[jcifs] Re: Any Support for Encrypted Transactions

Michael B. Allen miallen at eskimo.com
Mon May 6 18:09:06 EST 2002


On Sun, 5 May 2002 16:33:15 -0400
"Andrew Chernow" <achernow at earthlink.net> wrote:

> Mike,
>    I figured it could be done by adding to the jCIFS package, but I didn't
> want to build a tool which already exists.  I will submit a SSLNbtSocket
> class and any modifications to existing classes when I have a working
> version.  I assume others could make use of a `jcifs.smb.client.useSSL=true'
> option.  I appreciate your prompt response and suggestion.

That part's easy. I think figuring out all the certificates and managing
the keystore and all that crap is the hard part. There are some methods
on SSLSocket that may need to be called with appropriate parameters. If
you can do that nicely without messing up SmbTransport.java too much I
would very much like to include that in the standard distribution.

> 
>    On another note, I have created an interface called XFile.  I used 'X'
> for a lack of a better name.  An XFile makes it possible to work with a
> java.io.File and a jcifs.smb.SmbFile as if they were the same.  Only the
> methods found within both classes are defined within the XFile interface,
> excluding a few.  I then went ahead and created a JXFile and SmbXFile which
> both implement XFile.  From there I assume you can image what occurs,
> wrapping.  I made this becuase I am working with a lot with File and SmbFile
> objects.  Most of the code manipulating the two is the same.  I wanted to
> avoid
> 
>    if(file instanceof File)
> 
> statements everywhere.  I added a convience method to the XFile class,
> isSmb(), for my own uses.  This is a custom addition for my project becuase
> I am a programmer which means I am lazy.  I would rather go,
> if(xfile.isSmb()), then, if(xfile instanceof SmbFile).  There are some cases
> where you need to distinguish between the two.  I am not sure if this method
> should be there on an overall generic view.  One might want to create their
> own implementation of an XFile where isSmb() would be out of place.
> 
>    I am using XFile right now within a TreeNode class I called XFCNode for
> "XFile CheckBox Node".  These nodes are displayed within a File System
> TreeModel.  The TreeModel simply models the data like Windows Explorer,
> w/checkboxes.  By using XFile, I can use the same TreeRenderer, TreeModel,
> TreeNode and JTree custom classes for either an SmbFile or File object.
> Thus getting a local or Remote folder-tree view of files just by changing
> the root node.
> 
> Example:
> 
> XFCTree localTree = new XFCTree(createTreeModel(true));
> XFCTree remoteTree = new XFCTree(createTreeModel(false));
> 
> protected TreeModel createTreeModel(boolean local)
> {
>    XFile root = null;
>    if(local)
>    {
>       File f = new File("fileSystemRootPath");
>       root = new JXFile(f);
>    }
>    else
>    {
>       try
>       {
>          SmbFile f = new SmbFile("smb://rootOfShare");
>          root = new SmbXFile(f);
>       }
>       catch(SmbException e){}
>    }
> 
>    // this tree model creates XFCNodes and requires an XFile as argument
>    // it's constructor:
>    // public XFCTreeModel(XFile xfile){
>    //    super(new XFCNode(xfile));
>    // }
>    return new XFCTreeModel(root);
> }
> 
> // now when nodes are selected I can work with them generically, or when
> renderered - ect...
> localTree.addTreeSelectionListener(this);
> remoteTree.addTreeSelectionListener(this);
> 
> public void valueChanged(TreeSelectionEvent e)
> {
>    JTree tree = (JTree)e.getSource();
>    if(tree==null)
>       return;
> 
>    // prints some file attributes to STDOUT
>    XFCNode node = (XFCNode)tree.getLastSelectedPathComponent();
>    XFile xfile = node.getXFile();
>    System.out.println("Name: "         + xfile.getName());
>    System.out.println("Path: "         + xfile.getPath());
>    System.out.println("Length: "       + xfile.length());
>    System.out.println("Exists: "       + xfile.exists());
>    System.out.println("File: "         + xfile.isFile());
>    System.out.println("Directory: "    + xfile.isDirectory());
>    System.out.println("LastModified: " + new Date(xfile.lastModified()));
> 
> System.out.println("--------------------------------------------------------
> \n");
> }
> 
> I have attached XFile, SmbXFile and JXFile if your interested.  The classes
> are pretty straight foward but have proven to be quite powerful to use.
> Sometimes it's the simple concepts that can save you tons of logic and/or
> lines of code.  I don't know if this is something the jCIFS package needs,
> but I thought I would let you decide that.  I found it quite useful.  If I
> ever have something to contribute to an open source project, which I am
> using freely, I do!

Well this is interesting. I don't think it would be appropriate for me
to explore this as an option for jCIFS at the moment but it is something
to consider. Did you know that Sun's WebNFS product has a File like
API that uses the name 'XFile'? It's similar in purpose but it doesn't
extend java.io.File. I suppose it would be possible to have SmbFile
directly extend java.io.File *and* implement Suns XFileAccessor for
interoperability. But this is really a >1.0 thing. The first step was to
solidify a working product. I think we've done that. The next step is to
polish it up (need trivial stuff like copyTo()) finalize the docs and do
a 1.0 release. Then I can get philosophical about things like extending
java.io.File so users and swap it into their TreeModel and implement
XFileAccessor so it plays nice next to WebNFS. Of course there's a
long list of other pressing functionality like long Unicode share names
(requires DCE/RPC). Right now I have to be real practical-like because
there are companies that use this client in their products so I try to
to screw with it too radically. Just stability and speed.

In the mean-time I'll redirect your attachment to the mailing list. They
might indeed find it useful and I'll know how to find it in the future.

Mike

> --- "Michael B. Allen" <miallen at eskimo.com> wrote:
> > On Sat, 4 May 2002 22:40:31 -0700 (PDT)
> > andy chernow <achernow at yahoo.com> wrote:
> >
> > > Hello JCIFS Team,
> > >    I am creating an Java Client Application which
> > > communicates with a Samba server running on RedHat
> > > 7.2.  I have configured the Samba Server with SSL. I
> > > need to have the transactions encrypted.  Is there a
> > > way to get the SmbFileOutputStream and
> > > SmbFileInputStream to communicate with a Samba Server
> > > with SSL?  I did notice the DES class and SmbSession
> > > so I am not sure if the tools are already right under
> > > my fingers.  I am a little lost on how I would do this
> > > with your package.  Any suggestions, directions, links
> > > or samples would be very much appreciated.
> > >
> > > I am using jcifs version 0.6.2.
> >
> > This is just a guess but I would try to just get the
> > javax.net.ssl
> > package (JSSE) from Sun and copy
> > jcifs/netbios/NbtSocket.java to
> > jcifs/netbios/SSLNbtSocket.java but make it extent
> > javax.net.ssl.SSLSocket
> > instead of plain java.net.Socket. Then add a
> > property like
> > jcifs.smb.client.useSSL=true/false and have that
> > switch the Socket type on
> > line 237 of jcifs/smb/SmbTransport.java (you can
> > just change all instances
> > of NbtSocket to just Socket to make the code
> > generic). Provided you get
> > all the certificates worked out and all that crap,
> > that's it! Easy :~)
> >
> > Mike

-- 
May The Source be with you.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: xfile-achernow.zip
Type: application/zip
Size: 2392 bytes
Desc: not available
Url : http://lists.samba.org/archive/jcifs/attachments/20020506/f8a3780d/xfile-achernow.zip


More information about the jcifs mailing list