"AttributeError: 'NoneType' object has no attribute 'email'" in authserver

[Andrew Bennetts]

We occasionally see tracebacks like this in the authserver logs:

Traceback (innermost last):
  Module zope.publisher.publish, line 138, in publish
    result = publication.callObject(request, object)
  Module canonical.launchpad.webapp.publication, line 332, in callObject
    return mapply(ob, request.getPositionalArguments(), request)
  Module zope.publisher.publish, line 113, in mapply
    return debug_call(object, args)
   - __traceback_info__: <security proxied zope.app.publisher.xmlrpc.metaconfigure.AuthServerAPIView instance at 0x5718890>
  Module zope.publisher.publish, line 119, in debug_call
    return object(*args)
  Module canonical.launchpad.xmlrpc.authserver, line 26, in getUser
    return self._getPersonDict(self._getPerson(loginID))
  Module canonical.launchpad.xmlrpc.authserver, line 104, in _getPersonDict
    return {
  Module canonical.launchpad.xmlrpc.authserver, line 117, in _getEmailAddresses
    return [removeSecurityProxy(email).email for email in emails]
AttributeError: 'NoneType' object has no attribute 'email'

It's been happening for a long time (months IIRC). It started in the old twisted authserver, but it's now also occuring in the XML-RPC private server. Presumably is a simple bug that ought to be fixed. A quick inspection suggests it happens when retrieving the details of a user with that has no preferredemail set.

OOPSes recently: OOPS-1000XMLP10, OOPS-1000XMLP11, OOPS-1012XMLP1, OOPS-1012XMLP2, OOPS-1020XMLP2, OOPS-1184XMLP1,

[Michael Hudson-Doyle (mwhudson)]

So, finally, I think I know what's going on here. This happens when someone tries to log in to codehosting as a user who does not have a preferred email address -- for example "ssh <email address hidden>" does this, and it's easy to see how this might happen by mistake (lots of people probably have 'david' as their local username).

The call that is oopsing is the call to getUser we make to get the ssh keys.

I'm not sure what the correct fix is really; fixing getUser to pretend a user who doesn't have a preferred email address doesn't exist would be simple enough, but I'm not really sure what the implications of not having a preferred email address are.

[Francis J. Lacoste (flacoste)]

> I'm not sure what the correct fix is really; fixing getUser to pretend a user who doesn't have a preferred email address
> doesn't exist would be simple enough, but I'm not really sure what the implications of not having a preferred email
> address are.

That's a fair assumption. It's basically because the user never registered on Launchpad (person record was auto-created from an import probably).

Once you registered with us, you always have a preferred email address.

An alternative would be to return NotFound for people who fail the is_valid_person check. (That catches the case of not having a preferred email address.)

[Christian Reis (kiko)]

Hmm. When you say getUser where exactly does that code live? I'm not in favor of changing something as fundamental as is_valid_person unless we consider the effects carefully -- this sounds like something we should be doing special checks for in the callsite. No?

[Francis J. Lacoste (flacoste)]

It's the private xmlrpc code. I wasn't talking about modifying is_valid_person, but using it in getUser().

[Gary Poster (gary)]

I wonder if the increased/recent occurrences is another facet of the core openid-related bug 580461

[Tim Penhey (thumper)]

This code path no longer exists. Closing - with Invalid as this bug is now invalid due to no code. I couldn't mark it fix release in good conscience.