claudioc / jingo

Node.js based Wiki
MIT License
1.02k stars 184 forks source link

Auth handshake fails in 403 (sometimes) #65

Open almereyda opened 9 years ago

almereyda commented 9 years ago

Despite I can successfully login to our Jingo instance, users repeatedly report errors which are reflected by the thrown 403 below.

x.x.x.x - - [22/Jan/2015:08:21:05 +0100] "GET /auth/github HTTP/1.1" 302 0 "http://wiki.transformap.co/login?destination=%2Fwiki%2FTransforMap" "Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 Iceweasel/31.3.0"
x.x.x.x - - [22/Jan/2015:08:21:06 +0100] "GET /auth/github/callback?code=07548d1af20764a1a354 HTTP/1.1" 302 76 "http://wiki.transformap.co/login?destination=%2Fwiki%2FTransforMap" "Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 Iceweasel/31.3.0"
x.x.x.x - - [22/Jan/2015:08:21:07 +0100] "GET /auth/done HTTP/1.1" 403 29 "http://wiki.transformap.co/login?destination=%2Fwiki%2FTransforMap" "Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 Iceweasel/31.3.0"

I'm running Jingo behind a nginx reverse proxy and proxy_buffering off;.

How can this error happen? Why does the user receive a forbidden status?

almereyda commented 9 years ago

An example of a working handshake

x.x.x.x - - [22/Jan/2015:23:43:54 +0100] "GET /auth/github HTTP/1.1" 302 0 "http://wiki.transformap.co/log
in?destination=%2Fwiki%2FTransforMap" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0"
x.x.x.x - - [22/Jan/2015:23:44:07 +0100] "GET /auth/github/callback?code=5c7f95ae6171367dc369 HTTP/1.1" 302 76 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0"
x.x.x.x - - [22/Jan/2015:23:44:08 +0100] "GET /auth/done HTTP/1.1" 302 90 "-" "Mozilla/5.0 (X11; Ubuntu; L
inux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0"
claudioc commented 9 years ago

The test is quite simple:

!auth.alone.used && !tools.isAuthorized(res.locals.user.email, app.locals.config.get("authorization").validMatches

Looking at the code it seems that the authorization fails because the user email is not a validMatch. Is it possible?

almereyda commented 9 years ago

I start to believe it is an IPv6 issue from the landline there.