> 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
Well, I've been under impression that they look up roles and users information behind the scenes. At least, it happens when the Slide API is used directly. Actually, doesn't the "scope" parameter of the Slide servlet effectively block any access to all files that are not exposed by its value (/files means that a user can see only the resources below /files)? If it's not true, it might be a breach in our security... > 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? Updated - no. Theoretically, they can be deleted (WebDAV doesn't prohibit it, afaik). I don't know if Slide allows it though, but will have to find out soon... Well, it's another story. :-) Yours sincerely, Andrey. > > -----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]
