I don't have a question, but I thought I'd post my findings to the list so that others (including myself in the future) can benefit and hopefully be able to find this via Google.
I have Slide 2.1 (latest stable release at the time) deployed. This server will be accessed from a number of different clients: Windows users that use the "map a network drive" feature and connect to Slide using the URL to the deployed server. Web sites that will have URLs to files that are on the Slide server. Mac OS X users that will connect to the Slide server by choosing "Connect to server" from the Finder's Go menu. What I wanted was to allow anyone to read files under Slide's /files directory, but only allow certain roles to write (and delete) files. I also have Slide set up to automatically version-control new files. I had the server configured like I wanted it and Windows users could connect to Slide and add and delete files in the /files subdirectories that they had access to. If a user didn't have permissions to read from a certain folder, that folder did not appear on their computer. I was able to reference files on the Slide server's /files directory (and its subdirectories) from a web page and I could access those files without having to login to Slide. However, Mac OS X users were able to connect to Slide, but they couldn't write files to directories they had write permissions on and they weren't able to see certain directories unless they selected "Go to folder..." in the Finder's Go menu and explicitly type the name of the directory. Looking at the log files, it appeared that when a Windows client authenticated with the Slide server, all subsequent requests used that authentication information (like it should), but when a Mac OS X client authenticated with the Slide server, it only used the authentication information when unauthenticated users did not have read permission, otherwise it connected as an unauthenticated user. After trying every ACL setup I could think of without success, I thought the bug was in the Mac OS X built-in WebDAV capabilities. But, I noticed that when you access a directory through the Mac client, it issues PROPFIND methods for each subdirectory (as unauthenticated) and I found a page on Apple's site that states that the WebDAV functionality in OS X only sends authentication information if the server asks for it. Looking at the Slide server's web.xml file gave me the answer. It turned out that I needed to change the security-constraint setup (it's right below the comments that read "Uncomment this to get authentication"). I used multiple security-constraint elements to set up the server so that any GET method on /files/* does not require authentication (you specify this by not including an auth-constraint element inside the security-constraint). This was so that when web pages reference a file on the server (like in an img tag), they don't need to authenticate before they get access to the file. I have another security constraint that requires authentication if any of the other HTTP or WebDAV methods are used on /files/*. Those methods are listed further down in the web.xml file. This solved the problem! Now Mac OS X clients can see and read and write to all the directories that the Windows users were able to, and web pages can still reference files on the Server without requiring authentication. I highly recommend editing Slide's logging format pattern as the default does not give sufficient information to debug some access problems. You can do this by changing the logFormat init-parameter in the webdavlog filter at the top of the web.xml file. Set the value so that it uses all the placeholders specified in that init-parameter's description. When you restart the server, you'll notice that the Slide server log now includes extra information, especially on error messages like 403 Forbidden. It will tell you what action it was trying to perform, instead of the default "Unauthorized". - Michael James --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
