On Mon, Jun 30, 2008 at 1:40 PM, Pascal Aubry <[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]> wrote: > >> Scott Battaglia a écrit : >> > On Sun, Jun 29, 2008 at 5:22 AM, Pascal Aubry >> > <[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]>> 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]>> 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]> >> >>> 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 >> >> >> >> _______________________________________________ >> >> 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 >> > > ------------------------------ > _______________________________________________ > Yale CAS mailing [EMAIL PROTECTED]://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 > >
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
