Re: [twsocket] THttpCli digest and basic authentication
Maurizio Lotauro wrote: Sooner or later I must install (and use) a svn client :-) Any suggestion? When using Windows there is the great TortoiseSVN client (http://tortoisesvn.tigris.org/) that integrates into the Windows explorer. Have not found a better tool in the last years - and I really miss it when working on GNU/Linux. Regards, Tobias -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] THttpCli digest and basic authentication
Maurizio Lotauro wrote: Scrive Arno Garrels arno.garr...@gmx.de: Maurizio Lotauro wrote: Scrive Arno Garrels arno.garr...@gmx.de: Maurizio Lotauro wrote: [...] But if you have time give a look in the code, particularly to HttpAuthNTLM to get an idea how implement the Digest authentication class. Already done last week. However Digest is more similar to Basic, the only difference to Basic is that at least one challenge is required to build the Authorization header line. The key is the PrepareNextStep method where the class receive the header line to get all information needed and set the required properties. With digest you would have to parse the server challenge at this point, and check whether it is syntactically correct and reset the nounce count (nc) value/property to zero. For each subsequent Authorization header which is created using the _same challenge the nc has to be incremented by one. Problem is however that if a proxy sends 407 after you already got a server challenge the Autorization header was not received by the server so next time the Autorization header is created the nc must not be incremented otherwise the server may see gaps nc=0001, nc=0003 etc (this is currently no problem since a challenge is not yet reused). [...] Also see my latest changes in the ICS v7 repository. I'll do that but first I must change how the component works. Will you be adding your changes to v7? First I'll work on my version, that actually is used by D5 applications. After that we will see. One problem could be the adaptions to D2009. Sooner or later I must install (and use) a svn client :-) Any suggestion? The TortoiseSVN client is very good choice. I usually do not like shell extensions, however in this case I love it. Btw: If you like WinMerge (http://winmerge.org/) you can set it up as the external the diff viewer and merge tool. All you need to create your own local and network repositories is included in TortoiseSVN as well. Version control is not just useful for teams but also for a one man band. With a few clicks you create your own repositories (no server software is required). I could not live without it ;-) -- Arno -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] THttpCli digest and basic authentication
Scrive Arno Garrels arno.garr...@gmx.de: Maurizio Lotauro wrote: Scrive Arno Garrels arno.garr...@gmx.de: [...] With digest you would have to parse the server challenge at this point, and check whether it is syntactically correct and reset the nounce count (nc) value/property to zero. For each subsequent Authorization header which is created using the _same challenge the nc has to be incremented by one. Problem is however that if a proxy sends 407 after you already got a server challenge the Autorization header was not received by the server so next time the Autorization header is created the nc must not be incremented otherwise the server may see gaps nc=0001, nc=0003 etc (this is currently no problem since a challenge is not yet reused). Hmmm, very interesting. This confirm me that the idea that I have in mind goes in the right direction... [...] Sooner or later I must install (and use) a svn client :-) Any suggestion? The TortoiseSVN client is very good choice. I usually do not like shell extensions, however in this case I love it. Normally I use TotalCommander. Do you know if there are problems with it? Btw: If you like WinMerge (http://winmerge.org/) you can set it up as the external the diff viewer and merge tool. I'm using Beyond Compare. Version 3 is really great! I don't think there are problem to use as external application. All you need to create your own local and network repositories is included in TortoiseSVN as well. Version control is not just useful for teams but also for a one man band. With a few clicks you create your own repositories (no server software is required). I could not live without it ;-) This sounds that RTFM is a need :-) I put it in the queue of thinks to do. Bye, Maurizio. This mail has been sent using Alpikom webmail system http://www.alpikom.it -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] THttpCli digest and basic authentication
Scrive Tobias Rapp t.r...@noa-audio.com: Maurizio Lotauro wrote: Sooner or later I must install (and use) a svn client :-) Any suggestion? When using Windows there is the great TortoiseSVN client (http://tortoisesvn.tigris.org/) that integrates into the Windows explorer. Thank you for the link. Bye, Maurizio. This mail has been sent using Alpikom webmail system http://www.alpikom.it -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] THttpCli digest and basic authentication
Scrive Arno Garrels arno.garr...@gmx.de: Maurizio Lotauro wrote: Scrive Arno Garrels arno.garr...@gmx.de: Maurizio Lotauro wrote: [...] But if you have time give a look in the code, particularly to HttpAuthNTLM to get an idea how implement the Digest authentication class. Already done last week. However Digest is more similar to Basic, the only difference to Basic is that at least one challenge is required to build the Authorization header line. The basic is defined directly in the HttpAuth unit, but it is really very simple (only a few row of code). The key is the PrepareNextStep method where the class receive the header line to get all information needed and set the required properties. [...] Also see my latest changes in the ICS v7 repository. I'll do that but first I must change how the component works. Will you be adding your changes to v7? First I'll work on my version, that actually is used by D5 applications. After that we will see. One problem could be the adaptions to D2009. Sooner or later I must install (and use) a svn client :-) Any suggestion? This mail has been sent using Alpikom webmail system http://www.alpikom.it -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] THttpCli digest and basic authentication
Maurizio Lotauro wrote: Scrive Arno Garrels arno.garr...@gmx.de: Maurizio Lotauro wrote: [...] So I think I'll wait for your latest changes? Yes, probably at this point it is better to wait. But if you have time give a look in the code, particularly to HttpAuthNTLM to get an idea how implement the Digest authentication class. Already done last week. However Digest is more similar to Basic, the only difference to Basic is that at least one challenge is required to build the Authorization header line. Once a challenge is cached somehow it may be reused. With NTLM this is not possible. So I can ask you for some hint for the new changes if needed :-) Please ask, even though I do not understand all details of the integrity authentication Qop yet, or better said how to make it working with TSmtpCli :( Also see my latest changes in the ICS v7 repository. Will you be adding your changes to v7? -- Arno Mainly what I want to do is: - add a way to authenticate without first receiving a 401/401 status code - handle different realms sent form the server - add a way to tell the component which proxy should use. Those were my wishes last weekend, but I gave them up temporarily. Maybe it will be easier with the next changes. We will see. Bye, Maurizio. This mail has been sent using Alpikom webmail system http://www.alpikom.it -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] THttpCli digest and basic authentication
Maurizio Lotauro wrote: About the merge, I suggest to done it just to be a bit confident with the new authentication handling. But not make it official for the moment since I want to change it and this will certainly mean that some classes, events an so on will be different, introducing backward compatibility if the actual will be released. So I think I'll wait for your latest changes? Mainly what I want to do is: - add a way to authenticate without first receiving a 401/401 status code - handle different realms sent form the server - add a way to tell the component which proxy should use. Those were my wishes last weekend, but I gave them up temporarily. -- Arno -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] THttpCli digest and basic authentication
Scrive Arno Garrels arno.garr...@gmx.de: Maurizio Lotauro wrote: [...] So I think I'll wait for your latest changes? Yes, probably at this point it is better to wait. But if you have time give a look in the code, particularly to HttpAuthNTLM to get an idea how implement the Digest authentication class. So I can ask you for some hint for the new changes if needed :-) Mainly what I want to do is: - add a way to authenticate without first receiving a 401/401 status code - handle different realms sent form the server - add a way to tell the component which proxy should use. Those were my wishes last weekend, but I gave them up temporarily. Maybe it will be easier with the next changes. We will see. Bye, Maurizio. This mail has been sent using Alpikom webmail system http://www.alpikom.it -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] THttpCli digest and basic authentication
Maurizio, Something like that is required, also because current authentication code in the THttpCli is a complicated nightmare, error-prone and contains plenty of duplicated code. I know it very well :-) I already post in the past my propose of changes, but probably it was not the right moment because I got no feedback. Well done! I think I can merge your code with ICS v7 next week and add digest authentication. The demo should then be extended to show how to preemptively send Authorization headers. In order get this working with digest wee need the realm, nonce and opaque values from the challenge as well as HTTP method, the digest URI and a nonce count value which has to be incremented on each request actually received by the server. -- Arno -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] THttpCli digest and basic authentication
Scrive Arno Garrels arno.garr...@gmx.de: Maurizio, Arno, Something like that is required, also because current authentication code in the THttpCli is a complicated nightmare, error-prone and contains plenty of duplicated code. I know it very well :-) I already post in the past my propose of changes, but probably it was not the right moment because I got no feedback. Well done! I think I can merge your code with ICS v7 next week and add digest authentication. If you already added the Digest to the client then I suggest to do the merge using the version without it. I hope that at the end all code that actually is not used by the new authentication handling will be removed. Otherwise we continue to have two different code into a single source and maintain both will be a nightmare. The Digest authentication support must be in a different unit. The demo should then be extended to show how to preemptively send Authorization headers. At the end yes. In order get this working with digest wee need the realm, nonce and opaque values from the challenge as well as HTTP method, the digest URI and a nonce count value which has to be incremented on each request actually received by the server. This is done by the class that handle the specific authentication. After the component has selected which scheme will be used (the strongest one) it will initialized using the specific header line sent by the server. About the merge, I suggest to done it just to be a bit confident with the new authentication handling. But not make it official for the moment since I want to change it and this will certainly mean that some classes, events an so on will be different, introducing backward compatibility if the actual will be released. Mainly what I want to do is: - add a way to authenticate without first receiving a 401/401 status code - handle different realms sent form the server - add a way to tell the component which proxy should use. I hope that I start to work on it very very soon. Bye, Maurizio. This mail has been sent using Alpikom webmail system http://www.alpikom.it -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] THttpCli digest and basic authentication
Scrive Arno Garrels arno.garr...@gmx.de: Maurizio Lotauro wrote: Digest authentication requires at least one server challenge per protection space (realm). This is similar to basic authentication which may use a realm as challenge (currently not supported by basic in both THttpCli and THttpServer). The last sentence is not clear to me, can you explain? This was not quite correct since the THttpServer actually allows to specify a realm with basic authentication as well. The server must send a realm: RFC 2617 1.2 Access Authentication Framework ... The realm directive (case-insensitive) is required for all authentication schemes that issue a challenge. However it is not easy in the THttpCli to obtain this value unless you parse the AuthorizationRequest list. In my version this is one of the information passed to event used for the authentication :-) Also, both do not require a persistant connection and both require just a _single server challenge, that's the similarity I meant. We recently discussed about that. It should be always so because it is stateless. It is the NTLM that don't respect the rfc. [...] Something like that is required, also because current authentication code in the THttpCli is a complicated nightmare, error-prone and contains plenty of duplicated code. I know it very well :-) I already post in the past my propose of changes, but probably it was not the right moment because I got no feedback. Bye, Maurizio. This mail has been sent using Alpikom webmail system http://www.alpikom.it -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] THttpCli digest and basic authentication
Maurizio Lotauro wrote: Digest authentication requires at least one server challenge per protection space (realm). This is similar to basic authentication which may use a realm as challenge (currently not supported by basic in both THttpCli and THttpServer). The last sentence is not clear to me, can you explain? This was not quite correct since the THttpServer actually allows to specify a realm with basic authentication as well. However it is not easy in the THttpCli to obtain this value unless you parse the AuthorizationRequest list. Both Basic and Digest server responses include a realm: RFC 2617: 2 Basic Authentication Scheme The basic authentication scheme is based on the model that the client must authenticate itself with a user-ID and a password for each realm. The realm value should be considered an opaque string which can only be compared for equality with other realms on that server. The server will service the request only if it can validate the user-ID and password for the protection space of the Request-URI. There are no optional authentication parameters. Also, both do not require a persistant connection and both require just a _single server challenge, that's the similarity I meant. Any thoughts and suggestions? I already made a similar change. I have a modified version of THttpCli where I changed how the authentication is handled, so it is very easy to add a new one, and without touching the THttpCli class. As support I added an event so the authentication can be handled by the application or by an inherited class. In fact I have a derived class that ask for user and password and cache these information so it will not ask again. Something like that is required, also because current authentication code in the THttpCli is a complicated nightmare, error-prone and contains plenty of duplicated code. All this is at least three year old and I think it can be considered stable. If you want I can send it to you. But keep in mind that after our recent discussion about the authentication problem with Tomcat I planned to revise it to avoid the double request. Yes, please send it as PM. -- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] THttpCli digest and basic authentication
Scrive Arno Garrels arno.garr...@gmx.de: Hi All, Hi Arno, I just finished an implementation of Digest Access Authentication in the THttpCli. Well done :-) Digest authentication requires at least one server challenge per protection space (realm). This is similar to basic authentication which may use a realm as challenge (currently not supported by basic in both THttpCli and THttpServer). The last sentence is not clear to me, can you explain? Once a client is authenticated it MAY preemptively send the corresponding Authorization header with requests for resources in that protection space without receipt of another challenge from the server. This is currently not implemented in the THttpCli so always two requests are required with authentication which is horribly slow! I agree. I doubt that the THttpCli itself should handle those 'preemptive Authorization headers' instead it should provide some option which makes it possible/easy to lookup, create send those 'preemptive Authorization headers' at the application level or maybe in derived classes. Currently there is IMO no such option, the 401 and 407 error codes are handled silently internally. A agree to this too. Any thoughts and suggestions? I already made a similar change. I have a modified version of THttpCli where I changed how the authentication is handled, so it is very easy to add a new one, and without touching the THttpCli class. As support I added an event so the authentication can be handled by the application or by an inherited class. In fact I have a derived class that ask for user and password and cache these information so it will not ask again. All this is at least three year old and I think it can be considered stable. If you want I can send it to you. But keep in mind that after our recent discussion about the authentication problem with Tomcat I planned to revise it to avoid the double request. Bye, Maurizio. This mail has been sent using Alpikom webmail system http://www.alpikom.it -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
