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
