HTTP API allows creating users with an email address containing a colon (:
), frontend doesn't, furthermore such an account doesn't work with HTTP Basic auth.
#1245
Labels
documentation
API docs, readme, developer docs
A minor issue, but an issue all the same.
The Central HTTP API allows creating users with an email address containing a colon (
:
), see for instance this user I've created. But then you can't use that account for the API's HTTP Basic auth!The frontend doesn't allow creating such a user. Wikipedia leads me to think that that's erroneous — a
:
in the local-part of an email address is not invalid, even though all kinds of deliverability problems may arise from using such an email address (the local part needs to be quoted, for one). Nevertheless, I could get email delivered to me, which is what I needed for a password reset, which is what I needed to try out HTTP Basic auth, which then doesn't work.The minor problems in a nutshell:
:
) in it when authenticating with HTTP Basic auth, because the colon is the internal field separator (the authorization header value isbase64(utf8-encode(emailaddress:password))
; thus upon unpacking that there will be ambiguity. As such Central responds with a401 Unauthorized
with body{"message":"Could not authenticate with the provided credentials.","code":401.2}
when you try to do this anyway.My point is not so much that we should accommodate for such email addresses. But I do feel there's a slight issue because we're promising things that we can't follow through on, and I think that's by accident rather than deliberate.
Where to go from here then? Two ways forward:
A. given that we document and support (though discourage) HTTP Basic Auth, we simply shouldn't allow creation of accounts with email addresses with a
:
in them. Effecting that would also remove a discrepancy between frontend and backend validation, which is tidy ✨ .B. Simply document in the API documentation for HTTP Basic auth that sorry, if you managed to create an account with a colon in its email address, you can't use it for this auth scheme.
B) would certainly be the cheapest solution ;-)
The text was updated successfully, but these errors were encountered: