Closed Bug 888128 Opened 8 years ago Closed 8 years ago
missing crash-stats admin access after socorro 50/51 update with persona logon
I don't have admin privs in crash-status after logging into the updated socorro via persona. account firstname.lastname@example.org Thanks
jakem or jd - could you help me get access to the logs? We're not getting any error messages, there's probably some debug info though.
FYI, I'm able to log in. Are you in Mozilla LDAP under email@example.com or is this a non-Mozilla installation?
(In reply to Peter Bengtsson [:peterbe] from comment #2) > FYI, I'm able to log in. > > Are you in Mozilla LDAP under firstname.lastname@example.org or is this a non-Mozilla > installation? per Bug 531676 is should be in mozilla ldap
I see in crashstats/settings/base.py: LDAP_GROUP_NAMES = ['CrashReportsAdmin'] :peterbe, if you look at the PHP config you can see that this is the non-admin group: $config['admin_group'] = "cn=CrashCrew"; So, I think this means we want to allow "CrashReportsAdmin" group only access to /admin and "CrashCrew" access to PII
Wow! Two different levels. That's interesting indeed. That is going to me a significant code change. I'm happy to own that but it's going to take some time.
Wayne, I'm confused about something, you're not in the CrashCrew (or the CrashReportsAdmin) group. I can see that you're an employee using email@example.com which is also surprising considering that you're not in our Phonebook.
I'm not a true employee. I don't know how I am recorded except what's in Bug 531676. If there's a more suitable group for me to be in so I get the necessary privs that's cool. Perhaps I do for thunderbird what crashcrew people do for Firefox? Dunno. Mark might know.
Wayne, My bad. You are not in our LDAP as an employee. You are in the LDAP though. However, using the query I make you are NOT in CrashReportsAdmin or CrashCrew. I don't even think CrashCrew is a real group. I'm now trying to figure out why you were able to log in when the site was PHP before.
:jabba Apparently firstname.lastname@example.org IS in the CrashReportsAdmin group but we're not able to find him using the query you taught me to use (it's the exact same in MozLDAP) My code does two queries, one to figure out the UID (makes it possible to log in with your email alias) and then to combine that with the group name(s). The query we then run for email@example.com becomes:: (&(cn=CrashReportsAdmin)(|(firstname.lastname@example.org,o=com,dc=mozilla)(email@example.com,o=org,dc=mozilla)(firstname.lastname@example.org,o=net,dc=mozillacom)(memberUIDemail@example.com,o=net,dc=mozilla)(memberUIDfirstname.lastname@example.org))) We are hoping to, at some point, switch over to MozLDAP for Socorro so I think this is an interesting case to get that query working correctly.
I think the issue in your query there is (email@example.com,o=net,dc=mozillacom) You have dc=mozillacom instead of dc=mozilla
:jabba, you're a star! I better update MozLDAP too :) This PR fixes the problem https://github.com/mozilla/socorro-crashstats/pull/413 I know because I hijacked the code temporarily to log in as firstname.lastname@example.org
Commit pushed to master at https://github.com/mozilla/socorro-crashstats https://github.com/mozilla/socorro-crashstats/commit/a814b39cf1c3ed4cec11ff6922bc031d9275227e fixes bug 888128 - some people unable to login despite group membership, r=jabba
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
:mbrandt Can you QA this? From IRC:: 12:43 peterbeThe thing is, I think you can only QA if you can log in as a non-employee who is in LDAP and in the CrashReportsAdmin group :) 12:44 peterbeI guess we could QA that it just works to sign in but are you testing Persona sign in with your personal credentials? 12:44 peterbeAnd are you in CrashReportsAdmin?
OS: Windows Vista → All
Hardware: x86 → All
(In reply to Peter Bengtsson [:peterbe] from comment #13) > :mbrandt Can you QA this? I'm not sure I entirely understand what QA can verify in this instance - do I have access to this information. I can see a couple of potential scenarios: 1) we push this to stage and see if email@example.com can login as well as a list of other people who are unable to log in but should be able to. 2) generate a list of non-mozilla people from the old app that are able to log in with a generated list of people from the Django app who currently have privileges and see if there is a difference.
Let's go with 1 in this case. Once it's on stage.
(In reply to Peter Bengtsson [:peterbe] from comment #15) > Let's go with 1 in this case. Once it's on stage. Sounds great - Wayne when we land this on stage would you be willing to do some verification goodness for us :)
Whiteboard: [qa+] → [qa-]
You need to log in before you can comment on or make changes to this bug.