Henrik Nordström wrote:
mån 2010-08-16 klockan 18:15 +1200 skrev Amos Jeffries:
So...... the difference being that you are suggesting the credentials
text and parsing should be done on AuthUserRequest and no AuthUser
should exist associated with it until fully authed?
AuthUser only created/looked up at the point currently doing absorb()?
Correct.
okay. ++1.
Sounds like a good plan.
NOTE: this is why I specifically asked for details on the
RefCountCount() value on the assert bug:
==2 I think. Looks up IRC logs.. yes. "from->RefCountCount() == 2"
I mean, finding out what !=2 value it is to fail the assert.
AuthUser should be scheme-independent, but need to softly link to the
schemes using it allowing clean garbage collection and association of
scheme state (basic credentials cache, confirmed digest nonces and their
related H(A1))
It is already like that. AuthUser is the mostly-private part persisting
across requests/conn in the username cache. AuthUserRequest is the
public hanging off each request and conn indicating state of auth.
Pointing to whatever AuthUser has the credentials text.
Almost.. each AuthUser is scheme specific today. Shouldn't be, but still
is. Not the class as such, but it's data makes it unique per scheme.
References auth_type and AuthConfig.
I don't think thats making them scheme-specific as such. The child
classes inheriting from AuthUser will be doing that part.
Config can be unlinked by moving the TTL into AuthUser as a generic
timestamp set at point of last validation. IIRC thats all its used for
so the validating scheme's TTL-when-validated can persist across
reconfigure.
auth_type is just a meta data flag. Useful for cachemgr display and any
scheme-specific logics handling the AuthUser that fell like they need to
check the type.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.6
Beta testers wanted for 3.2.0.1
