LDAP authentication is not used for API calls

[martin-sa]

Step 1: Create a Taiga account, with a username that exists in LDAP, but make sure it has a different password than the user's LDAP password.

curl -X POST \ -H "Content-Type: application/json" \ -d '{ "type": "public", "username": "'$(whoami)'", "password": "'notasecret'", "email": "'noone@example.com'", "full_name": "'$(whoami)'" }' \ http://192.168.0.58/api/v1/auth/register

Step 2: Login interactively using a webbrowser. That works perfectly with the LDAP password. Trying to login using the Taiga specific password (notasecret in my command above) fails. Great! No surprises here.

Step 3: Now instead, try to sign-in using Taiga's REST API. Suddenly the password LDAP specified when registering the account should be used. The LDAP password does not work.

curl -X POST \ -H "Content-Type: application/json" \ -d '{ "type": "normal", "username": "'$(whoami)'", "password": "'notasecret'" }' \ http://192.168.0.58/api/v1/auth

I would say this behaviour is unexpected. To me, it would be more natural if the LDAP password was used even for API calls. Is my thinking flawed here, or could there be some room for improvement in the plug-in on this point?

[hardion]

+1 Just an extension of what have been said above: To workaround you have to set the same local password than the ldap. By default an ldap user has an empty password.

[Kegeruneku]

Have you tried using '"type": "ldap",' ?

[martin-sa]

Adding '"type": "ldap",' to the request sure makes logging in using the ldap password work.

Thanks @Kegeruneku !

[stevenroose]

@Kegeruneku is this intended? It makes no sense for API callers to need to know what authentication is used. I assume one could read the loginFormType field in the conf.json file and use that value, but that's cumbersome.