The Common Internet File System (CIFS) also known as Server Message Block (SMB) is a network protocol whose most common use is sharing files on a LAN. The protocol allows a client to access servers, files and printers on the LAN as though they were on the local machine.
Microsoft uses CIFS in all flavours of Windows to provide it's networking capabilities i.e. Shares, Network Neighbourhood. Unix/Linux also use CIFS via Samba and Apple has several clients and servers available, thus it's a fairly interopable protocol.
CIFS has a client and a server part. The server is probably more applicable to us as we could expose the repository as a CIFS server. This would theoretically mean that the repository would show up in the Network Neighbourhood and users would be able to map the repository as a normal Windows drive letter.
The client capabilities may also be useful as we could import content from an existing network share, for example.
There is an open source implementation of a CIFS client called jCIFS.
The client library provides programmatic access to CIFS servers allowing the following:
- Domains and workgroups
- Servers within a domain/workgroup
- Shares available on a server i.e. folders, printers
- Files and folders within a share
- File/Folder Manipulation (with appropriate authentication)
- Create files/folders
- Read/Write files
- Delete files/folders
- Test for existence
- Retrieve properties
In order to access network resources you obviously need to supply login credentials.
These are provided in the URL you use to access the resource, for example:
The credentials can also be provided via the "jcifs.smb.client.username" and "jcifs.smb.client.password" properties. In turn there are several ways these can be provided to the client i.e. from command line, properties file etc.
However, it doesn't appear that these can be transparently picked up from the local machine i.e. single sign-on. In order to do that we would need to run from within a browser. We could then make use of the NTLM authentication filter jCIFS provides to source the credentials via the browsers challenge/response mechanism (although this would probably be IE only).
As mentioned above it makes more sense for us to try and provide a CIFS server interface to the repository. This means the repository can become accessible via Windows Network Neighbourhood and as a shared network drive.
JLAN Server is a commercial product that provides a Java based CIFS/SMB server. It fronts a virtual file system that can be mapped to a physical file system, a database or any other type of content repository. The easiest route for us to take would be to provide a JLAN virtual file system implementation of our repository API, however, as mentioned above it is a commercial product and therefore not distributable in an open source project.
An attempt to decompile the downloadable demo was unsuccessful. It appears they have obfuscated the code supplied in the JAR files, so most of the classes and their contained methods are reduced to a, b, c, d etc. Furthermore, most those classes with meaningful names fail to decompile!
Using the downloaded demo I was able to setup a CIFS server that was accessible across our ACTIVITI domain. I used the JavaFileDiskDriver virtual file system to point to a local folder on my machine. I was then able to browse the share via Network Neighbourhood and as you would expect to map a drive letter to the share. Derek was also able to browse the network and read the contents of my fake repository via Network Neighbourhood. Although I was using a JLAN class to provide the file system it would be fairly easy to replace this with an implementation that used our sevice APIs.
Setting up the server however revealed how much of a mammoth task it will be to provide our own CIFS server. I know we wouldn't need quite as much support as JLAN has but the installation guide has 30+ pages of configuration options! It's also evident seeing the debugging statements coming from the server that a great deal of networking knowledge (NETBIOS) is going to be required to implement anything useful, something I certainly don't have!!
JLAN Server has 2 built-in authentication approaches, one is handled by JLAN itself and the other is a pass through authenticator allowing a domain controller to be used to authenticate clients.
I excercised both these approaches above. The local authentication specified users in the config file. Using this scheme I was presented with a login dialog to gain access to the test share I created. Once I switched to using the pass through authentication my network credentials were used to give me access to the share with no logon required.
JLAN Server's code was not available so I can't comment on it's quality or complexity but if the jCIFS code is anything to go by it will be horrendous in terms of complexity. It's obvious that to implement this stuff you will have to have intimate knowledge of the contents of each packet (to the byte level) that makes up a request to make anything useful happen!
Furthermore, given the sheer amount of code there is to reproduce to implement this ourselves will take way more than the 2 and a half months we have left!