Valid special characters in email address like + do not work
Permalink Browser Info Environment
If a user has an email address such as when they are logging in they are redirected to a url similar to:
It appears that the first parameter would translate to without the + symbol. In when trying to load the $userInfo by email address the user cannot be found.
A quick workaround is to add but this only works for plus symbols and is incorrect as we can't assume that all spaces should be a +.
Let me know if you need any other details
test+1@example.com
/login/callback/concrete/two_step_authentication_advanced/test%201%40example.com/
It appears that the first parameter would translate to
test 1@example.com
Kalmoya\TwoStepAdvanced\Overrides\Authentication\Concrete\Controller:42
A quick workaround is to add
$uName = str_replace(' ', '+', $uName);
Let me know if you need any other details
Type: | Ticket |
---|---|
Status: | Resolved |
Correction, base64 might add = / and + signs in the string so that's not going to work...
I need a different reversible encoding...
I need a different reversible encoding...
Me again...
It seems that a library is included in my package (and also in concrete's core) that has methods base64UrlSafeEncode() and base64UrlSafeDecode() so this seems promising
It seems that a library is included in my package (and also in concrete's core) that has methods base64UrlSafeEncode() and base64UrlSafeDecode() so this seems promising
This was taken care of
I don't have much control over how the URL is generated, that's concrete core stuff, so I'm thinking about 2 possibilities:
The first one would be to assume concrete is doing something wrong (can't imagine what) and encode the email myself before adding it to the URL, hoping concrete doesn't further process it.
The second one is to slice the Gordian knot and send it base64 encoded instead of in clear. Like that, it's all numbers and letters and easy to decode on arrival.
Would you agree the second option is best?