Hi all, i'm ready for a pull request. I committed and merged my devs into my forked master branch. I kept away the configuration files, so i will need a way to explainw how to make it work. What is the process for this? I can first : create a pul request (by the way PR 61 should be gorotten, as my new one will be complete). then : create a doc (CASUM page, mail here) ? Just tell me how you want things to be done
Frederic On Fri, Apr 13, 2012 at 9:44 PM, Frederic Esnault < [email protected]> wrote: > Damned forgot to say one thing. > Choosing between smart and dumb mode is now easy as 1-2-3. > > Dumb mode conf (ignoring some stuff, like requestparams extractor, and so > on...just cas-servlet conf: > > <bean id="handlerMappingOpendId" > > class="org.jasig.cas.support.openid.web.support.OpenIdPostUrlHandlerMapping"> > <property name="order" value="2"/> > <property name="mappings"> > <props> > <prop key="/login">delegatingController</prop> > </props> > </property> > </bean> > > <bean id="delegatingController" > class="org.jasig.cas.web.DelegatingController" > p:delegates-ref="delegateControllers"/> > > <util:list id="delegateControllers"> > <ref bean="openIdValidateController"/> > </util:list> > > Smart mode conf : > <bean id="handlerMappingOpendId" > > class="org.jasig.cas.support.openid.web.support.OpenIdPostUrlHandlerMapping"> > <property name="order" value="2"/> > <property name="mappings"> > <props> > <prop key="/login">delegatingController</prop> > </props> > </property> > </bean> > > <bean id="delegatingController" > class="org.jasig.cas.web.DelegatingController" > p:delegates-ref="delegateControllers"/> > > <util:list id="delegateControllers"> > *<ref bean="smartOpenIdAssociationController"/>* > <ref bean="openIdValidateController"/> > </util:list> > > *<bean id="smartOpenIdAssociationController" > class="org.jasig.cas.support.openid.web.mvc.SmartOpenIdController"* > * > p:centralAuthenticationService-ref="centralAuthenticationService" > p:serverManager-ref="serverManager"* > * p:successView="casOpenIdAssociationSuccessView" > p:failureView="casOpenIdAssociationFailureView" />* > > Easy right ? :) > > Frederic > > On Fri, Apr 13, 2012 at 9:39 PM, Frederic Esnault < > [email protected]> wrote: > >> Some more news. >> >> As i expected, dumb openid mode has been broken by my devs. That was >> predictable (mainly because we know use real association handles with smart >> openid and not CAS service ticket ids). >> And as I also expected, fixing the dumb mode was really easy (just ask >> the openid4java serverManager if he has an association with the received >> handle (which is null in case of dumb mode), and of course if we have one, >> ask if it's expired). If in dumb mode, just replacing the assoc_handle of >> the auth success response with the cas ticket id does the trick (consumer >> has no association, so calls back CAS to validate, which validates the cas >> ticket). In smart mode, cas ticket is immediatly validated when auth >> success response is sent, preventing further usage of the assoc handle >> (also handled by server manager - double security :) ). >> >> I'm now going to check unit tests, fix them and add some more to check >> spec compliance, and my code of course :) >> >> Shall i say it again ? "Stay tuned !" >> >> Frederic >> >> >> On Fri, Apr 13, 2012 at 9:53 AM, Frederic Esnault < >> [email protected]> wrote: >> >>> Told you to stay tuned :) >>> Yesterday i managed to get a successful authentication using Smart >>> OpenId mode. >>> >>> I already refactored some of my code. I also refactored the preivous >>> dumb mode code, which i expect not to be working anymore (i would be >>> surprised if it did). >>> So i know have to adapt the dumb mode code to make it work along with >>> the smart mode one, which will not be very hard. >>> I introduced a dependency on the openid4java lib to the >>> cas-server-support-openid. It would be useless and strange to reimplement >>> methods provided by this lib (signing, generating a response, etc...). >>> Of course i'll have to fix tests and add some more. >>> >>> I'll keep you informed of the progress. >>> >>> Frederic >>> >>> >>> On Wed, Apr 11, 2012 at 1:48 PM, Frederic Esnault < >>> [email protected]> wrote: >>> >>>> Thanks for the answer Bill. >>>> I'm quite confident that i can finish the implementation/unit >>>> test/refactor before may 4th. >>>> Of course i'll try to finish sooner, but i won't push my changes before >>>> i'm happy with the architecture and confident about the spec implementation >>>> and it's test coverage. >>>> I'll let you all informed, so stay tuned :) >>>> >>>> Frederic >>>> >>>> >>>> On Wed, Apr 11, 2012 at 1:31 PM, William G. Thompson, Jr. < >>>> [email protected]> wrote: >>>> >>>>> > So as i'm not yet done, and given the code review needed, i'm >>>>> wondering if >>>>> > it can make it into the 3.5.RC1, and if yes, what would be the >>>>> deadline for >>>>> > the pull request to be issued? >>>>> >>>>> The sooner the better! :) >>>>> >>>>> Given your description of the changes, perhaps a week would be >>>>> reasonable? May 4th for the pull request? May 11th is the RC1 >>>>> deadline. >>>>> >>>>> Bill >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Apr 11, 2012 at 4:09 AM, Frederic Esnault >>>>> <[email protected]> wrote: >>>>> > Hi all, >>>>> > >>>>> > I saw the planning for the releases of CAS 3.5 (RC1 and RELEASE). >>>>> > I was wondering what was the deadline for a pull request, about the >>>>> > implementation of OpenId Smart mode. >>>>> > I'm working on it currently, most of it being done. I'm facing a >>>>> problem of >>>>> > a signature check failure at the end of the process, which is >>>>> perfectly >>>>> > normal as the association handle is not the same. I still have a bit >>>>> of work >>>>> > to sign correctly CAS requests. >>>>> > After that i'd like to perform a little bit of refactoring, and of >>>>> course >>>>> > unit test my components. >>>>> > I also introduced a DelegatingController (similar to spring security >>>>> or >>>>> > spring mvc delegating components), using a canHandle method to check >>>>> if a >>>>> > controller is able to handle a request. This was needed to allow >>>>> differents >>>>> > behavior to be mapped on the same url (/login). >>>>> > The ServiceValidateController now implements a new interface >>>>> > (DelegateController, defining the canHandle method), and implements >>>>> it by >>>>> > answering true. >>>>> > This allows this kind of mapping (simplified xml) : >>>>> > >>>>> > <util:list id="delegates"> >>>>> > <entry key="smartOpenIdController" ref="smartOpenIdController"/> >>>>> > <entry key="serviceValidateContrller" >>>>> ref="serviceValidateController"/> >>>>> > </util:list> >>>>> > >>>>> > <bean id="delegatingController" class="o.j.c.w.DelegatingController"> >>>>> > <property name="delegates" ref="delegates"/> >>>>> > </bean> >>>>> > >>>>> > And the following handler mapping : >>>>> > >>>>> > <prop key="/login">delegatingController</prop> >>>>> > >>>>> > >>>>> > This is a small refactoring of CAS infrastructure, and do not break >>>>> usual >>>>> > behavior but will need a code review on your side to be approved (or >>>>> > rejected). >>>>> > >>>>> > So as i'm not yet done, and given the code review needed, i'm >>>>> wondering if >>>>> > it can make it into the 3.5.RC1, and if yes, what would be the >>>>> deadline for >>>>> > the pull request to be issued? >>>>> > >>>>> > Frederic >>>>> > >>>>> > -- >>>>> > You are currently subscribed to [email protected] as: >>>>> [email protected] >>>>> > To unsubscribe, change settings or access archives, see >>>>> > http://www.ja-sig.org/wiki/display/JSG/cas-dev >>>>> >>>>> -- >>>>> You are currently subscribed to [email protected] as: >>>>> [email protected] >>>>> To unsubscribe, change settings or access archives, see >>>>> http://www.ja-sig.org/wiki/display/JSG/cas-dev >>>>> >>>>> >>>> >>> >> > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
