Closed Bug 1328619 Opened 8 years ago Closed 8 years ago

Error logging in: Invalid email for clientId: 'mozilla-ldap/pmoore@mozilla.com'. Invalid value for scope 'assume:mozilla-user': 'None'

Categories

(Tree Management :: Treeherder, defect)

Product:
Tree Management
Component:
Treeherder
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 1339882

People

(Reporter: pmoore, Unassigned)

References

Details

I'm getting this error when accessing treeherder. I tried logging in via okta. When going to log in / log out, the taskcluster login page appears, and then immediately redirects to the page with the error, so it isn't possible to log out or log in a different way (unless e.g. using private browsing, clearing cache / local storage etc). Thanks!
Flags: needinfo?(cdawson)
This should go away when we merge Bug 1319246 - Allow login with plain email from Auth0. The problem is that the user is successfully logging in to TaskCluster, but then we reject it for our own reasons. TC doesn't know about that, so figures it's the same user just logging in again, so flashes past the screen to choose their login style. With bug 1319246, we should ensure we log the user in, one way or another, if they logged in successfully with Task Cluster. Even if that means creating a new user for them, based on that clientId. In that PR, we will still fail for two reasons, though: 1. the clientId has no email in it that we could find. We could change this to actually log the user in/create a user for them and perhaps put the clientId in the email field. I bet this is pretty rare. 2. The user has been disabled in Treeherder. Perhaps this case doesn't matter much. If the user is disabled, then we had some reason and aren't eager to let them log in again. Also, we don't have any disabled users... :)
Depends on: 1319246
Flags: needinfo?(cdawson)
This only affects TaskCluster people (who have assume:mozilla-user:*, because we can't agree on a way to use less-powerful credentials day-to-day). The fix is to create a less-privileged user with an appropriate assume:mozilla-user role and login as that. Or wait until bug 1319246 lands.
Bug 1319246 improved the situation here, though I think there are still some issues - see bug 1339882.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.