Hi Jerome, i answer in the body below :)
> Hi Frédéric, > > I update my CAS openid demo and both modes (smart and dumb) work perfectly. > > Regarding the delegates pattern, indeed it's a good pattern but I was > wondering if there was another way to add the smart mode. I think you could > have created a SmartOpenIdController by extending the > ServiceValidateController and added the specific logic for the smart mode : > in the handleRequestInternal method, check if the "openid.mode" is > "associate" and if so, create an association response otherwise call the > super.handleRequestInternal method (dumb mode). What do you think ? Actually that was my first pick, but if i remember correctly i could not override the handleRequestInteral method (maybe private or final don't remember exactly). I'm sick and tired, back from devoxx, but i'll check again why. But actually i do prefer a separate controller, which is more like a hanshake controller than a validate controller. > In addition, even if I like the option of enabling/disabling the smart mode, > does it make sense ? It certainly would be better to always have the smart > mode enabled. > Agreed, smart mode is the preferable way to use openid, spec says, and smart mode handles dumb requests also, but i didn't want to remove an existing feature. That could be a devteam vote. > As you add the openId association views in cas-server-webapp module, you > should also add their definitions in the protocol_views.properties file. Yes thought i did that, my bad :) > > Configuring all the beans in the different Spring contexts is a bit painful > and error-prone and I agree completely with you that it could be a real > improvement to find an easy way to enable a module in CAS server (for example > by moving the cas-server-support-openid.xml context file from > unused-spring-configuration directory to spring-configuration directory). > You're right : it's not just about creating beans, it's also about injecting > / setting them in another beans and it's not so easy (as Spring scopes are > also different between applicationContext.xml and cas-servlet.xml). Moreover, > you have the additionnal initial steps in login webflow needed by the OpenId > module. Don't hesitate to give it a try for the OpenId module if you see a > way ! > Agreed again. I tried with my howto on dumb openid (see casum) to make it clear, and even smart mode is just a little bit more conf to make, making it as simple as moving one file would be a great step forward. To be honest that's coming next on my todo :) > About the OpenId module more generally, I think that the > OpenIdProviderController which is defined by default in CAS server to declare > the OpenId endpoint could be moved in the OpenId module as I don't see the > use to have an OpenId endpoint declared without the logic to handle OpenId > authentication process. 100% agreed. We were both surprised to see it in core configuration. That's another bullet on my todo, along with adding support for delegate endpoints, yadis discovery and...openid 2. But about this controller, moving it into openid module and removing its declaration from core context could be a simple commit to add to my pull request. Frederic > > Best regards, > Jérôme > > -- > You are currently subscribed to cas-dev@lists.jasig.org as: > esnault.frede...@gmail.com > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
