Re: RESULT: possible bugs:( Re: Resend: disable httpclient logging)
Hi Odi, Maybe we should also change the wirelog logger to something like 'org.apache.commons.httpclient.wire'. The JLogFactory uses different methods to obtain loggers for a class and by name. Prefixing the name with a package is OK by me, but I'd prefer to leave some distinction in the naming scheme. Maybe 'org.apache.commons.httpclient.WIRE'. Or use some special characters no sane person would want to have in a class name, though they are acceptable in a property name. cheers, Roland
DO NOT REPLY [Bug 29730] New: - [Doc] Improve logging guide
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29730. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29730 [Doc] Improve logging guide Summary: [Doc] Improve logging guide Product: Commons Version: 2.0 Final Platform: Other URL: http://jakarta.apache.org/commons/httpclient/logging.htm l OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: HttpClient AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Until now, we only explain logging with SimpleLog. While this is very useful when you are not familiar with logging, this is too specific. The following should be added to the logging guide: * a list of all loggers (categories) that HttpClient provides: - wirelog - application log * description of what each log level contains * a Log4J sample config, maybe even some Log4J config code for use within a webapp I know that some of this is actually in the domain of Commmons-Logging / Log4J. But a lot of our users seemt to have issues with logging, so it seems best to provide this simple piece of information as a reference. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
NTLM authentication to an MS Exchange web page account using HTTP Client V2.0
Hi All, Using HTTPClient version 2.0 We are using HTTPClient to login to a MS Exchange web page account. We can only get it to work by passing in the realm as null, and putting the domain back on to the front of the user to pass into NTCredentials(). new NTCredentials(authUserNameAppendDomainWithBackSlash + settings.getAuthUserName(), settings.getAuthPassword(), settings.getHost(), settings.getAuthDomain()) The comments on the interface say that only the username should be passed in, and NOT the domain. For other NTLM pages it works to use only the user, but this page has not worked for us without the domain like this myDomain\myUser. On State.setCredentials() we have tried passing the host, null, and the string realm in without the domain appended to user. All these attempts fail. We would prefer to use the API without the domain on the user. client.getState().setCredentials( null, //realm, null, settings.getHost()- settings.getHost(), new NTCredentials(authUserNameAppendDomain + settings.getAuthUserName(), settings.getAuthPassword(), settings.getHost(), settings.getAuthDomain()) ); Is there some documentation on how the realm interacts with authentication? Thanks for your time and effort, Steve Steve Johnson Software Engineer Mercury Interactive 720 564 - 6532 USA, Canada and the Americas 720 564-6620 Hours: M-F 08:00-17:00 MST (Mountain Standard Time) http://www.mercuryinteractive.com http://www.mercuryinteractive.com Looking for Answers to your SiteScope or SiteSeer questions? http://support.mercuryinteractive.com http://support.mercuryinteractive.com
Re: NTLM authentication to an MS Exchange web page account using HTTP Client V2.0
This sounds very much like the webserver isn't really using NTLM but is using Digest/Basic instead. If it really were using NTLM passing in DOMAIN\User would definitely not work because HttpClient doesn't check for that case. That would also explain why the realm isn't what you expect. I'd say a wire log should shed a lot of light on the situation (see http://jakarta.apache.org/commons/httpclient/logging.html ) Regards, Adrian Sutton On 23/06/2004, at 3:43 AM, Steve Johnson wrote: Hi All, Using HTTPClient version 2.0 We are using HTTPClient to login to a MS Exchange web page account. We can only get it to work by passing in the realm as null, and putting the domain back on to the front of the user to pass into NTCredentials(). new NTCredentials(authUserNameAppendDomainWithBackSlash + settings.getAuthUserName(), settings.getAuthPassword(), settings.getHost(), settings.getAuthDomain()) The comments on the interface say that only the username should be passed in, and NOT the domain. For other NTLM pages it works to use only the user, but this page has not worked for us without the domain like this myDomain\myUser. On State.setCredentials() we have tried passing the host, null, and the string realm in without the domain appended to user. All these attempts fail. We would prefer to use the API without the domain on the user. client.getState().setCredentials( null, //realm, null, settings.getHost()- settings.getHost(), new NTCredentials(authUserNameAppendDomain + settings.getAuthUserName(), settings.getAuthPassword(), settings.getHost(), settings.getAuthDomain()) ); Is there some documentation on how the realm interacts with authentication? Thanks for your time and effort, Steve Steve Johnson Software Engineer Mercury Interactive 720 564 - 6532 USA, Canada and the Americas 720 564-6620 Hours: M-F 08:00-17:00 MST (Mountain Standard Time) http://www.mercuryinteractive.com http://www.mercuryinteractive.com Looking for Answers to your SiteScope or SiteSeer questions? http://support.mercuryinteractive.com http://support.mercuryinteractive.com -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com PGP.sig Description: This is a digitally signed message part
Re: Invalid RSA modulus size
Hi, Would anyone care to take a guess at whether using the BouncyCastle JCE would help get around this invalid modulus size error message? I had a bit of a play with it last week but without much luck. Thanks Tim - Original Message - From: Oleg Kalnichevski [EMAIL PROTECTED] Date: Saturday, June 12, 2004 10:30 pm Subject: Re: Invalid RSA modulus size Tim, This is believed to be a limitation of all Sun's JCE/JSSE implementations up to Java version 1.5. You can try testing your application with Java 1.5-b2 to see if the problem has indeed been fixed. Alternatively consider using IBM Java 1.4 or 3rd party JCE/JSSE implementations which _may_ not exhibit the same limitation HTH Oleg On Sat, 2004-06-12 at 05:36, Tim Wild wrote: Hi, I'm using HttpClient to connect to an apache server that requires certificates. When I use client and server certificates from my own CA with 1024 bit keys it works perfectly. When I get a commercial certificate with a longer key (4096 bits), I get the following error (full message below) when I connect to apache: javax.net.ssl.SSLProtocolException: java.io.IOException: subject key, Unknown key spec: Invalid RSA modulus size. Google produced one result, which talked about a maximum key size using the JCE of 2048 bits using the JDK 1.4.2 default policy files. Another site suggested getting the unrestricted policy files, so I got and installed them, but it doesn't seem to make any difference at all. Does anyone have any thought or suggestions? Half formed thoughs or ideas are welcome as it might give me a lead that I can follow myself. Thanks Tim Wild - To unsubscribe, e-mail: commons-httpclient-dev- [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- -- To unsubscribe, e-mail: commons-httpclient-dev- [EMAIL PROTECTED] additional commands, e-mail: [EMAIL PROTECTED] Attention: The information contained in this message and or attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any system and destroy any copies. Thank You. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
