anti-forgery-token is encoded but not decoded

[aheusingfeld]

In https://github.com/ddellacosta/friend-oauth2/blob/master/src/friend_oauth2/util.clj#L17 the anti-forgery-token is form-encoded but it is never decoded before checking it in https://github.com/ddellacosta/friend-oauth2/blob/master/src/friend_oauth2/util.clj#L40.

In case the state contains spaces, the token will have + chars after the encoding and therefore will not be the same. I just found that this is the reason for an endless loop redirecting me back to the provider.

[ddellacosta]

Thanks, good catch! Actually I shouldn't have been passing non-URL safe chars in the first place, so I'm stripping out +, / and = now.

I'll push a release ASAP and update this issue when I have.

[ddellacosta]

Hmm, actually I'm a bit curious what you were actually seeing--you won't see any spaces generated by crypto.random/base64, so I assumed you meant the + symbols were getting URL-encoded when sending (to "%2B") and then you were seeing "%2B" when you got the response back. Is this the case? I still don't want to assume the authorizing server is going to be doing URL-unencoding but I'm curious what the actual behavior is here.

[aheusingfeld]

When I set a breakpoint at https://github.com/ddellacosta/friend-oauth2/blob/master/src/friend_oauth2/workflow.clj#L32 (BTW: in friend-oauth2-0.1.1 it is L34) I can see that anti-forgery-token has a value of yXK1KWOg7lOsiDpsykvwWohxrxzs5EcEOXELtFgpeV9Vnha27XseRUTMCA9t1+77RlAAok8C4QMp7rTy
But when the redirect happens in https://github.com/ddellacosta/friend-oauth2/blob/master/src/friend_oauth2/workflow.clj#L47 it turns out

state:         yXK1KWOg7lOsiDpsykvwWohxrxzs5EcEOXELtFgpeV9Vnha27XseRUTMCA9t1 77RlAAok8C4QMp7rTy
session-state: yXK1KWOg7lOsiDpsykvwWohxrxzs5EcEOXELtFgpeV9Vnha27XseRUTMCA9t1+77RlAAok8C4QMp7rTy

So it seems that session-state has the same value as anti-forgery-token before the request but state doesn't have the + chars anymore. I really wonder why no one else stumbled upon that, yet. :-|

I'll push a release ASAP and update this issue when I have.

Thanks! I'm looking forward to that as it will probably solve the issue.

[ddellacosta]

Huh, well, sounds like maybe whatever provider you're using is doing some substituting of those values, as I would expect to see the URL encoded value "%2B" if we were to see anything--but no matter, it seems obvious these should be getting replaced regardless and will hopefully solve your problem. Thanks again for catching this!

[ddellacosta]

Pushed release 0.1.2

[aheusingfeld]

@ddellacosta great, this really fixed the issue. Thank you very much.
Just for your and others reference: This ticket has been raised as I'm working on innoq/statuses#148 - you will soon see the code there, I'm currently wrapping up and pushing things to the test environment. ;)