Thank you Scott, everything is clear now. 1.0.0RC5 provides the new logout methods, feel free to edit the docs (http://www.ja-sig.org/wiki/x/xhbP) if needed. PA
Scott Battaglia a écrit : > On Mon, Jun 30, 2008 at 1:40 PM, Pascal Aubry > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> > wrote: > > Hi Scott, > As always, correct me if I am wrong or not clear enough. > At first, *what we are talking about has nothing to do with > centralized Sign Out *(a logout request from another application): > indeed, in this case, the handleLogoutRequests() method is called, > the session killed and nothing else happens (in particular, no > redirection to the CAS server). > *We are talking of the application calling the logout() method*. > This method has one parameter -named url- the passed as the > service parameter to the CAS server (until 0.6.0). This parameter > should probably be renamed service for better understanding. > If I understood well, the PHP client application should be able to > pass the service parameter only, the url parameter only, both or > none. IMO, the only way to do this is to give 4 methods: > > > Yes, you can pass the service parameter, url parameter, both or none. > However, the behavior of what happens when you provide both depends on > the CAS server configuration. If service redirects are enabled, its > as if you passed only the service parameter. If they are disabled, > passing both acts as if you passed the url parameter. > > > * logout() > * logoutWithRedirectService($service) > * logoutWithUrl($url) > * logoutWithRedirectServiceAndUrl($service, $url) > > Calling logout() with no parameter (0.6 possibility) would print > an error saying that logoutWithRedirectService($service) should be > called in 1.0 in order to to get the old 0.6 behavior. > Now, what happens if you pass the service parameter only when the > redirection is disabled on the CAS server? What does the server > shows if it does not redirect? Just a page saying that the user > has been disconnected? > > It should show the normal CAS logout page. > > > > Now, what happens if you pass the service and the url parameters > when the redirection is enabled on the CAS server? Does the server > redirect and forget the url parameter? > > It should only do the redirect and ignore the url parameter. > > -Scott > > > Thanks, > PA > > Scott Battaglia a écrit : >> I'm attempting to consolidate this a little by copying your >> questions up here and responding to them (hopefully this doesn't >> make it confusing): >> >> > Ok. Since phpCAS does not know how the cas server behaves >> (redirects or >> > shows a link), it has to pass both url and service parameters. >> Can you >> > confirm this? >> >> It doesn't have to pass both. It only needs to pass the one >> who's behavior you need. If you want a url to be displayed them >> you pass using the url parameter. If you want a redirect (if the >> server has enabled it), then you use the service parameter. You >> don't want CAS choosing for you. >> >> > Just one last question: why does cas need two parameters? I >> feel that >> > the service parameter could be used instead of the url parameter >> > everywhere, and that the url parameter is not really needed. Am >> I wrong? >> > Are there any scenario where the two parameters could have >> different values? >> >> Its not a matter of whether they have different values. Its a >> matter of different behaviors. One redirects and one displays a >> link back. CAS won't make the choice for you. You get to choose >> whether you want to redirect (if the CAS server has enabled the >> option) or you merely want a link back displayed. Only having >> one parameter means that CAS has to decide what should happen >> when the point is that the application developer should be making >> the choice. >> >> -Scott >> >> >> >> -Scott Battaglia >> PGP Public Key Id: 0x383733AA >> LinkedIn: http://www.linkedin.com/in/scottbattaglia >> >> On Sun, Jun 29, 2008 at 9:28 AM, Pascal Aubry >> <[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]>> wrote: >> >> Scott Battaglia a écrit : >> > On Sun, Jun 29, 2008 at 5:22 AM, Pascal Aubry >> > <[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]> >> <mailto:[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]>>> >> > wrote: >> > >> > Scott Battaglia a écrit : >> >> CAS3 supports the url parameter for passing the value >> to the >> >> logout page for displaying "Click here to go back to your >> >> application." >> >> >> >> I can't speak for what CAS1 or CAS2 did. I don't >> believe there >> >> was an official way to do this sort of redirect, >> though I believe >> >> Yale had implemented a way unofficially. >> > I also believe that there was no official way to do it. >> Speaking >> > of what I know, the *service *parameter was used in the >> packages >> > esup-cas-server and esup-cas-quick-start (cas v2) to >> pass the >> > logout url to the cas server, i.e. the url the cas >> server should >> > redirect the user to after logout. The feature had been >> proposed >> > to the cas developers (Drew Mazurek was managing cas at >> this time >> > if I remember well) but never added, so class >> > edu.yale.its.tp.cas.servlet.Logout had been patched and >> the logout >> > feature added to 'our' cas distribution. >> > Now that cas v3 supports sign out, I think that one >> parameter only >> > should be used, but which one? Julien (thanks to him) >> had a look >> > at the cas sources and here is below what he saw. >> Scott, feel free >> > to correct us if we are wrong. >> > >> > The way the user is redirected after logout depends on the >> > parameter p:followServiceRedirects of the logout >> controller (cf >> > WEB-INF/cas-servlet.xml): >> > >> > * if true, cas uses parameter *service *(cf >> > >> >> https://www.ja-sig.org/svn/cas3/trunk/cas-server-core/src/main/java/org/jasig/cas/web/LogoutController.java) >> > to redirect the user automatically >> > * if false (by default), cas uses parameter *url >> *to present a >> > link after logout (cf >> > >> >> https://www.ja-sig.org/svn/cas3/trunk/cas-server-webapp/src/main/webapp/WEB-INF/view/jsp/default/ui/casLogoutView.jsp). >> > >> > According to >> > >> http://www.ja-sig.org/products/cas/overview/protocol/index.html >> > section 2.3.1, the *url *should be used only. >> > >> > >> > The specification states that the url parameter tells CAS >> what to >> > display on the logout page, so the CAS v3 is doing the >> correct behavior. >> > >> > >> > >> > I think that what we should do is: >> > >> > * make LogoutController.java use *url *instead of >> *service* >> > >> > The behavior of the LogoutController won't change. Its >> correct. url >> > is displayed and service redirects (if its turned on). >> Ok. Since phpCAS does not know how the cas server behaves >> (redirects or >> shows a link), it has to pass both url and service >> parameters. Can you >> confirm this? >> > >> > * >> > >> > >> > * make phpCAS use *url *to comply to the specs, and >> also use >> > *service *until release 1.1 >> > >> > Using url won't redirect you. Only service will. That's >> not going to >> > change. >> Understood. The service parameter has to be passed as well >> and will not >> be removed. >> > >> > * Let local adapters (such as Adam with his >> *destination >> > *parameter) patch phpCAS locally to also pass their >> > parameter at logout >> > >> No change here. >> Just one last question: why does cas need two parameters? I >> feel that >> the service parameter could be used instead of the url parameter >> everywhere, and that the url parameter is not really needed. >> Am I wrong? >> Are there any scenario where the two parameters could have >> different values? >> PA >> > >> > * Strongly invite phpCAS users to switch to the >> official cas >> > v3 asap. >> > >> > btw, http://developer.ja-sig.org/source/ does not >> respond this >> > morning. >> > >> > Yes, we're working on doing some testing of FishEye with >> Atlassian >> > and they want us to test it without the HTTP connector >> (which means >> > you guys can't see it). You can still do >> https://www.ja-sig.org/svn >> > I'm not sure unfortunately when we'll have it available to >> the public >> > again . You're the first one to notice (or at least say >> anything ;-)). >> > >> > -Scott >> > >> > >> > >> > PA >> > >> >> -Scott >> >> >> >> -Scott Battaglia >> >> PGP Public Key Id: 0x383733AA >> >> LinkedIn: http://www.linkedin.com/in/scottbattaglia >> >> >> >> On Sun, Jun 29, 2008 at 12:10 AM, Adam Moore >> >> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> >> wrote: >> >> >> >> So would I be correct in saying: >> >> >> >> CAS 1: ?url= >> >> CAS 2: ?destination= >> >> CAS 3: ?service= >> >> >> >> Scott Battaglia wrote: >> >>> CAS 3 will follow the service url for redirecting >> back if >> >>> its enabled on the LogoutController. If the other >> parameters >> >>> are there it will probably ignore them. >> >>> >> >>> -Scott >> >>> >> >>> -Scott Battaglia >> >>> PGP Public Key Id: 0x383733AA >> >>> LinkedIn: http://www.linkedin.com/in/scottbattaglia >> >>> >> >>> On Thu, Jun 26, 2008 at 3:57 PM, Pascal Aubry >> >>> <[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]> >> >>> <mailto:[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]>>> wrote: >> >>> >> >>> Adam Moore a écrit : >> >>> > I see in the logout method it is using >> ?service= for >> >>> logout url. >> >>> > Currently within another project I am >> working on >> >>> people have different >> >>> > parameters for the logout url. For me >> ?destination= >> >>> is what works. >> >>> > For others ?url= is what works and >> sometimes ?service= >> >>> works. Looking >> >>> > at the documentation for cas, it seems cas >> 1.0 uses >> >>> ?url=. The way we >> >>> > handled it in this project is to specify >> all three on >> >>> the logout url >> >>> > and the server can decide which one to use. >> >>> > >> >>> > So line 930 in the client.php file could >> look like this. >> >>> > >> >>> > $url = '?service=' . $url . '&destination=' >> . $url . >> >>> '&service=' . $url; >> >>> > >> >>> > Thoughts? >> >>> > >> >>> > Adam >> >>> Hi Adam, >> >>> I feel that passing the three parameters is >> the quick >> >>> and dirty way to >> >>> make it work. I did it for 1.0.0RC2, please test. >> >>> However, I think that one parameter should be >> enough. >> >>> What do CAS >> >>> developers think about it? >> >>> PA >> >>> >> >>> -- >> >>> http://perso.univ-rennes1.fr/pascal.aubry >> >>> >> >>> _______________________________________________ >> >>> Yale CAS mailing list >> >>> [email protected] >> <mailto:[email protected]> <mailto:[email protected] >> <mailto:[email protected]>> >> >>> http://tp.its.yale.edu/mailman/listinfo/cas >> >>> >> >>> >> >>> >> >> ------------------------------------------------------------------------ >> >>> _______________________________________________ >> Yale CAS >> >>> mailing list [email protected] >> <mailto:[email protected]> >> >>> <mailto:[email protected] >> <mailto:[email protected]>> >> >>> http://tp.its.yale.edu/mailman/listinfo/cas >> >> >> >> _______________________________________________ >> >> Yale CAS mailing list >> >> [email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>> >> >> http://tp.its.yale.edu/mailman/listinfo/cas >> >> >> >> >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ Yale >> CAS mailing >> >> list [email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>> >> >> http://tp.its.yale.edu/mailman/listinfo/cas >> > >> > >> > -- >> > http://perso.univ-rennes1.fr/pascal.aubry >> > >> > >> > _______________________________________________ >> > Yale CAS mailing list >> > [email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>> >> > http://tp.its.yale.edu/mailman/listinfo/cas >> > >> > >> > >> >> ------------------------------------------------------------------------ >> > >> > _______________________________________________ >> > Yale CAS mailing list >> > [email protected] <mailto:[email protected]> >> > http://tp.its.yale.edu/mailman/listinfo/cas >> > >> >> >> -- >> http://perso.univ-rennes1.fr/pascal.aubry >> >> _______________________________________________ >> Yale CAS mailing list >> [email protected] <mailto:[email protected]> >> http://tp.its.yale.edu/mailman/listinfo/cas >> >> >> ------------------------------------------------------------------------ >> _______________________________________________ Yale CAS mailing >> list [email protected] <mailto:[email protected]> >> http://tp.its.yale.edu/mailman/listinfo/cas > > > -- > http://perso.univ-rennes1.fr/pascal.aubry > > > _______________________________________________ > Yale CAS mailing list > [email protected] <mailto:[email protected]> > http://tp.its.yale.edu/mailman/listinfo/cas > > > ------------------------------------------------------------------------ > > _______________________________________________ > Yale CAS mailing list > [email protected] > http://tp.its.yale.edu/mailman/listinfo/cas > -- http://perso.univ-rennes1.fr/pascal.aubry _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
