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 > -- [EMAIL PROTECTED] Key ID:D6EEC5B5 _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
