Wouldn't that create a *possible* security risk? For example, if we store the "admin" realm on www.apache.org, and then connect to another site with a realm deliberately named to "[EMAIL PROTECTED]", it could be sent the login credentials for the first site by HttpClient, and then this other site could read the user's login information for the other site...
AFAIK, "@" is a valid character in a realm name (not 100% sure, haven't checked), so if we check realm names to avoid the above security risk, we might make it impossible for users to authenticate against a valid realm containing the "@" symbol. It might also be totally valid to use the same realm (such as an NTLM domain) on several hosts, so I don't think users should be forced to resupply credentials for each host either. Maybe two variants of each method using HttpState should be available, one with a host (maybe null, to retain current behaviour), one without (like the current implementation, just calls the other variant with a null "host" parameter). - Chris ----- Original Message ----- From: "Kalnichevski, Oleg" <[EMAIL PROTECTED]> To: "Commons HttpClient Project" <[EMAIL PROTECTED]> Sent: Friday, March 21, 2003 4:32 PM Subject: RE: Using appropriate credentials and state with multiple hosts Just a quick follow-up to my previous posting. I think there is a solution to the problem of conflicting authentication realms that would allow us to retain compatibility with the existing code: Authenticator class should initially attempt to obtain appropriate credentials using a key in the following form: '[EMAIL PROTECTED]'. If no credentials are returned, another attempt should be made using 'realm' only Folks, let me know what you think. Cheers Oleg Credentials map -----Original Message----- From: Kalnichevski, Oleg Sent: Freitag, 21. M�rz 2003 16:21 To: Commons HttpClient Project Subject: RE: Using appropriate credentials and state with multiple hosts Hi Chris As far as your first point is concerned, just bear with us for a short while. I am currently working on a patch that should address the problem. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17884 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17158 As far as your second point is concerned, it's a bit more complicated. HttpClient class has been designed to be capable of handling different hosts. However, you right about possibility of conflict between credentials belonging to different realms that happen to be sharing the same name. As far as I understand the authentication realms as defined in RFC2617 are not required to be unique. I am afraid it is a limitation we are supposed to live with. Alternatively we might consider redesigning HttpState class to include host name into credentials map keys. Oleg -----Original Message----- From: Chris Brown [mailto:[EMAIL PROTECTED] Sent: Freitag, 21. M�rz 2003 15:59 To: Commons HttpClient Project Subject: Using appropriate credentials and state with multiple hosts Hi, I'm using HttpClient 2.0 alpha 3, and am trying to find out how to work with multiple hosts, sometimes with authentification, sometimes without, sometimes with NTLM. Some questions, hope should be easy to answer... 1.) Is there already some method to parse authentification headers to extract the realm, or do I have to parse this myself (I've looked around a bit, may have missed it) ? 2.) Do I need a separate HttpState per client per host? From the javadocs, it seems that if more than one host uses the same realm name, such as "Private" (by coincidence), then I'm stuck, as HttpState can only store one set of credentials for a given name... Thanks, Chris --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
