Closed menturion closed 5 years ago
So far all I see is the expected behaviour: the configuration does not point towards a valid base URL and the login attempt fails.
Synapse does not return anything meaningful even thought this return the exact error.
Thanks for your reply. Which base URL do you mean? -1- The Matrix base URL? -2- Or the endpoint URL defined in the password provider config?
Both URLs work and respond correctly in other test scenarios.
I meant the 2nd URL if your list.
What is different in this test scenario compared to the other ones?
In the other test scenario I send the request ({'user':{'id':user_id, 'password':password}}
) directly to the implemented endpoint (-2-) through an PHP script (cURL) and get the correct JSON response according to your module description.
Please show all the log lines relevant to the attempt in synapse; you only show the stacktrace, so it's not really possible to tell you what could be wrong at this point.
I just got the problem.
Obviously Matrix is building a matrix ID by adding the prefix "@" and adding the postfix ":localhost" in my case to the "user_id".
However, I built a password provider endpoint that requires an email for authentication and returns a matrix ID if the authentication succeeds. This results into the following ID @mail@address.com:localhost
which is send to the password provider endpoint. And thus the login fails.
Is there any way to disable Matrix from adding a pre- and postfix to the user_id (here: [email address] for authentication)? Or do I have to strip the pre- and postfix before authentication?
No option for it I'm afraid.
So it might be a useful config option for your module which would tell your password provider to send an email address to the endpoint by stripping the pre- and postfix at line #46 in your code (def check_password ...)?
That's not a possible option: email has a specific meaning in Matrix, especially for the prime use case of this password provider: mxisd.
The current format must remain to accomodate for all use cases within the ecosystem.
What I mean is that some password providers (e.g. existing user database, with email and hashed PWD credentials) might need an email address to authenticate the user and return the corresponding Matrix ID upon authencation.
Otherwise the user would have two different credentials. One with the email address (legacy) and one with the user ID for Matrix (new).
Nevertheless, many thanks for your help! I solved it by stripping the ID to get the entered email address for authenication.
Otherwise the user would have two different credentials. One with the email address (legacy) and one with the user ID for Matrix (new).
That is precisely the point, and is a valid scenario from a Matrix point of view. Therefore, this password provider has to support it also. That it's not the case in your system is for you to deal with, but a Matrix ID, a username and an email are to be considered two different credentials in Matrix, with potentially three different outcomes or requirements.
Thank you for the follow up, closing this issue now.
I am getting the following error in the log file:
The response body of the Matrix API is as follows:
"{"errcode":"M_UNKNOWN","error":"Internal server error"}"