[jcifs] 1.3.x filter authentication problem

Wed Feb 11 13:45:09 GMT 2009

Hannes,

Statics are generally bad news in any low level API, because it often
prohibits it from being a useful API in any web application (or anything
that is generally deployed X times on one VM).

My use of static generally involves little more than declaring
constants.

John

> -----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 Hannes B.
> Sent: 11 February 2009 13:02
> To: jcifs at lists.samba.org
> Subject: Re: RE: [jcifs] 1.3.x filter authentication problem
> 
> 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.
> > _______________________________________________
> 
_______________________________________________

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.
_______________________________________________