I was going full-tilt into refactoring the OpenID support in Acegi. Unfortunately I got held up with home and work (gotta have your priorities in order). There are few central points that I'm focusing on right now...
- Replace the JanRain support with OpenId4Java.
- Replace the Servlet that is in there with an AuthenticationProcessingFilter based approach.
- Try and get some form of integration into the contacts sample.
The JanRain library is all but deceased, and it doesn't seem to support redirects anway. The OpenId4Java library seems to be the most active, and properly supports redirects and discovery. The Servlet that is in there now is well intended but doesn't mesh with the overall architecture in Acegi.
I'm going to try and get this stuff ramped up pretty quickly. Since
Ben Alex is starting rumors he's going to be talking about it at
Spring One.
4 comments:
Brilliant! I was just about to write you an email wondering why you'd chosen to use JanRain over OpenID4Java.
FYI My site http://www.myhippocampus.com is currently using this, and it's working great. I replaced the servlet with a Spring MVC controller, but other than that it was a pretty simple drop-in affair.
If you'd like any help with this or want feedback I'd be happy to help out.
Thanks.
-Jeff
Thanks for the comment Jeff.
Janrain is in there currently because it was part of the contribution.
Rigor mortis seemed to be setting in on Janrain so I started an effort to use OpenId4Java. Unfortunately it's still on my laptop and I haven't had a chance finish it up (it is close though).
I was looking over your blog, I see you had some trouble with the servlet in there as well. I am working on removing that too.
Hopefully I can get the new stuff into Subversion soon and you can have a look at it.
Sounds great Ray. I'll try to remember to check the sandbox.
Now that I think of it, there is one other change I made.
In JanRainOpenIDConsumer it sets the trustRoot with
req.getServerName()
For some reason req.getServerName() always returns "localhost" for me. Some misconfiguration on my part? Anyway I was in a situation where it failed once deployed bc localhost wouldn't match my domain. My solution was to dependency inject the trustRoot string using a HostPrecedingPropertyPlaceholderConfigurer
Anyway I'd find it useful if the ability to set the trustRoot made it in there (though I'd understand if not.)
Thanks for the idea, I'll see if I can fit it in to the Oid4j stuff.
Are you setup up with Apache in front of your app server or something like that?
Post a Comment