Usually this kind of problems is only seen if https requests takes a
different path in your network than http.
I.e. if you are proxying http but not https. or forwarding http to a
parent but not https.
The cause is usually that the web server embeds the requesting IP in
it's session identifiers, and rejects the session when seeing different
source IPs for http and https requests from what should be the same
client..
Regards
Henrik
tis 2008-01-15 klockan 11:37 -0500 skrev Aaron Allen:
> As a test, I passed our squid proxy data up to Paros web proxy. Effectively doing a MITM attack on our SSL data so I could see the HTTP headers. Interestingly, when I do this, I am able to login to the site. Obviously I don't see anything unusual in the HTTP headers as everything loads fine. But, once I take Paros out of the mix the problem starts again.
>
> I am completely out of ideas at this point. Has anyone else experienced anything similar?
>
> -----Original Message-----
> From: Rob Hutton [mailto:rob@getuwired.us]
> Sent: Monday, January 14, 2008 2:48 PM
> To: squid-users@squid-cache.org
> Cc: Aaron Allen
> Subject: Re: [squid-users] Unable to login to website when accessed via squid
>
> We ran into this before with a site that on login was responding to a post,
> with a query variable that contained the session ID, with a redirect. I
> don't remember what the differences in behavior were, but they were obvious
> once we did some packet capturing and compared the two conversations.
>
> It turned out, the site was doing something strange that did not break with
> the browser, but squid didn't like it. If I remember right, the redirect did
> not contain the query string, but the browser would send it to the new url
> with the subsequent request while squid redirected to the new location sans
> the query string.
>
> Thanks,
> Rob
>
> Rob Hutton
> Service Manager
> GetUWired
> www.getuwired.us
> (877) 236-9094
>
>
> On Monday 14 January 2008 12:06:47 Aaron Allen wrote:
> > I have exhausted all my ideas on this one, so I am coming to you all for
> > new ones.
> >
> > I am currently running Squid+Dansguardian as an explicit proxy on our
> > network. All traffic is passed through the proxy (including SSL using
> > CONNECT) after NTLM authentication with squid.
> >
> > There is one website that our users are unable to login to when accessing
> > the site via the proxy (if I manually bypass the proxy, the login works
> > perfectly every time). I have also bypassed Dansguardian and the problem
> > is still present when just using Squid as the proxy.
> >
> > As a note, the entire site is SSLed, so all the data is done via CONNECT.
> >
> > The site uses a web based login form. When the login form is submitted the
> > browser receives a "302 - Moved Temporarily" status from the server
> > redirecting it to the welcome page of the site (and passing along the login
> > credentials). However, whenever the site is accessed via the proxy, the
> > welcome page returns an additional "302 - Moved Temporarily" status
> > redirecting the user back to the original login form.
> >
> > My first inclination is that it was a problem with the way this particular
> > site was setup. I have contacted the owners of the site and they are
> > unaware of any problems and don't know why we would be getting redirected
> > back to the original login page. Additionally, is there any reason that
> > the HTTPS request coming from the web browser via squid would look any
> > different to the web server than the request that is not passed through
> > squid?
> >
> > Of course I've checked log files and don't see anything unusual or anything
> > being DENIED.
> >
> > I am running out of ideas, so if anyone has any pointers, I would love to
> > hear them.
> >
> > Thanks!
> > Aaron
>
>
This archive was generated by hypermail pre-2.1.9 : Fri Feb 01 2008 - 12:00:05 MST