Redirect rule with user.email as request parameter

[wjans]

I’m having an encoding issue in my redirect rule when sending the user’s email as a request parameter. I add the request parameter like this:

context.redirect = {
    url: "https://my-domain.com/verify-email?email=" + user.email
};

This works fine for a regular email where the @ is properly encoded, but when it contains a + it is received as %20. Causing email addresses like for instance user+1@my-domain.com being received as user%201%40my-domain.com rather than user%2B1%40my-domain.com.

Is this expected behaviour? And if so, how can/should I deal with this?

[lucas.sonich]

Hello!

url is reading the + in the email as a space. You could try doing url encoding and pass the user.email already encoded.

Thanks.

[wjans]

Thanks, that does the trick!

I didn’t try it since parts were already encoded (like the @ for instance) and I would expect it to be encoded twice then, but that doesn’t seem to happen. Which I don’t fully understand to be honest, is there a check involved whether URL encoding still needs to happen afterwards?