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
