SSO redirect fails for non latin chars

Enabling Discourse as SSO provider (in wordpress but that is unrelated) doesn’t work when setting the redirect paramenter to non-latin chars. for example this works:

but this doesn’t work: discourse_sso=1&redirect_to=אאאא/

by “doesn’t work” i mean that the bad url just redirects to an “Oops error page” in Discourse

Use the transliterated URL characters instead. I wouldn’t expect unicode to work in that field.


Thanks, but Wordpress creates that url via this discourse plugin shortcode [discourse_sso_client login=‘Login here’ ]
The redirect URL is automatically set to the page in which the shortcode was embedded.

1 Like

You can add a redirect parameter to the shortcode:

[discourse_sso_client login='Login Through the Forum' redirect=]

That will create a link like this:

<a href="">Login Through the Forum</a>

You can also manually create a login link instead of using the shortcode. It needs to have the following query parameters:


I am aware that I can pass the redirect string into the shortcode, but that is not always practical. For example in my case (which I think is common), the shortcode is embedded in a sidebar shared in all pages of the website. So overriding the redirect means that users will never be redirected to the right page.

I guess i could write my own shortcode for that somehow… anyway, thanks for the answer and please consider this a feature request to support wordpress with unicode urls :slight_smile:

1 Like

@gerald is right, the plugin does not deal properly with URL and Unicode characters. I’m helping him on this matter.

After investigating, it seems you need to encode properly the URL before sending the request:
Possible and working suggestion: utf8_uri_encode($redirect_to)
If you don’t encode, Discourse will not be happy and will error that URI must be ASCII only.

Another place to fix is when the plugin receives the response:
I’m not totally sure why urldecode and sanitize_text_field is used before the string is decoded, but once decoded, the sanitize_text_field call on the URL will strip all the encoded characters.
Possible suggestion: urldecode needs to be called before.

So far, those fixes seem to fix the issue gerald had.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.