On 05.01.15 18:15, Amos Jeffries wrote:
Can you try making the constructor at the top of src/HelperReply.cc
look like this and see if it resolves the problem?
HelperReply::HelperReply(char *buf, size_t len) :
result(HelperReply::Unknown),
notes(),
whichServer(NULL)
{
assert(notes.empty());
parse(buf,len);
}
This didn't help I'm afraid.
Some further debugging so far today:
The notes in HelperReply are indeed empty when the token is added.
However, Auth::Negotiate::UserRequest::HandleReply() appends the reply
notes to auth_user_request. It fetches a cached user record from
proxy_auth_username_cache and then calls absorb() to merge
auth_user_request with the cached user record. This ends up adding the
new Negotiate token into the cached record. This keeps happening for
each new request and the cached user record gradually accumulates tokens.
As far as I can see, tokens are only ever read from the helper's reply
notes, not the user's notes, so maybe the tokens never need to be
appended to auth_user_request in the first place?
Alternatively, A->absorb(B) could be altered to remove any notes from A
that have the same keys as B's notes, before using appendNewOnly() to
merge them?
--
- Steve Hill
Technical Director
Opendium Limited http://www.opendium.com
Direct contacts:
Instant messager: xmpp:st...@opendium.com
Email: st...@opendium.com
Phone: sip:st...@opendium.com
Sales / enquiries contacts:
Email: sa...@opendium.com
Phone: +44-1792-824568 / sip:sa...@opendium.com
Support contacts:
Email: supp...@opendium.com
Phone: +44-1792-825748 / sip:supp...@opendium.com
_______________________________________________
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users
