On 13/02/2013 3:49 a.m., Alexandre Chappaz wrote:
Hi,
I know this is a subject that has been put on the table many times,
but I wanted to share with you my experience with squid + sharepoint.
Squid Cache: Version 3.2.7-20130211-r11781
I am having an issue with autehtication :
when accessing the sharepoint server, I do get a login/pw popup, I can
login and see some of the pages behind, but when doing some operation,
even though I am supposed to be logged in, the autentcation popup
comes back.
Here is what I find the the access log :
1360679927.561 43 X.X.X.X TCP_MISS/200 652 GET
http://saralex.hd.free.fr/_layouts/images/selbg.png -
FIRSTUP_PARENT/192.168.100.XX image/png
URL #1. No authentication required. non-pinned connection used.
1360679928.543 37 X.X.X.X TCP_MISS/401 542 GET
http://saralex.hd.free.fr/_layouts/listform.aspx? -
PINNED/192.168.100.XX -
URL #2. Sent to upstream on already authenticated+PINNED connection.
Upstream server requires further authentication details.
--> authentication challenge?
1360679928.665 58 X.X.X.X TCP_MISS/401 795 GET
http://saralex.hd.free.fr/_layouts/listform.aspx? -
PINNED/192.168.100.XX -
URL #2 repeated. Sent to upstream on already authenticated+PINNED
connection. Upstream server requires further authentication details.
--> possibly authentication handshake request?
1360679928.753 229 X.X.X.X TCP_MISS/200 20625 GET
http://saralex.hd.free.fr/_layouts/images/fgimg.png -
FIRSTUP_PARENT/192.168.100.XX image/png
URL #3. No authentication required. non-pinned connection used.
1360679928.788 68 X.X.X.X TCP_MISS/302 891 GET
http://saralex.hd.free.fr/_layouts/listform.aspx? -
PINNED/192.168.100.XX text/html
URL #2 repeated. Sent to upstream on already authenticated+PINNED
connection. Upstream server redirectes the client to another URL.
--> authentication credentials accepted.
1360679928.921 45 X.X.X.X TCP_MISS/401 542 GET
http://saralex.hd.free.fr/Lists/Tasks/NewForm.aspx? -
PINNED/192.168.100.XX -
URL #4. Sent to upstream on already authenticated+PINNED connection.
Upstream server requires further authentication details.
--> authentication challenge?
1360679929.019 47 X.X.X.X TCP_MISS/401 795 GET
http://saralex.hd.free.fr/Lists/Tasks/NewForm.aspx? -
PINNED/192.168.100.XX -
URL #4 repeated. Sent to upstream on already authenticated+PINNED
connection. Upstream server requires further authentication details.
--> possibly authentication handshake request?
1360679929.656 81 X.X.X.X TCP_MISS/200 1986 GET
http://saralex.hd.free.fr/_layouts/images/loadingcirclests16.gif -
FIRSTUP_PARENT/192.168.100.XX image/gif
URL #5. no authentication required. non-pinned connection used.
1360679930.417 1322 X.X.X.X TCP_MISS/200 130496 GET
http://saralex.hd.free.fr/Lists/Tasks/NewForm.aspx? -
PINNED/192.168.100.XX text/html
URL #4 repeated. Sent to upstream on already authenticated+PINNED
connection. Upstream server provides the display response.
--> authentication credentials accepted.
1360679934.618 53 X.X.X.X TCP_MISS/401 542 GET
http://saralex.hd.free.fr/_layouts/iframe.aspx? -
PINNED/192.168.100.XX -
1360679934.729 51 X.X.X.X TCP_MISS/401 795 GET
http://saralex.hd.free.fr/_layouts/iframe.aspx? -
PINNED/192.168.100.XX -
could this be a pinning issue?
Is V2.7 STABLE managing these things in a nicer way?
Unknown. But I doubt it. This is Squid using a PINNED connection to
relay traffic to an upstream server. That upstream server is rejecting
the clients delivered credentials after each object. There is no sign of
proxy authentication taking place, this re-challenge business is all
between client and upstream server.
You need to look at whether these connections are being pinned then
closed, and why that is happening. Squid-3.2 offers debug level 11,2
which will give you a trace of the HTTP headers to see if the close is a
normal operation from either end. Or whether they are keep-alive by
Squid and the upstream server is just constantly forcing re-auth (it
happens).
Amos
