I meant restrict in terms of both :-) And you're right in that I do need the /history path to be visible to users so they can see pervious revisions so I need to use access control to manage this path. We use a secure web proxy application that junctions web webapps to itself and access control can be placed on these junction paths. Basically I had thought of restricting access to slide paths using this mechanism. So my question was really whether or not refusing access to a path altogether using this proxy would cause any problems. From your and Stefan's reply I see that I can block access to /actions, /roles, /users and /projector etc with this proxy with no ill effects. I don't want my users seeing the list of actions, roles and users in the system. But I will need to leave /history exposed so that users can view other revisions.
I don't know about updating these revisions though... I didn't think revisions could be updated? Thanks, Warwick > -----Original Message----- > From: Andrey Shulinsky [mailto:[EMAIL PROTECTED] > Sent: Thursday, February 03, 2005 8:11 PM > To: 'Slide Users Mailing List' > Subject: RE: Restricting access to /history? > > > Hi, Warwick! > > > Is there any reason that I shouldn't be able to restrict > > client access to every directory under /slide other than > > files. For instance I don't want the client to see /history > > or /actions or /users. Does the client ever need access to > > any of these paths for a legitimate reason or can the client > > be constrained to making DAV requests under the /files path > > with no ill-effects? > > May I ask what do you mean by "restrict"? Is it "restrict by > means of "permissions" or "restrict by means of the scope > exposed to users"? > > If it's about permissions, I believe the following access > rights should be > granted: > > If you store the versions of your files under the /history > (the default > setting) then every user that can create/update a versioned > file needs inheritable "write" permissions to this directory. > Every user needs inheritable "read" access to the /users > (again, if you store user profiles there). I thought the same > rule applies to the /actions but looks like it doesn't - by > default an ordinary user has no access rights to this > directory and we use the default setting. And every user > should have the non-inheritable read permission to the root > directory (i.e. / ). Otherwise some nasty exception is > thrown, can't remember the details, can check if you're curious. > > If you just want to use the "scope" parameter of the Slide > servlet like this > > <param-name>scope</param-name> <param-value>/files</param-value> > > then you can do it without any problem, I think. > > BTW, we use Slide 2.0 and standard TxXMLFileDescriptorsStore > & TxFileContentStore > > Yours sincerely, > Andrey. > > > > --------------------------------------------------------------------- > 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]
