Cookie Referrer is not deleted after an OAUth redirect

• Customer / Requester: Big Consumer Electronic Company
• GitLab version: 7-14-stable-ee replicated in 8.1.2-ee
• Zendesk ticket: https://gitlab.zendesk.com/agent/tickets/10440

Description of issue

If you use GitLab as an OAuth provider, the following edge case can happen.

• First open a GitLab tab, but don't sign in there
• Open the Web App that has omniauth-gitlab for sign in and sign in there with your GitLab credentials
• Then go into the already opened tab and sign in again there.
• You will be redirected to the App instead of the main GitLab dashboard

This happens, because the Web App sets a referrer to the OAUth callback URL, in order to properly authenticate. This referrer does not get deleted after the redirect, so it stays in the cookie, which the already opened tab reuses, thus redirecting the user back to the Web App instead of the GitLab dashboard.

Result of replication

Just as stated.

Concrete questions / Next steps

@DouweM and I had a quick chat about this on Slack, and it seems that we are simply not resetting or clearing the cookie before the redirect.

“Clearing the cookie” is really just passing along the “Set-Cookie” header with the response, no matter if the response is a “200 OK” or a “301 Redirect”

So we could just reset the cookie and send the 301 response.

@DouweM how much time do you think it would take to fix?

/cc @JobV

@patricio If the issue is indeed what we think, not more than 30 minutes.

@JobV can we schedule this for 8.5?

Milestone changed to 8.5

Reassigned to @jameslopez

@DouweM what's the best way to test this? I've tried using a simple rails-omniauth app with the omniauth-gitlab gem, but I'm getting this error after authorising login in and authorising the app:

Auth2::Error at /auth/gitlab/callback
invalid_grant: The provided authorization grant is invalid, expired, revoked, does not match the redirection URI used in the authorization request, or was issued to another client.
{"error":"invalid_grant","error_description":"The provided authorization grant is invalid, expired, revoked, does not match the redirection URI used in the authorization request, or was issued to another client."}
OAuth2::Client#request
oauth2 (1.1.0) lib/oauth2/client.rb, line 113

The app I've put: https://gitlab.com/jameslopez/rails-gitlab-omniauth

@jameslopez Yeah, that's probably the best way to replicate and test it. That error sounds like the config of the OAuth application you've created in your GitLab instance is wrong, do the URIs match etc?

@jameslopez Looks like you're not alone with that issue, check out https://github.com/linchus/omniauth-gitlab/issues/10

thanks @DouweM - they fixed in the latest release and it now seems working

@DouweM I am unable to replicate this with the test app I'm using:

http://recordit.co/Vd3zEFtfMO

1. Showing the app config in my gitlab instance at port 3000. Cleared cookies and refreshed the page.
2. Login in with my omniauth app at port 5600. Redirected to gitlab to login
3. Logged in successfully to my app at 5600.
4. Tried logging with the first tab to my local gitlab instance, port 3000. ActionController::InvalidAuthenticityToken error is showed.

I tried with Gitlab CE, EE, Chrome and Firefox - with the same results...

Am I reproducing this the wrong way?

/cc @patricio

@jameslopez Have you compared that method against the video in the ZenDesk ticket?

@DouweM actually not, just checked 1password to get access and have a look. Thanks!

@DouweM I'm still having trouble with this one as I can't replicate it with the latest omniauth-gitlab - but I could reproduce it using gitlab.com and omniauth-gitlab 1.0.1. However I still get the same ActionController::InvalidAuthenticityToken if I use my local Gitlab instance, so I couldn't test a fix!

I think it might be much faster if you put a fix for this one? Perhaps the omniauth-gitlab upgrade is one path. Or adding the Set-Cookie header in Oauth::AuthorizationsController#new, I'm guessing

@jameslopez I'm not too familiar with the omniauth behavior here either, I'm afraid, and I haven't even tried reproducing it :) If you could reproduce it with gitlab.com, that's odd, since that now runs an 8.5rc... Even if you can't reproduce, do you understand why it could happen and think up a fix for that, like resetting the cookie?

@DouweM no problem, let me put something in place. @patricio it would be awesome if you could quickly test a fix as 1.0.1 is working for you!

mentioned in merge request !2876 (merged)

Milestone changed to 8.6

Reassigned to @patricio

@patricio I've put a fix for this on https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/2876 - it would be great if you could test it...

@jameslopez it's going to take me some time, but I'll get to it before the release.

@patricio No problem, really appreciate your help! thanks

@jameslopez I was able to test the fix and it does seem to work. Did it work for you as well?

Reassigned to @jameslopez

@patricio thanks very much! I sort of tested it locally but with a slight different error. I only managed to reproduce it properly using gitlab.com. So I really appreciate your help!

Status changed to closed by merge request !2876 (merged)

mentioned in commit d22c1069

Mentioned in commit pfjason/gitlab-ce@d22c1069

Mentioned in commit pfjason/gitlab-ce@64b57ec8