Attempting to visit air.mozilla.org causes redirection loop related to auth0 about airmozilla HOT 19 CLOSED

https://air.mozilla.org/login-failure/ is not protected. Anybody can open it.

▶ curl -I https://air.mozilla.org/login-failure/  | grep HTTP
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
HTTP/2 200

I wonder if it's some session cookie that is hell bent on trying to re-login or something.

Do you know, how can I fail to log in?
When I type in "[email protected]" as the email I see this:

from airmozilla.

I suspect it's got nothing to do with the /login-failure/ page but perhaps mozilla-django-oidc has a piece of middleware that, due to some session cookie, is intent on redirecting the user.

from airmozilla.

Ah! I think we're suffering from this: mozilla/mozilla-django-oidc#153

from airmozilla.

@gene1wood The only thing that can really redirect you on a page like /login-failure/ is the RefreshIDToken middleware. It's got nothing to do with what URL you're on since the middleware works for almost any URL (except some blacklisted ones). The RefreshIDToken does a redirect ONLY based on this list of conditions:

• GET request
• You're authenticated
• It's not an AJAX request
• You're not on urls like [u'/oidc/authenticate/', u'/oidc/callback/', u'/oidc/logout/']
• you don't have a future session cookie for oidc_id_token_expiration

I have a feeling you actually were authenticated but the ID token refresh redirect dance was upset and sent you back to /oidc/callback/?error=login_required&error_description=Login%20required&state=Bcb.... That back, then redirected you to harmless little /login-failure/. And since you're still signed in, but not without a oidc_id_token_expiration session cookie, you are redirected to https://auth.mozilla.auth0.com/authorize?nonce=mTeIPqMIGv3qGcI0vh5etSH0eNS4ojiv&prompt=none&state=KBT3WpufwH8N49a3t3JI0sDKPcIbz3EO&redirect_uri=https%3A%2F%2Fair.mozilla.org%2Foidc%2Fcallback%2F&response_type=code&client_id=nV1rnMMkB4uX9IewNOCitqy8NoyXVHlM&scope=openid+email which rejects and spits you back to /oidc/callback/?error=login_required&error_description=Login%20required&state=Bcb... and the redirect madness starts all over again.

One thing I don't understand is, if you were signed in, how did you even manage to get to the "Sign in" button (the one that redirects to to Auth0).

from airmozilla.

Perhaps you didn't click the "Sign in" button to kick off the craziness. Perhaps you were merrily logged in and on your next click, the middleware decided it was time for you to refresh your ID token and that fails.

Any idea how to reproduce that?

from airmozilla.

One thing I don't understand is, if you were signed in, how did you even manage to get to the "Sign in" button (the one that redirects to to Auth0).

I don't remember. I suspect I clicked sign-in which took me to the sign-in button which I clicked, but I could be wrong.

Any idea how to reproduce that?

The next time it happens to me I can gather more data. Is the thing missing from the HAR the step before the first step?

from airmozilla.

I only know how to open a HAR file in Chrome's Network dev tools. It just shows the URLs that happened. I don't know how to play it.

What makes things tricky is that you can't just go to /oidc/callback/?error=login_required&error_description=Login%20required&state=Bcb... because it's not reproducing the redirect loop.

from airmozilla.

I think I just have to wait till it happens again and capture more data. I imagine it will happen after the weekend as I won't be logged in for a couple days.

from airmozilla.

I see it too now. As in, I can't get in myself.
The URL it redirects to is:

https://air.mozilla.org/oidc/callback/?error=login_required&error_description=Multifactor%20authentication%20required&state=wydDOdYzzJT....

"Multifactor%20authentication%20required"

I was logged in on Friday last week and I guess now Mozilla Auth0 wants me to do something extra, i.e. 2FA.

I think the problem is that mozilla-django-oidc fails to log me out when the refresh redirect thing fails. I'll try to move this information over to the mozilla-django-oidc project.

from airmozilla.

I was able to view airmo last week without issue, however today I tried and got the redirect loop. I had closed my browser friday evening but I'm thinking it didn't close completely. So I was thinking the cache should have been cleared upon trying to reach airmo today.

After some poking around I realized Firefox needed a restart to update, so I restarted.
Afterwards I was able to reach airmo just fine. My browser settings clear cache and history on restart.

from airmozilla.

I got the redirect loop. Then I logged in to check the mana page for #moco. Then I was able to get to air.mozilla.org as well.

from airmozilla.

Went to air.mozilla.org and got this:
Archive 18-03-19 12-38-02.har.zip

Nightly 61.0a1 (2018-03-14) (64-bit) on macOS 10.13.2

NOTE: Clearing air.mozilla.org cookies did not help. I do not see any auth0.com cookies to clear.

from airmozilla.

I get the redirect loop in every copy of Firefox and Chrome. It's been slowly breaking one browser after another.

from airmozilla.

A workaround for now is to delete all "air.mozilla.org" cookies and login again.

from airmozilla.

I think this solves the problem for mozilla-django-oidc. mozilla/mozilla-django-oidc#213

However, for airmozilla the state of things are different. So perhaps instead of waiting for a new release of mozilla-django-oidc I just add a hasty extra middleware that does the same thing.

from airmozilla.

Inbound upgrade to remedy this quickly: https://bugzilla.mozilla.org/show_bug.cgi?id=1447117

from airmozilla.

@gene1wood
Airmozilla isn't particular important but the quick fix I threw together is a rough version of a change I'm proposing to mozilla-django-oidc and it's quite non-trivial.
Would you mind doing a test of this, using air.mozilla.org?

1. Log in, close your browser session.
2. Go to Auth0 admin and disable the relevant user
3. Open air.mozilla.org
   Expected result: Signed out
4. Enable the account again in Auth0 Admin
5. Go back to air.mozilla.org and you should be able to sign in again.

from airmozilla.

Sure.

1. I started a new browser session, went to air.mozilla.org clicked sign in was taken to Auth0 and signed in with my LDAP
2. I confirmed I was now logged into air.mozilla.org
3. I closed my browser
4. I blocked my production user in Auth0
5. I opened my browser and went to air.mozilla.org
6. I was still logged into air.mozilla.org

This is what I would expect though. Blocking a user in Auth0 wouldn't have any affect on an RPs session for that user.

from airmozilla.

This is what I would expect though. Blocking a user in Auth0 wouldn't have any affect on an RPs session for that user.

No it should have an affect. In Django we set a cookie that lasts a long time but there's a piece of middleware periodically forces you to go to Auth0 again (with that prompt=none). That should happen to you too and it should fail and when you come back to air.mozilla.org you should now be logged out. I suspect that the little timer that knows when it's time to refresh the session didn't kick in in your case. Perhaps if you click around a little bit longer.

from airmozilla.