If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.
RESOLVED WORKSFORME

Status

Mozilla Developer Network
Sign-in
P1
normal
RESOLVED WORKSFORME
5 years ago
3 years ago

People

(Reporter: retornam, Unassigned)

Tracking

Details

(Whiteboard: [type:bug], URL)

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
STR:
1) Visit https://developer.mozilla.org
2) Click the sign in  button and try to login using MozillaPersona
3) The page redirects to https://developer.allizom.org/en-US/users/browserid_verify
which shows a blank page and nothing happens afterwards

Updated

5 years ago
Priority: -- → P1
Whiteboard: bug
Haven't seen this in a while. Stephen: Can you reproduce?
Flags: needinfo?(stephen.donner)
(In reply to John Karahalis [:openjck] from comment #1)
> Haven't seen this in a while. Stephen: Can you reproduce?

Yes:

1. Visit https://developer.allizom.org/en-US/fjdskl
2. Click on Sign In
3. Log in
4. You're taken to:

https://developer.allizom.org/en-US/users/browserid_verify
Flags: needinfo?(stephen.donner)
Created attachment 692408 [details]
Screenshot, including some Web Console stuff
11:56 jrgm: stephend: so on the wire, an assertion is POST'd to the server, and that returns 302 to the other page for register. The assertion checks out as properly signed. I can't really say what the back end of MDN allizom is thinking.
Just managed to repro this 7 times in a row (in fact I can't log in from Nightly or Aurora at all). I get a 405 METHOD NOT ALLOWED response from GET .../browserid_verify and the login process stops.
Can someone look at the server logs on developer.allizom.org for the approximate time of comment #5 '2013-02-05 19:25:04 PST'. 

:jsocol was that a GET or a POST? I don't know where the source for developer.allizom.org lives but I can imagine that server not allowing a GET to /en-US/verify/browserid_verify. But I don't know what would be causing d.a.o front-end code to choose to GET this.

FWIW: I tried this now in nightly, and I am authenticated to developer.allizom.org, but in my case the assertion is sent with a POST which returns a 302 with a cookie, and Location: https://developer.allizom.org/en-US/
Created attachment 710504 [details]
screenshot of persona pop-ups

(In reply to John Morrison [:jrgm] from comment #6)
> Can someone look at the server logs on developer.allizom.org for the
> approximate time of comment #5 '2013-02-05 19:25:04 PST'. 

Ah, sorry, this was actually on prod (developer.mozilla.org) not stage. Not that there's much difference.

> :jsocol was that a GET or a POST? I don't know where the source for
> developer.allizom.org lives but I can imagine that server not allowing a GET
> to /en-US/verify/browserid_verify. But I don't know what would be causing
> d.a.o front-end code to choose to GET this.

It was a GET.

The source is here, for the record: https://github.com/mozilla/kuma It uses django-browserid.

> FWIW: I tried this now in nightly, and I am authenticated to
> developer.allizom.org, but in my case the assertion is sent with a POST
> which returns a 302 with a cookie, and Location:
> https://developer.allizom.org/en-US/

I just tried again on both stage and prod and was able to authenticate fine (though I note that on prod the persona popup does not look the same as on stage, and that's still true [prod - top, stage - bottom]).
So on the issue of the appearance of the popup on prod vs. stage, that's a known issue with firefox and window.open when the parent window has changed CSS pixel-to-device ratio:
https://bugzilla.mozilla.org/show_bug.cgi?id=779335#c3
https://github.com/mozilla/browserid/issues/2008#issuecomment-7412230
So in the upper image the width is such that it has switched layout based on CSS @media rules.


But back to this bug. I don't know why this would come and go, with a 405 result for a GET. The best clue might be in the the d.m.org server logs.
(In reply to comment #5)
> Just managed to repro this 7 times in a row (in fact I can't log in from
> Nightly or Aurora at all). I get a 405 METHOD NOT ALLOWED response from GET
> .../browserid_verify and the login process stops.

Was this on prod, or on stage?
(In reply to Luke Crouch [:groovecoder] from comment #9)
> (In reply to comment #5)
> > Just managed to repro this 7 times in a row (in fact I can't log in from
> > Nightly or Aurora at all). I get a 405 METHOD NOT ALLOWED response from GET
> > .../browserid_verify and the login process stops.
> 
> Was this on prod, or on stage?

(In reply to James Socol [:jsocol, :james] from comment #7)
> Ah, sorry, this was actually on prod (developer.mozilla.org) not stage. Not
> that there's much difference.

The 405 almost certainly comes from a @require_POST decorator in django-browserid (unless the browserid_verify view is in kuma). So my question is why would Persona sometimes cause a GET and sometimes a POST?
Whiteboard: bug → [type:bug]
Duplicate of this bug: 881746
I saw this the other day, and someone else just verified with bug 881746.

We need to update django-browserid (or whatever it's called now) anyway. Would we be able to do both in one go here?
I hit this today.
Please vote on this bug to float it to the top of the backlog. (http://mzl.la/mdn_backlog)
I'm 99% sure this was caused by situations where we got into the old MindTouch compatibility code. Which was just removed in a gigantic commit that landed in the repo the other day. Closing for now as a result, but once deployed, if people keep seeing the issue, please reopen.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Duplicate of this bug: 904686
Happening again. See bug 904686.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Just hit this myself. Thankfully the workaround is easy and obvious: log in again, and you will probably be successful.

Comment 19

4 years ago
I had a sign in issue, before, when trying to add linuxwebdeveloper@gmail.com when still using BlackJadedHeart@gmail.com for my MDN sign in.  So, I was told it would be fixed, and then I was able to sign in with linuxwebdeveloper@gmail.com.  But, then, last night, around 7 something p.m., EST, I got a notification e-mail to my BlackJadedHeart@gmail.com e-mail address, specifying that I was vouched for on mozilla.org.  I tried signing in with linuxwebdeveloper@gmail.com, first, and it showed I was verified when i did so via persona, but then it went to a webpage that showed as though that e-mail address isn't affiliated with an acct on MDN.  So, I then tried BlackJadedHeart@gmail.com, and it allowed me sign in.  Earlier, today tried these same steps, too, before just a couple minutes, aho, and I couldn't even sign in with any of the e-mail addresses.  Please correct this problem for me, and allow me to sign in with both of my e-mail addresses so that I can use either one to sign in at any time.  Can you also check to make sure that was valid of that I am vouched for, because if I am not, why that e-mail notification to me of that I am vouched for?  And since I usually mainly use linuxwebdeveloper@gmail.com, now.. can I be of that, as well?
April Morone

Comment 20

4 years ago
April,

It sounds like there are a few things going on here, none of which are clearly related to the original description of this bug.

1. You have a profile on MDN that is associated with your linuxwebdeveloper@gmail address.
2. You have a vouched profile on Mozillians.org that is associated with your BlackJadedHeart@gmail address.

These are two separate identities as far as Persona is concerned. If you try to log in to MDN with BlackJadedHeart, you will be asked to create a new MDN profile. If you try to log in to Mozillians.org with linuxwebdeveloper, you will be asked to create a new Mozillians profile.

> Please correct this problem for me, and allow me to sign in with both of my e-mail addresses so that I can use either one to sign in at any time.

That's not how Persona currently works. You can have two email addresses connected to Persona, but you will not be able to log in to the same account on a website with both addresses. This might change in the future for Mozillians.org (see bug 699952).

If you can reproduce the problem you had with MDN, please submit a new bug. If it turns out to be the same problem as this one, it will be marked as a duplicate. But it might turn out to be a different login-related bug.

If you want to change the email address you use for Mozillians.org, file a bug for Community Tools::Account Help.

Comment 21

4 years ago
Correction: If you can login to Mozillians.org, you can change your email address by editing your profile. If you can't login to Mozillians.org, file a bug for Community Tools::Account Help.

Comment 22

4 years ago
(In reply to Janet Swisher from comment #21)
> Correction: If you can login to Mozillians.org, you can change your email
> address by editing your profile. If you can't login to Mozillians.org, file
> a bug for Community Tools::Account Help.

Janet,
     Thank you for this information.  :)  And I had meant Mozillians.org.  :)  Yes, I'd had an acct under BlackJadedHeart@gmail.com on Mozillians.org, and an acct under linuxwebdeveloper@gmail.com on MDN.  I meant for everything to be same of accts on both websites, as well as to be vouched for on the acct on Mozillians.org of the linuxwebdeveloper@gmai.com account.  William has fixed this whol entire issue for me (Thank you William).  :)
I think I finally discovered some steps to reproduce.

To get stuck on browserid_verify:

> 1. Visit https://developer.mozilla.org/en-US/asdf (or any other page
     that does not exist)
> 2. Sign in

By contrast, to log in normally, without getting stuck on browserid_verify:

> 1. Visit https://developer.mozilla.org/en-US/ (or any other page that
>    does exist)
> 2. Sign in

Raymond, can you confirm this? In comment 0 you mention that this happens only on developer.mozilla.org, but could it be that you were mistaken, and that this only happened to you when logging in from a 404 page?
Flags: needinfo?(mozbugs.retornam)
(Reporter)

Comment 24

4 years ago
(In reply to John Karahalis [:openjck] from comment #23)
> I think I finally discovered some steps to reproduce.
> 
> To get stuck on browserid_verify:
> 
> > 1. Visit https://developer.mozilla.org/en-US/asdf (or any other page
>      that does not exist)
> > 2. Sign in
> 
> By contrast, to log in normally, without getting stuck on browserid_verify:
> 
> > 1. Visit https://developer.mozilla.org/en-US/ (or any other page that
> >    does exist)
> > 2. Sign in
> 
> Raymond, can you confirm this? In comment 0 you mention that this happens
> only on developer.mozilla.org, but could it be that you were mistaken, and
> that this only happened to you when logging in from a 404 page?

No this happens when I try to login from the homepage sometimes not only on 404 pages. We have been able to reproduce this more on 404 pages though
Flags: needinfo?(mozbugs.retornam)
Looks like we have bug 853480 for the issue I mention in comment 23.
I haven't hit this issue at all, and now that we've switched away from django-browserid can we revisit this?
Flags: needinfo?(jkarahalis)
FWIW, I cannot reproduce using the steps in Comment 2 or Comment 23.
(In reply to Jannis Leidel [:jezdez] from comment #26)
> I haven't hit this issue at all, and now that we've switched away from
> django-browserid can we revisit this?

This bug has a history of being difficult to reproduce. Comment 23 shares some steps, but it turns out those steps reproduce a different bug, bug 853480.

This bug is about more random and sporadic authentication failures. Given the difficulty in reproducing this, I recommend that we close the bug as WORKSFORME and keep an eye out for similar bugs in the future.
Status: REOPENED → RESOLVED
Last Resolved: 4 years ago3 years ago
Flags: needinfo?(jkarahalis)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.