Experiences with WebDAV Construction Kit
I'm wondering if anyone would mind sharing their experience with the WebDAV Construction Kit? How stable have you found it to be? Also, can I support ACLs and versioning with the kit? I know the site says you can't, but I'm hoping that has changed. :) - Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Experiences with WebDAV Construction Kit
Thanks for the feedback! Those are impressive numbers. It is comforting to know that WCK can withstand such stress. Now I just need to figure out ACLs and versioning. :) - Andy On Friday 04 February 2005 08:50 am, John Rousseau wrote: > I used the WCK to put a WebDAV front end on our product. I don't do ACLs > or versioning. Our QA folks recently put 250 million files via 20 > threads through slide into our archive without any errors. The narrow > paths that we have exercised seem stable to me. > > -John > > Andy Depue wrote: > > I'm wondering if anyone would mind sharing their experience with the > > WebDAV Construction Kit? How stable have you found it to be? Also, can > > I support ACLs and versioning with the kit? I know the site says you > > can't, but I'm hoping that has changed. :) > > > > - Andy > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Duplicating security information?
OK, I need ACLs and versioning so I guess WCK isn't for me. The one thing I want to avoid in my system is duplicating security information for a user. This would be the username, password, and the user's roles. We already manage user/passwords/roles in our system, and would like Slide to use our user repository instead of its own. As I look through Slide source code, it is beginning to appear that Slide is really wired to look into its own Store for security information. This leaves me with three choices: 1. Reimplement the Security interface to use my user resository. Very big task there. 2. Create my own Store implementation that wraps Slide's security store so that user/password/user role information is pulled from my user repository while ACLs and all other information is passed through to Slide's security store. Not sure how hard this is... but at first glance it doesn't look straightforward. 3. Have our security system duplicate user information in Slide and keep the two separate systems in sync. None of these options seem very palatable to me. Am I missing something? Does Slide really not provide an easy way for me to supply it with the currently authenticated user AND his/her roles? To me, the ideal solution would be to hand Slide a preauthenticated token of some sort that says, "I've already authenticated this guy and vouch for him - oh, and btw, these are the roles he is granted." Any information or help in this area is greatly appreciated! Thanks, Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Duplicating security information?
Thanks for the response! If I go ahead with this, my plan is to mimick a good idea that Ben Alex had for his Acegi Security framework, which is to create an adapter that would implement the store interfaces (like JNDIPrincipalStore does), but translate and delegate to a simplified DAO that one could implement for various security backends. It is easy to adapt Acegi to your own security system because all you have to do is implement a simple DAO interface from Acegi - the same should be possible for Slide. As I look over the JNDIPrincipalStore implementation I can see there is a lot of Slide specific API "protocol" going on that I'm going to have to parse. A simple DAO interface would make this much easier. I'm not sure what the DAO interface is going to look like yet (it will be read only at this point, like the JNDIPrincipalStore), but it sure would be nice to have something as simple as this: Collection getUsers(... some sort of Slide related criteria ...) Collection getUserRoles(String username) It seems like such a common thing people want to do, it is will worth the effort of creating this interface. Well, I'm off to parse the Slide API... any tips are appreciated. :) - Andy On Tuesday 08 February 2005 07:00 pm, Carlos Villegas wrote: > Andy Depue wrote: > > None of these options seem very palatable to me. Am I missing something? > > Does Slide really not provide an easy way for me to supply it with the > > currently authenticated user AND his/her roles? To me, the ideal > > solution would be to hand Slide a preauthenticated token of some sort > > that says, "I've already authenticated this guy and vouch for him - oh, > > and btw, these are the roles he is granted." > > Any information or help in this area is greatly appreciated! > > No, there doesn't seem to be an easy way. You'll need to write your own > store. You can take a look at the JNDIPrincipalStore which is close to > what you want to do; it retrieves users and roles from an LDAP directory. > > There was an idea of writing a store that retrieves users and roles from > a JAAS LoginModule which is a standard way to plugin different > authentication systems. However, there are issues about how to map the > WebDAV model to JAAS. JAAS handles authentication but it doesn't seem to > provide a way to list all users and roles, which is needed by Slide. > Anyway, I may take a look at this later, but I don't know when I'll be > able to do that. > > Carlos > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Configuring a principal store
OK, I've coded my own Principal store based on code from JNDIPrincipalStore and am setting up a test configuration. I'm a little confused how to setup domain.xml. First, my store will only handle /users and /roles. Everything else will be handled by J2EEStore. So, do I setup two separate and distinct entries under (one for J2EE and one for my custom principal store), or do I setup one entry and use my custom class for the element? Something like: ... If I setup two entries, they might look something like: ... ... ... Is this even right? And if so, I'm a little confused what is all about? If someone has a configuration similar working with JNDIPrincipalStore, I'd love to see it. The Wiki was unhelpful concerning how I should approach this. It has a section on multiple store configurations, but doesn't address if one of the stores happens to handle principal information. The element is what's throwing me off here. Thanks, Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WebDav Acces (User Auths) with JDBC Datasource
I submitted code a few weeks ago to accomplish something very similar. You will still have to write a few simple methods (by implementing a DAO style interface) to retrieve your users from MySQL, but my contribution takes care of mapping your user info to the principal store format that Slide expects. My code also assumes that you are not relying on Slide to authenticate, but have already authenticated the current user before entering Slide. My "principal store" implementation does not expose passwords to Slide, only user information, roles, etc. Take a look at http://issues.apache.org/bugzilla/show_bug.cgi?id=33639 for my contribution. I also include code to integrate Acegi authentication (which is what we use) with Slide's WebDAV servlet - and to facilitate some IoC style configuration (in my case, Spring). - Andy On Thursday 17 March 2005 08:01 pm, Michael J. Prichard wrote: > Hello. > > I am trying to set up a webdav server that hits a MySQL database to get > the authentication information. I also want to direct the user to their > "home" directory structure after they log in. > > Is this possible and, if so, does anyone out there have any experience > with it? > > Thanks, > Michael > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WebDav Acces (User Auths) with JDBC Datasource
WebDAV is only part of our architecture. We have rich clients that also communicate with services via Spring's http based remote protocol and via JMS. Sometimes the client may access a document directly, but sometimes the client may invoke a service which then needs access to a document. The user must be authenticated to access the service, which must be authenticated to access the document (with the user's priveledges). We wanted to keep all authentication in one place (Acegi) and handle it consistently in all cases for security purposes, scalability purposes, and auditing purposes. Acegi provides a set of servlet filters that handle all authentication up-front, before servlets are invoked (such as the remote invocation servlet, or the remote JMS servlet, or the WebDAV servlet). This keeps authentication in one "place", which benefits those things I mentioned earlier (security, scalability, and auditing). - Andy On Friday 18 March 2005 08:28 am, Michael J. Prichard wrote: > Hey Andy, > > Thanks for the response and the code. I am curious, what reason did you > build the authentication outside of Slide? > > I am new to Slide (and Webdav) so please bear with me :) > > Thanks, > Michael > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
WebdavResource and transactions
I'm using WebdavResource to access a Slide WebDAV servlet. My question is simple: do I need to call lockMethod when using transactions? For example, do I have to do something like this: resource.startTransaction(...) resource.lockMethod(...) or resource.lockMethod(...) resource.startTransaction(...) Or does this not make sense for Slide? Does startTransaction automatically lock? I've run into a deadlock issue and suspect this has something to do with it. - Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Multiple WebdavResource in one transaction
Hello, I'm wondering if someone could tell me how to have multiple WebdavResource instances participate in a single transaction? Thanks, Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Versioning: Conent cloning on PROPPATCH.
The ideal here, of course, would be for versioning to store deltas. If a property changes, record the change in the property alone, etc. If the content is text and the content changes, store a diff, not a new copy (much like CVS). If the content is binary, then store a binary delta. There are open source Java projects available for performing binary deltas, such as http://sourceforge.net/projects/xdelta - Andy On Friday 29 April 2005 12:44 am, Denis Zvonov wrote: > Hi guys, > > We found that when PROPPATCH is executed on a versionable resource a new > version (new file or VERSION_CONTENT record in case of RDBMS) of content > is produced too. This leads to inacceptable cloning of content which > leads to storage size growth. When we plan to store thousands or even > millions of files with the total volume of tenths of gigabytes, this > cloning becomes a very unpleasant... > > Can there be a way to write a storage or any other way not to clone > !_unchanged_! content? > > > Also there is another issue with Slide implementation. When we configure > Slide to store content in filesystem and all other things in Oracle, > content of previous versions is stored in Oracle anyway. There should be > allowed some history_content_store pluggable, I think. > > Another issue with Oracle store implementation. Revoking of privileges > from resources has error in SQL statement and does not work. > > We use Slide 2.1 > > Best regards. > Denis. > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
