© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
a60fb26
(Get the code!)
I asked Mark for guidance on this issue; here's his response:
-------
You can find the basic discussion at
https:/
and the best problem descriptions at
https:/
- and -
https:/
So, with that in mind, my reproduction steps are:
-------
1. Set up an identity in the manager to be something like this:
Display Name: Messed Up Identity
Issuer: <email address hidden>
Username: mark
Password: <whatever>
2. Connect to a new service using ABFAB, so that the identity selector
is shown.
3. Select "Messed Up Identity"
Expected results:
-------
The identity selector should send the identity "<email address hidden>@mark", which should fail all authentications.
Actual results:
-------
The identity is not sent to the server. The moonshot libraries look for a file named .gss_eap_id (which was used before the identity selector existed), which suggests that the identity selector did not return an identity to the moonshot libraries.
Were I to debug this, I'd start looking towards the end of the lifecycle of a request for an identity, where the user has already made a selection. Somewhere along the line, the user selection is transformed into a GSS credential, and that's where this is likely failing. What I don't know is whether that's happening in the selector code, or in the library code.
If the selector hands back strings for the library to transform into the GSS credential, then I don't know that there's a lot else for the library to do at that point. It is dealing with some unusable data, and tries to fall back, and fails when it can't.
If the selector hands back the GSS credential, then there's probably a call in there to gss_import_name that is failing, because the name string (<email address hidden>@mark) does not meet the expected format. I would guess that the selector code assumes that call will always succeed.
Were I to fix this, I'd work this along two axes. First, I'd look to constrain the input field to disallow the presence of "@" or "/", which are used as delimiters that we aren't looking to have. Second, I'd look to make sure that the selector never tries to put together an identifier that has two "@" in it, even if such an identifier already got into its database somehow.