API responses do not correspond to API documentation

Troubleshooting Self hosted Taiga
1

Good day fellow Taiga users,

my company uses a self-hosted Taiga instance for project management. We have an internal tool that combines some Taiga endpoints for analysis purposes.

I am currently trying to rebuild that tool with Laravel (currently it is built with Slim Framework) but the API responses I receive differ from the responses the current tool receives.

Two major differences I have discovered by now:

  • The user detail objects returned by the /users endpoint do not contain the e-mail keys. If I request a specific user however (/users/1), that entry contains the e-mail key. According to the documentation, /users and /users/{id} both return user detail objects. The current tool (apparently) receives the e-mail keys with its response. Mine does not (as outlined above).
  • The filtering per project on the /users endpoint does not work, for example /users?project=1 does just return all users inconsiderate of what members are actually part of the project with id 1. This is not implemented in the currently deployed tool, thus I do not know if it would work there, but it’s still weird?

Both tools use the exact same user (and thus password) for authenticating against the API.

Is there some trusted hosts setting or something along those lines that I am missing? Or do I do authentication wrong (this is the first project in which I set up the HTTP Networking myself, in other projects it was already done by someone else).

Right now my authentication flow looks as follows:

  1. Laravel application authenticates against /auth and receives user auth detail in response.
  2. I store the auth_token and refresh keys for future use.
  3. For all future requests, I configure the auth token as Authorization Bearer Token header with the Laravel in-built function ->withToken('my_auth_token'). This attaches a header Authorization: Bearer my_auth_token.

Note that right now I do not use the ‘refresh’ token for anything. Is that intended? Right now, every PHP requests logs in again to the API, that probably could be optimized (but should not be cause of the issues I am facing, right?)

Thanks a lot for reading, I will happily add further detail if I missed anything significant.

2

Hi @cdres

The users api never return emails for list user request. Only return email for a retrieve request only if the user is the consumer or is a superuser. This is for a security reason: any user could obtain all the emails of the platform and this is a sensitive information.

To get the list of project members, the best aprouch is to get the project detail using /api/v1/projects/<id> or /api/v1/projects/by_slug?slug=<project_slug>

You can read the documentation section about the Taiga Api here: Taiga REST API

I hope this can help

Best regards

3

Hey David,

thanks for the quick response. :slight_smile:

Is that behavior outlined somewhere within the API documentation because I can’t seem to find that. I only see that the response objects of both routes are apparently the same, at least both are called user detail object.

Thank you for your time.

4

Well, the response is auto-generated from a retrieve request with a superuser. This is why the response contains the email. The documentation is written manually and may contain some typos or simplifications (like this one).

I know that because I check the source code taiga-back/taiga/users/api.py at main · kaleidos-ventures/taiga-back · GitHub and because is a very bad practice to offer email lists from APIs.