-Sean On Monday, May 7, 2012, Jasha Joachimsthal wrote:
> In the integration test runs the openId login fails often because > myopenid.com seems to be down a lot. Then I took a closer look to our > current handling of the openId account and found a few flaws: > > We store the openId identification as user name and have filled in its > password in the demo setup. You can also login with the username/password > form without going to myopenid.com > A workaround is replacing the current password with the hashed version of a > long random password. Is there any way to tell the user that they are configured to use openId and to log in that way instead of username/password? Do we need to support both an OpenId login and a username/password login for an OpenId user? > The username is also used in the user profile url. The profile url > > http://localhost:8080/portal/app/person/http://rave2011.myopenid.com/?referringPageId=13returns > an empty page. I tried URL encoding the user name (can't harm to do > that anyway), but the application container seems to refuse the %2F (/) in > the URL and responds with a 400-bad request before it reaches the webapp. > We can fix this by using a different user name (can be as simple as > replacing the slashes with underscores) and store the openId url in the > openId field of the person table. Might need to doubly URL encode. Underscores seems like an acceptable workaround if URL escaping doesn't work, but what would a username that contains an underscore look like and behave? > > The current implementation needs an existing account in the person table, > which means you first need to create an account and then log in with your > openId. I assume the real use case is that a user profile is created upon > first login through the openId provider. This can be done by letting the > DefaultUserService > implement AuthenticationUserDetailsService<OpenIDAuthenticationToken> (or > extend the DefaultUserService and implement this interface) and handle the > openId login in the method "public UserDetails > loadUserDetails(OpenIDAuthenticationToken token)" with the values in the > token. > The nasty thing here is that we require a unique email address for a user > account but that there is no standardisation in openId attributes :\ For > Yahoo and Google I managed to find the right attribute exchange for the > email address, but not for openid-provider.appspot.com. Is there any way to prompt the user to verify their discovered email or enter in an undiscovered email as part of that account creation process? > > Jasha Joachimsthal > > Europe - Amsterdam - Oosteinde 11, 1017 WT Amsterdam - +31(0)20 522 4466 > US - Boston - 1 Broadway, Cambridge, MA 02142 - +1 877 414 4776 (toll free) > > www.onehippo.com >
