[jcifs] Null pointer exception in ServerMessageBlock.java

Edward Costello edward.costello at orionhealth.com
Thu Jun 22 22:22:47 GMT 2006


I'd forgotten that this thread was in the context of SMB connections. Is 
there a way to do something similar to the NtlmPasswordAuthentication 
for HTTP URL connections authenticated using JCIFS?

Cheers
Ed

----- Original Message -----
*From:* Michael B Allen <mba2000 at ioplex.com>
*To:* Edward Costello <edward.costello at orionhealth.com>
*CC:* jcifs at lists.samba.org
*Sent:* 06/23/2006 9:47:27 AM +1200
*Subject:* [jcifs] Null pointer exception in ServerMessageBlock.java


>The general rules for supplying JCIFS credentials are:
>
>1) Create an NtlmPasswordAuthentication (NPA) object and pass that to
>   all constructors (e.g. SmbFile).
>2) However, if you will only being using one set of credentials you may
>   prefer to use properties because it makes the code simpler.
>3) You may prefer to put the credentials in a properties file but you
>   should take care to set appropriate permissions on the file to protect
>   it.
>4) If you are only experimenting or your application does not require
>   security and you accept that the credentials may be inadvertantly exposed,
>   you may choose to place the credentials in the SMB URL for the target
>   resource.
>
>Note that ALL of these methods are crude. It would have been better to
>integrate with Java's Subject based security model. I started to perform
>that work for jCIFS 2 but my situation has since changed and I no longer
>have time for new OSS development.
>
>It is unfortunate that so many users have resorted to using method
>4. That is perhaps partly my fault as many of the examples do not use
>method 1 as they should have.
>
>Mike
>
>On Fri, 23 Jun 2006 08:17:59 +1200
>Edward Costello <edward.costello at orionhealth.com> wrote:
>
>  
>
>>I'm curious then. Without specifying the username and password in the 
>>URL, is it possible to use JCIFS to authenticate just a particular 
>>connection. For Example, we have a single service we connect to using 
>>NTLM authentication. We'd like to ensure firstly that the credentials 
>>are never sent to any other service that happens to require NTLM 
>>authentication. We'd also like to be able to use a different set of 
>>credentials for other services that use NTLM authentication.
>>
>>As far as I could tell from the documentation the only way to set the 
>>username and password without putting in in the URL is to use a 
>>properties file, system properties or a static configuration object. All 
>>of these would result in the credentials being sent to any service that 
>>requests NTLM authentication and would prevent us ever using a second 
>>set of credentials for a different service.
>>
>>Cheers
>>Ed
>>
>>----- Original Message -----
>>*From:* Michael B Allen <mba2000 at ioplex.com>
>>*To:* "Levi Purvis" <jcifs at purvis.ws>
>>*CC:* jcifs at lists.samba.org
>>*Sent:* 06/23/2006 7:04:24 AM +1200
>>*Subject:* [jcifs] Null pointer exception in ServerMessageBlock.java
>>
>>
>>    
>>
>>>On Thu, 22 Jun 2006 08:35:35 -0400
>>>"Levi Purvis" <jcifs at purvis.ws> wrote:
>>>
>>> 
>>>
>>>      
>>>
>>>>>>>Never put your password in the URL.
>>>>>>>         
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>Why not?
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>>>>Because it's a security hazard.
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>Could you elaborate, please?
>>>>   
>>>>
>>>>        
>>>>
>>>URLs have a tendency to be passed around, cached, stored in config files
>>>and are generally promiscuous. For example. it's not inconceivable that
>>>a URL could be printed in a stack trace thereby possibly exposing any
>>>password in it to a user in a browser or terminal window.
>>>
>>>For real applications, URLs should never contain passwords. It's only
>>>provided as a convenience to the developer for experimental purposes or
>>>for user's who do not require any guarantee of security.
>>>
>>>Mike
>>>
>>> 
>>>
>>>      
>>>
>
>
>  
>
-------------- next part --------------
HTML attachment scrubbed and removed


More information about the jcifs mailing list