Get the 'TamperData' extension for firefox. Once you've installed it, go to the 'tools' menu, and select 'TamperData'. It'll pop up a window. Now go back to browsing. That TamperData window will record the request and response headers of everything you do. (You don't need to click the 'Start Tamper' button unless you want to *edit* the headers)
That's the best option I know of, using a proxy is awkward in this case because of the redirects, and using etherreal etc is no use for SSL. I have no idea how people who are stuck on IE cope with problems like this :) Cheers Baz On 3/30/06, Lucas Opara <[EMAIL PROTECTED]> wrote: > Setting proxyName and proxyPort in tomcat 4 connector works!!! > Thanks a lot Baz!! You saved my life ;-) > > About the location header and the request header, dunno how to check if they > are correct and which one is not... Any idea how I could check this? > > cheers, > > Lucas. > > > On 3/30/06, Baz <[EMAIL PROTECTED]> wrote: > > > Any chance you can get hold of the Host: header that came in with this: > 13:56:46,799 DEBUG ChannelProcessingFilter:157 - Request: > https://cn1983:7443/CreditsWebApp/html/authentication/debug.jsp > ; > ConfigAttributes: [REQUIRES_SECURE_CHANNEL] > > ... and the Location: header sent to you by CAS? (the Location header > should be like: https://cn1983:8443/... and the Host header needs to > be cn1983:8443 ; if the first one's wrong the bug is in CAS, if the > second one's wrong the bug is in the browser. > > In any case, you ought to be able to work around this on tomcat: set > proxyHost and proxyPort for your application: > http://tomcat.apache.org/tomcat-4.1-doc/proxy-howto.html > > ... even though you're not using a proxy, this *should*[1] force tc to > pass your app the correct serverName/serverPort. > > Failing that: you can add your own servlet filter that passes a > HttpServletRequestWrapper down the chain, with the correct host and > port; that bandaid should get your release out the door. > > Cheers, > Baz > > [1] I say *should*, but in the past and the tomcat people refused to > fix bugs with the port not being set: > http://issues.apache.org/bugzilla/show_bug.cgi?id=11748 > (NB even though they said the buggy connector was deprecated, the code > with the bug was copied directly into the new connector) I don't know > if things have moved on since then, but you're using TC4 for the > application so this is likely to hit you. > > On 3/30/06, Lucas Opara <[EMAIL PROTECTED]> wrote: > > I have a strange bug with cas and acegi. > > > > I have configured 2 tomcats server on the same machine called cn1983. > > A tomcat 4.1.29 for hosting my web application protected by acegi/CAS. > > A tomcat 5.0.28 for hosting CAS.war. > > > > tomcat 4 uses port 8443 for SSL. > > tomcat 5 uses port 7443 for SSL. > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmdlnk&kid0944&bid$1720&dat1642 > _______________________________________________ > Home: http://acegisecurity.org > Acegisecurity-developer mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer > > ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 _______________________________________________ Home: http://acegisecurity.org Acegisecurity-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
