If the CAS client isn't properly constructing the url for redirection and service ticket validation (they should be the same thing) then there's a bug in the CAS client. Clients should construct and URLencode the entire URL and not just part of it. They should do it for both redirection and ticket validation.
I don't know much about the AuthCAS client to state with confidence what it is doing. Any chance you can look at using mod_auth_cas, which we know works (right, Matt? ;-))? -Scott Battaglia PGP Public Key Id: 0x383733AA LinkedIn: http://www.linkedin.com/in/scottbattaglia On Mon, Sep 15, 2008 at 8:16 PM, Michael Dalby <[EMAIL PROTECTED]> wrote: > When I URL encode it I get something like this: > > > https://MyDomain/cas/login?service=https%3A%2F%2FAnotherDomain.com%3A1443%2FMyPage%2Fshowall%3Da > > Or, if I want showall to be a parameter of the service: > > > https://ssotest1.uoregon.edu/cas/login?service=https%3A%2F%2Fnac-pf2.uoregon.edu%3A1443%2Fhelpdesk%2F&showall=a > > if I want CAS to interpret the parameter. If I don't encode 'showall' my > service is correct and CAS will validate the ticket. However, I don't > get the parameter passed back to me. If I encode 'showall' it gets > passed back to me on the redirect, but CAS won't validate the ticket > because my service doesn't match (because a GET is included in it). It > seems to be a Catch-22. > > I've also tried > > https://ssotest1.uoregon.edu/cas/login?showall=a&service=https://nac-pf2.uoregon.edu:1443/helpdesk/ > > where there is no ambiguity because service is the last parameter to > appear, however this works the same as just not encoding 'showall'. CAS > will validate the service ticket, but not return the variable. > > Matt Smith wrote: > > I believe the service parameter used for authentication must exactly > > match the service parameter used for authentication - in this case, > > that would require that the parameters ('showall') are maintained for > > validation. > > > > I suggest you fully encode that URL, though, just to be safe. For > > demonstration of the problem, imagine adding a parameter after > > showall, perhaps "page=20". This would make your current URL: > > > > > https://MyDomain.com/cas/login?service=https://AnotherDomain.com:Port/MyPage/?showall=a&page=20 > > > > Is "page=20" a parameter to the URL at "cas/login", or it is part of > > your "service=" parameter ? > > > > To avoid the ambiguity, encode your URL. > > > > HTH, > > -Matt > > > > On Mon, Sep 15, 2008 at 4:53 PM, Michael Dalby <[EMAIL PROTECTED]> > wrote: > > > >> Ahh, I actually believe the issue was that final ampersand. When I > >> change the URL to read > >> > >> > https://MyDomain.com/cas/login?service=https://AnotherDomain.com:Port/MyPage/?showall=a > >> > >> where the service variable now contains a valid URL due to the final > >> '?'. It returns the showall variable, however the service ticket doesn't > >> validate. Instead I get the error > >> > >> " > >> Failed to validate Service Ticket <ST> : ticket '<ST>' does not match > >> supplied service. The original service was > >> 'https://AnotherDomain:Port/MyPage/?showall=a' and the supplied service > >> was 'https://AnotherDomain:Port/MyPage/'. > >> " > >> I know that our CAS implementation requires you to register your > >> service. Could this be the problem? I have this problem both with and > >> without URL encoding (though thanks for the tip, the encoding is going > >> to be critical since I have to do everything in GETs now). > >> > >> -Mike > >> > >> > >> Matthew J. Smith wrote: > >> > >>> Try encoding the service parameter: > >>> https%3A%2F%2FAnotherDomain.com%3APort%2FMyPage%2F%3Fshowall%3Da > >>> > >>> (note that I encoded the "&" as a "?", to make a valid encoded URL). > >>> > >>> Also, assuming you are doing this under Apache, you may want to check > >>> out mod_auth_cas, which does all this for you. > >>> > >>> -Matt > >>> > >>> Michael Dalby wrote: > >>> > >>>> I'm using the AuthCAS-1.3.1 perl module. As far as I can tell it > doesn't > >>>> have any function that appends the CGI parameters to the URL as a GET > >>>> request. Iterating through all of the CGI parameters, and appending > them > >>>> manually isn't hard. Though, I think I may have the syntax wrong > because > >>>> my CAS server is not returning these variables. When I redirect the > user > >>>> to CAS to get a service ticket the url looks something like this: > >>>> > >>> > https://MyDomain.com/cas/login?service=https://AnotherDomain.com:Port/MyPage/&showall=a > >>> > >>> > >>>> I had expected the CAS server to return the "showall" parameter back > to > >>>> me. However, the only parameter that is defined when the user is > >>>> redirected back to me is the service ticket. > >>>> > >>>> The help is greatly appreciated! Thanks, > >>>> > >>>> -Mike > >>>> > >>>> Matt Smith wrote: > >>>> > >>>>> Michael-- > >>>>> Unless I misunderstand, it sounds like you are writing your own CAS > >>>>> client. Have you considered using any of the existing clients, which > >>>>> exist for a large number of platforms and languages? I believe they > >>>>> all handle GET persistence for you, and POST persistence is on at > >>>>> least a couple client roadmaps. > >>>>> > >>>>> That being said: > >>>>> 1) GET persistence is easily achieved by keeping the current query > >>>>> attached to the URL when encoding the service parameter in the > >>>>> redirect to the CAS server. > >>>>> > >>>>> 2) POST persistence is harder, since redirects are performed as GETs. > >>>>> You would have to cache the original POST, redirect, recognize the > >>>>> return (GET), and convert the GET request into a POST, with the > >>>>> original POST'd content. > >>>>> > >>>>> HTH, > >>>>> -Matt > >>>>> > >>>>> On Fri, Sep 12, 2008 at 12:47 PM, Michael Dalby > >>>>> > >>> <[EMAIL PROTECTED]> wrote: > >>> > >>>>>> I have a question about getting CGI variables and using CAS. I'm not > >>>>>> sure if there are different implementations of CAS, but the way we > are > >>>>>> currently using it requires a different service ticket for every > http > >>>>>> request to my CGI. When a user requests the page, I check for a > >>>>>> > >>> "ticket" > >>> > >>>>>> variable in the URL, if they don't have it I 302 redirect them to > our > >>>>>> CAS server who redirects them back to my page with the "ticket" > >>>>>> > >>> variable > >>> > >>>>>> appended to the URL. This means that if a user attempts to GET or > POST > >>>>>> variables to my page, I lose them because the redirection to and > from > >>>>>> CAS. I'm hoping that I'm just doing something wrong here, because > the > >>>>>> alternative involves a lot of hacks to get this working. Thanks > >>>>>> > >>> much for > >>> > >>>>>> the help! > >>>>>> _______________________________________________ > >>>>>> 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 > >>>> > >>> > >> _______________________________________________ > >> 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 > >> > >> > > > > > > > > > > _______________________________________________ > 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
