[jcifs] NtlmHttpFilter breaks file upload UI component : SOLVED

[Michael B Allen]

On Tue, Mar 3, 2009 at 12:01 PM, Ivan Stefanov
<ivan.stefanov at clever-soft.com> wrote:
> Hello everybody,
>
> The previous issue has been solved by installing the newest (3.3.0) version
> of richfaces. Perhaps it would be nice to add somewhere in the documentation
> that newer richfaces is recommended, or that older than the 3.3.0 version is
> known to have issues NtlmHttpFilter?
>
> However, a new problem has come up. While developing, I have been
> exclusively testing on Firefox 3.0.6. When one tries to log in with this
> browser the default identification window springs up, the user enters
> username/password, the authentication goes smoothly and basically SSO works.
> However, when I have tested this on IE7 and on Opera 9.64, the
> authentication simply refuses to function anymore. The possible scenarios
> are two: either the username/password credenticals are not recognised and I
> get prompted for them again, or the browser shows the "Cannot display the
> webpage" page without asking for username/password and in my JBoss console I
> get the following stacktrace:
>
> 17:42:00,429 ERROR [ExceptionFilter] handling uncaught exception
> jcifs.smb.SmbException: The parameter is incorrect.
>     at jcifs.smb.SmbTransport.checkStatus(SmbTransport.java:542)
>     at jcifs.smb.SmbTransport.send(SmbTransport.java:644)
>     at jcifs.smb.SmbSession.sessionSetup(SmbSession.java:307)
>     at jcifs.smb.SmbSession.send(SmbSession.java:235)

I doubt this error has much to do with what browser was used. Have you
been testing successfully with a a Linux or OSX client but then found
that it failed in a Windows environment? Meaning is the pattern the OS
and not the browser?

If you send me a packet capture I can tell you more definitively what
the error is about. The "parameter is incorrect" error is a very
generic issue that can occur under a wide range of conditions.

Of course, as stated in the NTLM HTTP Authentication Filter
documentation and FAQ, you do know that the NtlmHttpFilter is not
supported and is being removed? The only reason I'm interested in
seeing a capture about this is because in theory this error should not
occur and it just might affect the CIFS or DCERPC code.

Mike

>     at jcifs.smb.SmbTree.treeConnect(SmbTree.java:161)
>     at jcifs.smb.SmbSession.logon(SmbSession.java:171)
>     at jcifs.smb.SmbSession.logon(SmbSession.java:164)
>     at
> eu.cleversoft.infonds3.session.helper.InfondsNtlmHttpFilter.negotiate(InfondsNtlmHttpFilter.java:152)
>     at jcifs.http.NtlmHttpFilter.doFilter(NtlmHttpFilter.java:121)
>     at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>     at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>     at
> org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
>     at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:85)
>     at
> org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>     at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
>     at
> org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>     at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:44)
>     at
> org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>     at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
>     at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
>     at
> org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:390)
>     at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:517)
>     at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:60)
>     at
> org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>     at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
>     at
> org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>     at
> org.jboss.seam.debug.hot.HotDeployFilter.doFilter(HotDeployFilter.java:68)
>     at
> org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>     at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
>     at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>     at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>     at
> eu.cleversoft.infonds3.support.CharsetFilter.doFilter(CharsetFilter.java:32)
>     at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>     at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>     at
> org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
>     at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>     at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>     at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
>     at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
>     at
> org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
>     at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
>     at
> org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
>     at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>     at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>     at
> org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
>     at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>     at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
>     at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
>     at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
>     at
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
>     at java.lang.Thread.run(Unknown Source)
> 17:42:00,429 ERROR [ExceptionFilter] exception root cause
>
> The line
> eu.cleversoft.infonds3.session.helper.InfondsNtlmHttpFilter.negotiate(InfondsNtlmHttpFilter.java:152),
> from where supposedly the exception gets thrown, points to the
> SmbSession.logon( dc, ntlm ); call in my modified negotiate() method, which
> does nothing different than the original NtlmHttpFilter.negotiate(), but
> take jcifs.http.domainController from our local database and not from
> web.xml.
>
> I am running Windows Vista SP1. Are there any additional system settings,
> which one has to configure in order to get IE and Opera to work? What could
> be the cause for the filter to fail with those two browsers, but to function
> correctly with Firefox?
>
> Thank you very much in advance!
>
> Best regards,
> Ivan Stefanov
>
> Ivan Stefanov wrote:
>
> Hello all,
>
> Currently I am building a JBoss Seam application, which needs to implement
> Windows SSO and I have tried the approach proposed here. I have written an
> own FilterClass, which inherits the jcifs.http.NtlmHttpFilter class and most
> of its functionality, only modifying the init() and negotiate() methods so
> that the default_domain_controller and domain_name are pulled out from our
> database and not from the web.xml file. After some tweaking, it worked, but
> a very unexpected bug appeared.
>
> For the web front-end of out application I am extensively using richfaces
> components. After deploying the Ntlm filter, the rich:fileUpload component
> does not function anymore. I've tried to troubleshoot the problem and it
> appears that, although the POST carries the whole content of the file (PDF
> in our case), and the input HttpServletRequest parameter in
> NtlmHttpFilter.doFilter() contains, it seems, the correct information, no
> uploadEvent ever gets fired, since the upload listener method never gets
> called. When I turn off the filter (by removing its entry from web.xml and
> also the autoLogin method from components.xml), everything works fine.
>
> After some googling, it seems to me that this is an obscure, though
> relatively known issue, but apart from most people declaring that the
> NtlmFilter breaks the request and it appears empty, I have found no proposed
> adequte solution.
>
> As a part of my attempts to troubleshoot the problem, I have tried
> completely overriding the NtlmHttpFilter.doFilter method (that is, without a
> super.doFilter() call) in order to call my modified negotiate() method in
> the
> if ((ntlm = negotiate( req, resp, false )) == null) {
>             return;
> }
> statement, but then I found out that I can't call the NtlmHttpServletRequest
> constructor from the inheriting, as the NtlmHttpServletRequest class is not
> declared as public in the jCIFS package. Do the jCIFS developers propose any
> other approach to accessing this class, or is it deliberately designed not
> to be accessed by classes outside of the jcifs.http package?
>
> Any information on how I could better troubleshoot the problem with the
> broken file upload, or any workaround, or at least a suggestion how could I
> access the NtlmHttpServletRequest from my inheriting class, are very
> welcome!
>
> Thank you in advance!
>
> Ivan Stefanov
>
> --
> Mit freundlichen Grüßen
> Ivan Stefanov
>
> Software Entwickler
> CleverSoft GmbH
>
> Personalisierte Factsheets mit FactsheetsLIVE™:
> Geben Sie Ihren Vertriebsmitarbeitern und Beratern die Möglichkeit ein mit
> Ihren jeweiligen Kontaktdaten
> samt Logo und Foto personalisiertes Factsheet zu erstellen. Erfahren Sie
> mehr auf www.FactsheetsLIVE.de!
>
> www.clever-soft.com | Paul-Heyse-Str.6 | 80336 München | Germany
> Tel. +49 89/99 16 91 17 | Mobil +49 172/77 43 714 | Fax +49 89/30 76 41-29
>
> Die CleverSoft ist ein Unternehmen der Clever Holding GmbH |
> www.clever-holding.de
>
> Bei Fragen zu unseren Produkten bitten wir Sie
> um eine E-Mail an: support at clever-soft.com
>
> ---
> CleverSoft GmbH | www.clever-soft.com | Zasiusstr. 45 | 79102 Freiburg |
> Deutschland
> Sitz und Registergericht: Freiburg i.Br. | HRB 7358 | Geschäftsführer:
> Florian Clever
> Steuernummer 06415/41889 | USt-IdNr. DE237074688
>
> Diese E-Mail kann vertrauliche und/oder geheime Informationen enthalten.
> Wenn Sie nicht der richtige Adressat sind und diese E-Mail irrtümlich
> erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie
> diese E-Mail. Das unerlaubte Vervielfältigen und die unbefugte Weitergabe
> dieser E-Mail sind nicht gestattet. Wir haben alle verkehrsüblichen
> Maßnahmen unternommen, um das Risiko der Verbreitung virenbefallener
> Software oder E-Mails zu minimieren. Dennoch raten wir Ihnen, Ihre eigenen
> Virenkontrollen für alle Anhänge an dieser Nachricht durchzuführen. Sollten
> Sie die verschlüsselte Übermittlung von E-Mails wünschen, so setzen Sie sich
> bitte mit uns in Verbindung.



-- 
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/