Jenny Lee wrote:
Hello Folks,
Basic authentication. Same user must use different usernames from the
same IP in quick succession for role determination purposes.
This breaks the model and purpose of authentication. You apparently are
trying to use diffrent credentials for authentication and for
authorization and do do both simultaneously.
The regular way to do this is to assign a group indicating role to the
credentials. This gets tested to authorize particular actions separately
by the authenticating software based on the credentials.
Why can't you do it that way?
I have this:
authenticate_ttl 1 seconds
- store credentials in the internal cache for 1 second. After which
they can be discarded. Does not affect validity of credentials.
SHOULD be larger than credentialsttl (Basic), nonce_max_duration
(Digest) and authenticate_ip_ttl or it will override them and discard
valid credentials on garbage collection.
> authenticate_ip_ttl 1 seconds
- you already figured that one out.
> auth_param basic credentialsttl 1 seconds
- max time between checks of the authentication credentials with the
backend. Squid will accept credentials without testing the backend if
the username was tested and okay less than 1 second ago.
I read from Henrik's old posts that
authenticate_cache_garbage_interval is not that important for user
interaction. So I left that at default. I am also not limiting with
max_user_ip acl so authenticate_ip_ttl has no relevance either as far
as I can guess.
No need to guess:
http://www.squid-cache.org/Doc/config/authenticate_ip_ttl/
This works fine, user can specify a new username and login with that.
When I left these values at defaults, user would specify a new
user/pass, but squid was still using his old user in its operations.
The problem is: squid acceps the old password of the new username.
For example, if I type user1/pass1, browse, close browser. Open, type
user2/pass1, access is still granted. What is controlling this?
When I was reading about on the issue, Robert seemed to have written
a book about explanation of authenticate_ttl and credentialsttl.
Thanks him for that. Of course, it all sounded greek to me. Can
someone explain us the relation of these values on regular user
interaction? Yes, browsers cache credentials and they must be sent to
squid on each request. We know this part.
Quite simple:
* Squid keeps a list (cache) of credentials previously seen. Along
with the time they were last checked.
* when new ones come in they are looked for in the cache.
* If they are found and credentialsttl has not passed, the new ones
are accepted without testing.
* If credentialsttl has passed, they are tested with the backend again.
- the results are used to update the cache and time-checked is reset
on the username.
At some intervals (garbage collection) the whole list gets checked
* If authenticate_ttl has passed all info previously stored about the
expired credentials is discarded.
Also, isnt keeping these values so low going to be an overkill on
squid? I have some users that use static usernames. What settings
would give best of both worlds?
Keeping authenticate_ttl low may cause problems when garbage collecting.
Though thats it on guaranteed if its lower than credentialsttl.
As for the other question. You can't with the current auth design. That
would require a bit of re-coding in Squid to accept credentialsttl back
from the auth helper, and auth helpers to send it.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.5
