CSRF token check on /backpack/authenticate fails in issuing workflow. #174

beardedmouse opened this Issue May 22, 2012 · 8 comments

2 participants


I have two different backpack users i've been logging in with for testing. Both start the login process from the separate open signin window but then direct to this URL: http://beta.openbadges.org/backpack/authenticate
where i get a "Forbidden" screen.

Anyone else having this issue. I'd mentioned on Friday and Chris mentioned that he thought it was working now, but not working properly for me yet.

Thanks in advance.



For some reason a token check started failing, other people have been reporting intermittent problems (I've been unable to reproduce). I have a reason to believe that it has to do with caching, however, in the meantime I've disabled that check. It's supposed to be for added security (making sure that the data sent in was actually sent in by the user, it's a cross-site request forgery check token) but for authentication, the data is being verified by the browserid authenticator so I think we're okay to disable it while I figure out the real issue.


Notes to self:

  • temporarily fixed by whitelisting /backpack/authenticate
  • add more debugging around the token failure (what was sent, what was expected)
  • the issuing workflow sends the CSRF token in a header rather than as POST data. Maybe that's an issue?
    • it could also be a caching problem; we should aggressively no-cache the entire issuing workflow.

Thanks Brian - now it's logging me in to this URL: http://beta.openbadges.org/
but none of the badges that i've awarded myself recently are there any longer. Really strange. Let me know if it helps to have more details about browser/system, etc. (or whatever's helpful).


So the badges were in the backpack and now they are not? That is incredibly strange. Yeah, let me know any details about that and see if you can reproduce it now. I implemented & pushed cache busting code to production, so the issuing workflow should be less stupid when switching between multiple identities.


Yeah, strange.

So - if, for example, i try and access my backpack from the openbadges.org homepage, it signs me in to a "http://beta.openbadges.org/" URL. If, however, i access my backpack from the most recent badge i was awarded (from my email (gmail) account) and then click on "go to my backpack" in the modal where it tells me "it appears you already have this badge," then it sends me to this version "http://stage.openbadges.org/" .

So yes, it appears that certain points of sign in are sending me to one URL and other points to others. Worth noting that the "stage" URL doesn't contain the earliest badges i was awarded. It looks like there was a point in time where it just started creating a new backpack for me.

I can't attach images here but will email you screenshots of the two different backpacks.

Mac 10.6.8
FF browser 12.0


Ah okay, so openbadges.org should be sending you to http://beta.openbadges.org, that's correct. http://stage.openbadges.org doesn't share a database with http://beta.openbadges.org so the backpacks can & will contain different badges, depending on which badges were pushed where.

You guys are testing using stage, right? If that's true, you should always be looking at stage for your latest badges to make sure that stuff works.


Although I may not be fully understanding the issue, let me know if I've misunderstood anything.


So am i correct that badges awarded to 'stage' won't be active in users' actual backpack? You're suggesting that our system isn't pointing badges to the right live place?

To your question, yes we've been using 'stage' to test our system but am not sure that our guys realize things are still pointed in that direction. I'll have them review what's here and come back to you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment