Intermitent fail 1 time each 10 times using Oauth: mismatching_state error

server

#1

I successfully implemented Oauth with PHP using Bshaffer server package with Seafile server 6.2.3 and everything seems to work correctly except this.
All 4 calls that Oauth make are working great:

  • 1 _authorize_validate
  • 2 _authorize_handle POST /{_locale}/oauth/authorize
  • 3 _token
    _user_info GET /{_locale}/oauth/user -> After this I’m logged in in Seafile with the user provided in this Json response.

But 1 time each 10 calls or so it fails with the following error:
2017-12-26 16:15:18,592 [ERROR] seahub.oauth.views:111 oauth_callback (mismatching_state) CSRF Warning! State not equal in request and response.

Here it’s a trace of my existing calls:
https://seafile/accounts/login/ SSo link:

GET http://mysso/app_dev.php/de/oauth/authorize?response_type=code&client_id=seafile&redirect_uri=https%3A%2F%2Fstorage%2Foauth%2Fcallback%2F&scope=user&state=Yw59lC5m24acdBLkkM4BBjU0bQ3Hja/oauth/authorize?response_type=code&client_id=seafile&redirect_uri=https%3A%2F%2Fstorage%2Foauth%2Fcallback%2F&scope=user&state=Yw59lC5m24acdBLkkM4BBjU0bQ3Hja

Click on authorize:
POST http://mysso/oauth/authorize?response_type=code&client_id=seafile&redirect_uri=https%3A%2F%2Fstorage%2Foauth%2Fcallback%2F&scope=user&state=Yw59lC5m24acdBLkkM4BBjU0bQ3Hja

Redirect to redirec_uri
https://seafile/oauth/callback/?code=aded49b3a6b7906ef992349cf163b651bed7d5f7&state=Yw59lC5m24acdBLkkM4BBjU0bQ3Hja

And that’s it here it dies before calling the user data with this error.

And it cannot be that the state has been tampered with. I checked it many times, the state in the first call is the same as in the last Token request. So there is have to be something wrong in the state checking unless I’m overseeing something very bold (Or the error is not providing the right description and another thing is happening under the hood)

NOTE: I’m not using SSH in this example since I don’t have a valid certificate for developing, but the error seems unrelated to this.

As an additional info once getting this error, every additional SSO call might get’s the same error until restarting Seahub with: seahub.sh restart
UPDATED 11.01.2018: Sorry this is not true. No need to restart it’s just that after first time it happens is more likely to happen again or it’s just random. But server keeps on working of course!

This does not happen only with my Oauth install, happens also with the provided github example, just hit the Route:
/oauth/login/ Many times until getting it.

Can you please take a look ? It’s impossible to integrate this until this is fixed.


#2

@daniel.pan and team, can you guys please send me some signal over this one ?
I really want to have this working as soon as possible! Thanks :slight_smile:


#3

We don’t have to look into the problem yet. We will look at it in the next week.


#4

Hi,

I have the same problem. I print the state function parameter (state org) and state from params.get (state param) from parse_authorization_code_response in oauthlib in the parameters.py
Here the exception is thrown

if state and params.get(‘state’, None) != state:
raise MismatchingStateError()

Here is an example of multiple sign-ons after starting the seahub server:

state org = None … state param = ZdHqp6KXb0yHp7sKflIPeIkL8sRQNF
state org = OuGAJ6bDaPwSFqudIXyXSXRJqXwyqs … state param = OuGAJ6bDaPwSFqudIXyXSXRJqXwyqs
state org = OuGAJ6bDaPwSFqudIXyXSXRJqXwyqs … state param = UMqrRYlaqgJhLpRNKgLMMy3rEPWiai
state org = None … state param = RwgKGUKcis5IpMf2YjDlje99H1ppVX
state org = jZLsSLawIqxIOm3PoXRqQUaAydXBsA … state param = jZLsSLawIqxIOm3PoXRqQUaAydXBsA
state org = OuGAJ6bDaPwSFqudIXyXSXRJqXwyqs … state param = lj00CBrRGWPawJuOmOyobPMU5YN2eM
state org = UMqrRYlaqgJhLpRNKgLMMy3rEPWiai … state param = IiEnvPmPB2k30HaXUloIJGbjFr6KZn
state org = VofcbpxiO4AtUCHZjtij1IZu1Jh7Ox … state param = VofcbpxiO4AtUCHZjtij1IZu1Jh7Ox

Thanks.


#5

The fix will be included in the next release for pro and community edition.


#6

Hi,

Did you fix the issue?

Thanks


#7

We still didn’t make it live but I’ve been testing it locally and it seems to work without any interruption.

Good work @daniel.pan and thanks for the support!