On Sat, 30 Oct 2004, Andrew Bartlett wrote:
Can you give me details of the exact protocol you intend to use? Inside ntlm_auth it should be trivial, I just keep separate state machines in a lookup tree.
It just adds a number infront of the request identifying the "session". What comes after the number is exactly the same as today.
squid (2 pending negotiate requests)
0 YR base64-blob 1 YR base64-blob
helper (both responded quickly with challenges)
0 TT base64-blob 1 TT base64 blob
squid (client responded in second session)
1 KK base64-blob
helper (authentication successful)
1 AF username
squid (session number 1 reused for the next session, and client responded in the first session)
1 YR base64-blob 0 KK base64-blob
helper (new challenge generated in session number 1 and shortly after that the authentication was verified successfully in the first session)
1 TT base64-blo 0 AF username
The above illustrates
2 successful authentications, one per session number
1 one pending challenge in session number 1
1 reordered reply in the last reply sequence where the challenge is sent before authentication reply even if queried in the opposite order by Squid
What has not been determined is if this should be extended with an additional call for "session terminated", or if it should simply rely on the YR command to imply a new session.
If desired it can be relied upon the session numbers being integers in the range 0 to N-1 where N is the configured concurrency level for the helper.
Regards Henrik
