We just tried to authenticate with our application without being logged into anything on StackExchange. This is best tested in a private browser session without any cookies etc.
So after starting the iteration process on our site, I’m correctly redirected to the StackExchange OAuth authorization site (line breaks made for visualization purposes):
https://stackexchange.com/oauth
?client_id=9999
&redirect_uri=http%3a%2f%2flocalhost%2fauthorize
&scope=
&response_type=code
&state=
&returnurl=%2foauth%3fclient_id%3d9999%26redirect_uri%3dhttp%253a%252f%252flocalhost%252fauthorize%26scope%3d%26response_type%3dcode%26state%3d
So far so well. I then choose Google to log into StackExchange, get redirected correctly and log in there. Afterwards, Google redirects me to this URL:
https://stackexchange.com/%2foauth
%3fclient_id%3d9999
%26redirect_uri%3dhttp%253a%252f%252flocalhost%252fauthorize
%26scope%3d
%26response_type%3dcode
%26state%3d
As you can see, the URL is urlencoded and will throw a 404 error on stackexchange.com. If I decode that encoded URI, I get this URL, which is again close to what we had before:
https://stackexchange.com//oauth
?client_id=9999
&redirect_uri=http%3a%2f%2flocalhost%2fauthorize
&scope=
&response_type=code
&state=
If I enter that into my browser’s bar, StackExchange will correctly tell me that it’s redirecting me back to our site and that also works just fine.
Because I don’t get back to our app’s /authorize path, the authorization won’t finish. So I have to manually get back from the (blank) 404 error site, and restart the login on our page. As I’m now logged into SE, it will immediately return to the app and I’m logged in there, so it’s not that big of an issue.
But that double-urlencoding still breaks the complete workflow so it would be nice if that would be fixed.
