Henk-Jan,
If you are willing to run up a test copy of squid on a spare machine, for you to use (it's not stable code - it is likely to be
part of squid 2.5) you could try the auth_rewrite branch of squid. It has a bottom up rewrite of squid's internal authentication
mechanisms. I left the basic specifics largely untouched, but I'm more than happy to dig into them.. If you wanted to try it out
it's available from http://squid.sourceforge.net/
DO NOT replace your current production squid with it. I'm suggesting you you up a local copy and that you test yourself against it
to see how it goes.
Rob
----- Original Message -----
From: "Henk-Jan Kloosterman" <proxy@kloosterman.org>
To: "Henrik Nordstrom" <hno@hem.passagen.se>
Cc: <squid-users@ircache.net>
Sent: Saturday, December 23, 2000 2:39 AM
Subject: Re: [SQU] Authenticate problem:
>
>
> > Henk-Jan Kloosterman wrote:
> >
> > > > The browser always authenticates, but Squid tries to cache this to not
> > > > overload the backend database.
> > >
> > > Can I disable this cache? Cuase it realy "feels" that this is the
> problem.
> >
> > Most likely not. All this cache does is to lower the amount of requests
> > to the backend authentication service. If you disable the cache then
> > Squid will have to validate the password on each and every request. And
> > since you use securid tokens this means that the user would have to
> > generate a new passphrases mostly the whole time..
> >
> > > > Is the radius authentication sucessful, or is it repeated failures?
> > >
> > > No it is not succesfull: And there is the problem! The passwords change
> > > every minute (we use a "secureid" token to generaie the password)
> >
> > Ok. So each user whould have to reauthenticate each authenticate_ttl
> > then, possibly causing trouble if it happens in the middle of a page, or
> > on a page partially cached in the client browser. If the users browser
> > have or tries to open multiple connections to the proxy when the old
> > passphrase expires then multiple requests for a new identification will
> > be sent (one for each concurrent request not carrying a valid
> > identification).
> >
> > Hmm.. maybe there are a proxy_auth cache defiency there. In theory the
> > first request carrying the new passphrase would be sent to the
> > authenticator, but maybe all are until the authenticator returns. Need
> > to check the code on this.
> >
>
> If you could to that please, cuase I am running out of options right now.
> I checked in cachemgr.cgi: In authticator sttistics the average service time
> is 1830 msec
>
> I am not sure, but it looks like it happens if the user hasn't used the
> browser for a longer period (shorter then 3600 secs) I will try to check. Do
> you want more info?
>
> > > > What is your settings of
> > > >
> > > > authenticate_ttl
> > >
> > > 3600
> >
> > Fine.
> >
> > > > authenticate_ip_ttl
> > >
> > > 3600
> >
> > This might also be one source if the same userid tried to access Squid
> > from two or more different IP's.
>
>
> No!!! I triple checked this: It is always from the same IP adress!
>
> --
> To unsubscribe, see http://www.squid-cache.org/mailing-lists.html
>
>
-- To unsubscribe, see http://www.squid-cache.org/mailing-lists.htmlReceived on Fri Dec 22 2000 - 14:56:30 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:57:06 MST