[jcifs] 1.3.x filter authentication problem

[Hannes B.]

Thanks for answering and your professional comments!

I try to sumarize:

- A new ClassLoader

Is possible, I tried to implement and had success but thats not the global solution! It's also possible to rename the package jcifs to jcifs12 in the source version and include two jcifs libs. (yes, banned).

If it's possible to configure jcifs "per instance", you don't think about that!

- config

per Thread:

Not the best solution: Tomcat with two filters with different jcifs configurations. The filters have the same thread!



I agree to John!
We have to find a way to use a "key" class where we put the properties!

I like static calls, but i don't like it in libraries because i can't do anythin around it. 
If i need static properties or access, i wrap around the library. That's not possible if the library is "static".

It would be great if the jcifs library allows instance oriented configurations.



-------- Original-Nachricht --------
> Datum: Tue, 10 Feb 2009 08:30:12 -0000
> Von: John.Baker at barclayscapital.com
> An: jcifs at lists.samba.org
> Betreff: RE: [jcifs] 1.3.x filter authentication problem

> My question was unrelated to the filter - it was a general question
> about configuration of jcifs.
> 
> I don't understand why there would be any threading issues with a
> separate Properties object per instance of a jcifs object, unless there
> are more statics lurking in the code.  
> 
> So, the answer is to be able to pass Properties objects into the
> constructors of key objects (like SmbFile).  Or bind configurations to
> Threads (less nice but entirely do-able). 
> 
> And then the HttpFilter can remain in Jcifs, and perhaps we can put some
> work into new filters (for Kerberos, given they seem to be floating
> around as ext packages).
> 
> > -----Original Message-----
> > From: 
> > jcifs-bounces+john.baker=barclayscapital.com at lists.samba.org 
> > [mailto:jcifs-bounces+john.baker=barclayscapital.com at lists.sam
> > ba.org] On Behalf Of Michael B Allen
> > Sent: 09 February 2009 18:15
> > To: Caldarale, Charles R
> > Cc: jcifs at lists.samba.org
> > Subject: Re: [jcifs] 1.3.x filter authentication problem
> > 
> > On Mon, Feb 9, 2009 at 11:36 AM, Caldarale, Charles R 
> > <Chuck.Caldarale at unisys.com> wrote:
> > >> Subject: RE: [jcifs] 1.3.x filter authentication problem
> > >
> > > (Sorry for the previous message - fumble fingers on the keyboard.)
> > >
> > >> How does one create two instances of Jcifs, with different 
> > >> configurations, within one VM?
> > >
> > > You will need a separate classloader for each instance of 
> > jCIFS.  If you're running inside Tomcat, each webapp uses a 
> > separate classloader already; just put the jCIFS jar in the 
> > WEB-INF/lib directory of each webapp.  Do not put the jar in 
> > Tomcat's shared directory.
> > 
> > Note that doesn't really help with the static properties 
> > issue since the only way to set some properties reliably is 
> > with through commandline using -Djcifs.properties=file.prp.
> > 
> > Just like the Windows CIFS client and smbclient, the 
> > configuration in JCIFS is global and static. For example, on 
> > Windows the LmCompatibilityLevel is in the registry and 
> > extended security is basically hard coded into the client. 
> > These are not things that can be changed at runtime. Meaning 
> > they're global and static.
> > 
> > The heart of the problem in this thread is that servlet 
> > containers set things at runtime using init-params but the 
> > Filter doesn't support
> > NTLMv2 so the new 1.3 default values of
> > jcifs.smb.client.useExtendedSecurity=true and
> > jcifs.smb.lmCompatibility=3 are wrong for the Filter. 
> > Strangely I would think this should still work since the 
> > properties aren't actually set the JCIFS classes are first 
> > loaded. But it looks like Tomcat at least is maybe loading 
> > some JCIFS classes before it actually reads the init-params 
> > so some init-params are basically ignored.
> > 
> > Fortunately this issue is largely specific to the combination 
> > of the Filter not supporting NTLMv2 and how some servlet 
> > containers load classes. So none of this really matters much 
> > since the Filter is effectively deprecated.
> > 
> > But it doesn't mean that we can't make the JCIFS 
> > configuration more flexible in the future. It would be nice 
> > to be able to supply different configurations. But if the 
> > config is not global and static the issue is "where do you 
> > put it?". My thought is that we can hang it on the current 
> > thread or stick it in the JAAS Subject so that it get's 
> > inherited (are Subjects inherited when creating new 
> > Threads?). But of course that's a fairly radical change and 
> > requires touching code in many places so it is not going to 
> > happen soon.
> > 
> > Note that some people have suggested that this could be 
> > "fixed" by simply making the properties non-static. That 
> > would not be thread-safe. Meaning thread 1 could set property 
> > a, then thread 2 could set property a and then thread 1 could 
> > act on property a with the wrong value and get the wrong 
> > result or a mysterious error.
> > 
> > In hindsight I should have removed the Filter in 1.3 so that 
> > people would be forced to use 1.2 which has exactly the same 
> > Filter code with the right default values for 
> > useExtendedSecurity and lmCompatibility.
> > 
> > Mike
> > 
> > --
> > Michael B Allen
> > Java Active Directory Integration
> > http://www.ioplex.com/
> > 
> _______________________________________________
> 
> This e-mail may contain information that is confidential, privileged or
> otherwise protected from disclosure. If you are not an intended recipient of
> this e-mail, do not duplicate or redistribute it by any means. Please
> delete it and any attachments and notify the sender that you have received it in
> error. Unless specifically indicated, this e-mail is not an offer to buy
> or sell or a solicitation to buy or sell any securities, investment products
> or other financial product or service, an official confirmation of any
> transaction, or an official statement of Barclays. Any views or opinions
> presented are solely those of the author and do not necessarily represent those
> of Barclays. This e-mail is subject to terms available at the following
> link: www.barcap.com/emaildisclaimer. By messaging with Barclays you consent
> to the foregoing.  Barclays Capital is the investment banking division of
> Barclays Bank PLC, a company registered in England (number 1026167) with its
> registered office at 1 Churchill Place, London, E14 5HP.  This email may
> relate to or be sent from other members of the Barclays Group.
> _______________________________________________