RE: Procedure for adding code ? Updated inheritable properties
Nick, I patched up our webdav client and slide server with the source you send. I still am not sure how to create an ace that will not propogate down the repository tree. Here is the sample code I am using, can you confirm it is the right way to create a ace that should not inherit downwards ... bInherited = false; ace = new Ace(sPrincipal, bDenyPrivilege, bProtected, bInherited, null); What does the fourth argument mean? Does it mean that this ace is an inherited one or does it mean that this ace should not inherit downwards. I did not see any change in the interface after applying your patch ... Please correct me if I am wrong Krishna -Original Message- From: Nick Longinow [mailto:[EMAIL PROTECTED] Sent: Friday, February 04, 2005 12:59 PM To: 'Slide Users Mailing List'; [EMAIL PROTECTED] Subject: RE: Procedure for adding code ? Updated inheritable properties Oliver This code is good; I pulled, diffed, built and ran the binaries against my test set with success. Thanks for putting it into the system. Nick -Original Message- From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] Sent: Thursday, February 03, 2005 4:07 PM To: Slide Users Mailing List Subject: Re: Procedure for adding code ? Updated inheritable properties I have just committed the patch to the Slide CVS Head which will become Slide 2.2. Applying it to the 2.1 branch was not appropriate as it is a new feature and only bug fixes should go into it. Nick, could you please check if everything looks alright now? Oliver On Thu, 3 Feb 2005 10:18:58 -0500, Nick Longinow [EMAIL PROTECTED] wrote: I'd ask one of the committers for a date. Till then, you and anyone else is welcome to use the patched source. Nick -Original Message- From: Krishna Kankipati [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 02, 2005 3:43 PM To: 'Slide Users Mailing List' Subject: RE: Procedure for adding code ? Updated inheritable properties Nick, We are waiting on this fix for a release this month end, do you think this patch will be approved by then? Where do I get the patch from . Krishna -Original Message- From: Nick Longinow [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 02, 2005 1:18 PM To: 'Slide Users Mailing List' Subject: RE: Procedure for adding code ? Updated inheritable properties You might have to wait longer; I don't know how long it takes for the committers to actually apply the patch, assuming they even accept it. Nick -Original Message- From: Krishna Kankipati [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 02, 2005 3:12 PM To: 'Slide Users Mailing List' Cc: Martin Olovsson Subject: RE: Procedure for adding code ? Updated inheritable properties Nick, Great, I have been waiting for this change for quiet some time ... thanks a bunch Krishna -Original Message- From: Nick Longinow [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 02, 2005 1:11 PM To: 'Slide Users Mailing List' Subject: RE: Procedure for adding code ? Updated inheritable properties Yes. Exactly so. -Original Message- From: Krishna Kankipati [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 02, 2005 3:06 PM To: 'Slide Users Mailing List' Subject: RE: Procedure for adding code ? Updated inheritable properties Nick, Does this mean that with this patch we can use webdav client to add Ace that has inheritable false to an ACL? Basically I am trying to use webdav client to be able to create a permission that should not inherit down the repository tree. Is it possible with your code change? Krishna -Original Message- From: Nick Longinow [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 02, 2005 9:53 AM To: 'Slide Users Mailing List' Subject: RE: Procedure for adding code ? Updated inheritable properties Will do. -Original Message- From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 01, 2005 4:50 PM To: Slide Users Mailing List Subject: Re: Procedure for adding code ? Updated inheritable properties Would be best to create a bugzilla entry and attach your paches. Oliver On Tue, 1 Feb 2005 14:45:27 -0500, Nick Longinow [EMAIL PROTECTED] wrote: I've (with much help) added parameters to the Ace plumbing to add the attribute 'inheritable' to an Ace. What is the process for returning this code to the Slide community so that it becomes part of the products ? (both server and webdav client were updated). Nick - 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: Procedure for adding code ? Updated inheritable properties
Nick, Does this mean that with this patch we can use webdav client to add Ace that has inheritable false to an ACL? Basically I am trying to use webdav client to be able to create a permission that should not inherit down the repository tree. Is it possible with your code change? Krishna -Original Message- From: Nick Longinow [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 02, 2005 9:53 AM To: 'Slide Users Mailing List' Subject: RE: Procedure for adding code ? Updated inheritable properties Will do. -Original Message- From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 01, 2005 4:50 PM To: Slide Users Mailing List Subject: Re: Procedure for adding code ? Updated inheritable properties Would be best to create a bugzilla entry and attach your paches. Oliver On Tue, 1 Feb 2005 14:45:27 -0500, Nick Longinow [EMAIL PROTECTED] wrote: I've (with much help) added parameters to the Ace plumbing to add the attribute 'inheritable' to an Ace. What is the process for returning this code to the Slide community so that it becomes part of the products ? (both server and webdav client were updated). Nick - 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: Procedure for adding code ? Updated inheritable properties
Nick, Great, I have been waiting for this change for quiet some time ... thanks a bunch Krishna -Original Message- From: Nick Longinow [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 02, 2005 1:11 PM To: 'Slide Users Mailing List' Subject: RE: Procedure for adding code ? Updated inheritable properties Yes. Exactly so. -Original Message- From: Krishna Kankipati [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 02, 2005 3:06 PM To: 'Slide Users Mailing List' Subject: RE: Procedure for adding code ? Updated inheritable properties Nick, Does this mean that with this patch we can use webdav client to add Ace that has inheritable false to an ACL? Basically I am trying to use webdav client to be able to create a permission that should not inherit down the repository tree. Is it possible with your code change? Krishna -Original Message- From: Nick Longinow [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 02, 2005 9:53 AM To: 'Slide Users Mailing List' Subject: RE: Procedure for adding code ? Updated inheritable properties Will do. -Original Message- From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 01, 2005 4:50 PM To: Slide Users Mailing List Subject: Re: Procedure for adding code ? Updated inheritable properties Would be best to create a bugzilla entry and attach your paches. Oliver On Tue, 1 Feb 2005 14:45:27 -0500, Nick Longinow [EMAIL PROTECTED] wrote: I've (with much help) added parameters to the Ace plumbing to add the attribute 'inheritable' to an Ace. What is the process for returning this code to the Slide community so that it becomes part of the products ? (both server and webdav client were updated). Nick - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Procedure for adding code ? Updated inheritable properties
Nick, We are waiting on this fix for a release this month end, do you think this patch will be approved by then? Where do I get the patch from . Krishna -Original Message- From: Nick Longinow [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 02, 2005 1:18 PM To: 'Slide Users Mailing List' Subject: RE: Procedure for adding code ? Updated inheritable properties You might have to wait longer; I don't know how long it takes for the committers to actually apply the patch, assuming they even accept it. Nick -Original Message- From: Krishna Kankipati [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 02, 2005 3:12 PM To: 'Slide Users Mailing List' Cc: Martin Olovsson Subject: RE: Procedure for adding code ? Updated inheritable properties Nick, Great, I have been waiting for this change for quiet some time ... thanks a bunch Krishna -Original Message- From: Nick Longinow [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 02, 2005 1:11 PM To: 'Slide Users Mailing List' Subject: RE: Procedure for adding code ? Updated inheritable properties Yes. Exactly so. -Original Message- From: Krishna Kankipati [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 02, 2005 3:06 PM To: 'Slide Users Mailing List' Subject: RE: Procedure for adding code ? Updated inheritable properties Nick, Does this mean that with this patch we can use webdav client to add Ace that has inheritable false to an ACL? Basically I am trying to use webdav client to be able to create a permission that should not inherit down the repository tree. Is it possible with your code change? Krishna -Original Message- From: Nick Longinow [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 02, 2005 9:53 AM To: 'Slide Users Mailing List' Subject: RE: Procedure for adding code ? Updated inheritable properties Will do. -Original Message- From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 01, 2005 4:50 PM To: Slide Users Mailing List Subject: Re: Procedure for adding code ? Updated inheritable properties Would be best to create a bugzilla entry and attach your paches. Oliver On Tue, 1 Feb 2005 14:45:27 -0500, Nick Longinow [EMAIL PROTECTED] wrote: I've (with much help) added parameters to the Ace plumbing to add the attribute 'inheritable' to an Ace. What is the process for returning this code to the Slide community so that it becomes part of the products ? (both server and webdav client were updated). Nick - 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] - 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: Regarding Implementing ACL in slide.
Chaitanya, You can look at samples in the webdav client command client lib. If you download source code for webdav client , you will find a directory within it having source code for command line client. You can pick sample code from there and extend upon it. It has functions to fetch/grant/deny/remove permissions. hope this helps . regards, Krishna -Original Message- From: chaitanya [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 28, 2004 2:17 AM To: 'Slide Users Mailing List' Subject: Regarding Implementing ACL in slide. Hi all, I am a new comer to this webDAV (slide). We started using slide for our application i have done all the necessary functionalities like, uploading to a slide. maintaining versions. and all the basic things which is provided by the slide. Iam struck in implementing ACL and would be great if someone provides the basics of using ACL. It would be great if someone helps me in this regard. kind regards Naga Chaitanya.N V2Solutions A New Vision to Solutions India: +91-22-56733201 ext. 218 US : 1-408-705-2141 ext. 218 http://www.v2solutions.com TZ:GMT+5.30 -Original Message- From: Ollie [mailto:[EMAIL PROTECTED] Sent: Monday, December 27, 2004 1:08 AM To: Slide Users Mailing List; haipeng du Subject: Re: mix slide store Yes -Original Message- From: haipeng du [EMAIL PROTECTED] Date: Sun, 26 Dec 2004 11:38:49 To:slide-user@jakarta.apache.org Subject: mix slide store Could I use JDBC store as properties store and use file system to save file, just like: store name=tx parameter name=tlock-timeout120/parameter nodestore classname=org.apache.slide.store.impl.rdbms.JDBCStore parameter name=adapterorg.apache.slide.store.impl.rdbms.MySql41RDBMSAdapter/parame ter parameter name=drivercom.mysql.jdbc.Driver/parameter parameter name=urljdbc:mysql://localhost/slide/parameter parameter name=userroot/parameter parameter name=passwordslide/parameter parameter name=dbcpPoolingtrue/parameter !--parameter name=maxPooledConnections10/parameter parameter name=isolationSERIALIZABLE/parameter parameter name=compressfalse/parameter -- /nodestore !-- sequencestore classname=org.apache.slide.store.txfile.FileSequenceStore parameter name=rootpathstore/sequence/parameter /sequencestore -- securitystore reference store=nodestore/ /securitystore lockstore reference store=nodestore/ /lockstore revisiondescriptorsstore reference store=nodestore/ /revisiondescriptorsstore revisiondescriptorstore reference store=nodestore/ /revisiondescriptorstore contentstore classname=org.apache.slide.store.txfile.TxFileContentStore parameter name=rootpathstore/content/parameter parameter name=workpathwork/content/parameter parameter name=defer-savingtrue/parameter parameter name=timeout120/parameter /contentstore Is that Ok? -- Haipeng Du Software Engineer Comphealth, Salt Lake City - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Mike Oliver CTO, Alarius Systems LLC Las Vegas, Nevada USA Sent using my BlackBerry 6510 from Nextel - 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]
ACL Problem with Slide2.1 Beta2
Hi,
We were using slide 2.1 Beta 1 and were doing pretty good with ACL. Our
design for custom authentication was like this:
1. Disable web-server authentication (remove security constraint elements in
web.xml).
2. Enable slide security (in slide.properties)
2. Write a filter for webdav servlet. This filter captures every http
request and does custom authentication. After authentication, it sets a
principal object in session based on the logged-user (code for this is given
below)
This worked pretty well for Slide 2.1 B1, except that the slide trace
messages spitted out unauthneticated as the principal user. We were OK
with that because the ACL worked on the logged-user (user set in session as
a principal object).
When we upgraded to Slide 2.1 B2, slide server ACL was running on
unauthenticated instead of the principal user set in the session. Now
since ACL thinks that the logged user is unauthenticated, nothing works
I do not understand what changed between b1 and b2. Is this a bug
introduced, or am I supposed to do something extra for b2?
Any help appreciated .
Code for the servlet filter that custom authenticates .
public void doFilter(ServletRequest req, ServletResponse res,
FilterChain fChain) throws IOException, ServletException
{
// Cast to the Http specific class for the request and the
response
HttpServletRequest httpReq = (HttpServletRequest)req;
HttpServletResponse httpRes = (HttpServletResponse)res;
// Return exception if the filter config object is null
if(fConfig == null)
{
String sError =
SlideAuthenticationFilter.doFilter()::FilterConfig is null;
httpRes.sendError(WebdavStatus.SC_INTERNAL_SERVER_ERROR, sError);
return;
}
// Check for the authorization header. It will be used to
create the principal object
// for slide authorizations. All webdav client calls
from salespoint should have the
// Authorization header in the format BASIC
username:slideunlockkey. The string
// username:slideunlockkey should be encoded in
base64 format. The Slide un-lock key
// is a constant defined in this class (TODO save it in
an external editable resource).
String sAuthorizationHeader =
httpReq.getHeader(Authorization);
if(!authenticateRequest(sAuthorizationHeader))
{
String sError =
SlideAuthenticationFilter.doFilter()::Authentication failed, invalid slide
repository unlock key;
httpRes.sendError(WebdavStatus.SC_FORBIDDEN,
sError);
return;
}
// User is authenticated, let him through slide
// Fetch the http session object for this user, if none
create one
HttpSession httpSession = httpReq.getSession(true);
// SlidePrincipal is a simple implementation of Principal
interface
// Look if there is a principal object bound to the session
for the logged-in user
SlidePrincipal principal =
(SlidePrincipal)httpSession.getAttribute(org.apache.slide.webdav.method.pri
ncipal);
if((principal !=
null)(principal.getName().equals(this.sLoggedUser)))
{
// If valid principal exists in session
// Do nothing
}
else
{
// If principal object is not bound to session yet
create one
// If one is found but principal name does not
match, set it
if(principal == null)
{
// Create a new pricipal object
principal = new SlidePrincipal(sLoggedUser);
// Bind it to session
httpSession.setAttribute(org.apache.slide.webdav.method.principal,
principal);
}
else // Update the existing principal with the right
name
principal.setName(sLoggedUser);
}
fChain.doFilter(req, res);
}
thanks,
Krishna
RE: Adding a non-inheritable permission to a folder using webdav clie nt lib not working
Michael,
I completely agree with you.
All,
The reason I think this is very important for a complete ACL based
access system.
I have developed an admin UI for slide repository and the challenge
we are facing is that whenever a principal is assigned a permission
('write','all' etc ...) on a folder, I have to manually assign 'read'
permissions to all the upstream folders (for the user to be able to at least
navigate to that folder).
The problem with this approach is that the entire tree within 'files' folder
gets 'read' assigned to this principal, which breaks the whole purpose of
ACL.
I don't see any other way of getting around this problem than to set all
upstream folders (only those upstream folders user has to navigate to reach
the folder in question) to non-inheritable read. This way only those
folders which the user has to navigate to reach the folder on which he is
assigned a 'write' is accessible to him (to navigate only). I think if we
cannot to do this it would be a significant drawback to usage of slide
itself as an ACL platform.
I am wondering how the present production systems of slide get around this
problem I would like to hear from people who have implemented the
present ACL (vanilla server implementation for ACL) and build navigable
access based repository trees.
Any comments?
Thanks regards
Krishna
-Original Message-
From: Michael Smith [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 27, 2004 6:06 PM
To: Slide Users Mailing List
Subject: Re: Adding a non-inheritable permission to a folder using webdav
clie nt lib not working
Ingo Brunberg wrote:
The ACL spec states that you cannot modify an inherited or protected
ACE.
What about adding a new ACE? I'm not sure. If you add an ACE to a
collection, isn't it automatically inheritable? Might that depend on a
particular server implementation? I guess no implementation would
allow you to add a protected ACE. And maybe the ACL spec should be
changed to allow marking a new ACE as inheritable.
Reagrds,
Ingo
When setting an ACL (note that any modification to an ACL requires you
to set the _entire_ ACL: there's no way to just add/remove/modify a
single ACE), the inheritability of ACEs in the request is implementation
defined - anything could happen.
Slide interprets it as always being inheritable (this is the best option
available in the current spec, since there's no way for the client to
specify desired inheritability).
I'd support changing the spec to allow setting inheritability on ACEs
explicitly. I'm not sure what problems this might have for other
implementations, though - I suspect slide is unusual in being able to
set this seperately per-ACE.
Mike
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Adding a non-inheritable permission to a folder using webdav clie nt lib not working
All,
I think it would be an extremely important feature to have (rather
it's a handicap not to have that feature), how do you go about proposing to
the DAV acl spec group, I have never done that?
Krishna
-Original Message-
From: Warwick Burrows [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 28, 2004 10:20 AM
To: 'Slide Users Mailing List'
Subject: RE: Adding a non-inheritable permission to a folder using webdav
clie nt lib not working
Guys,
There was another email thread like this recently regarding a users need to
have the read bit on a folder to navigate through it to get to children. I
worked on an authorization product at one time and our solution was to
define another permission called traverse that would permit a user to
traverse through a collection but not be able to list or read the contents
of that collection. Incidentally, we also defined a list permission that a
user would need to actually list the contents of a particular collection -
though this was mainly for GUI purposes when traversing a visual tree by
clicking. I was surprised that the DAV acl spec doesn't define a traverse
permission as it is exactly what's needed to permit a user to traverse to a
certain point in the tree without being able to see any of the files in the
collections upstream.
Anyway, I realize that this doesn't help to solve your problem right now,
but my question is whether its the right answer for the DAV acl spec in
general. Would it be worth proposing this to the DAV acl spec group so that
we can make DAV access control more flexible and more useful in the future?
Warwick
-Original Message-
From: Krishna Kankipati [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 28, 2004 10:58 AM
To: 'Slide Users Mailing List'; '[EMAIL PROTECTED]'
Cc: Martin Olovsson; Jagadeesh Sunkara
Subject: RE: Adding a non-inheritable permission to a folder
using webdav clie nt lib not working
Michael,
I completely agree with you.
All,
The reason I think this is very important for a
complete ACL based access system.
I have developed an admin UI for slide repository and
the challenge we are facing is that whenever a principal is
assigned a permission ('write','all' etc ...) on a folder, I
have to manually assign 'read' permissions to all the
upstream folders (for the user to be able to at least
navigate to that folder).
The problem with this approach is that the entire tree within
'files' folder gets 'read' assigned to this principal, which
breaks the whole purpose of ACL.
I don't see any other way of getting around this problem than
to set all upstream folders (only those upstream folders user
has to navigate to reach the folder in question) to
non-inheritable read. This way only those folders which the
user has to navigate to reach the folder on which he is
assigned a 'write' is accessible to him (to navigate only). I
think if we cannot to do this it would be a significant
drawback to usage of slide itself as an ACL platform.
I am wondering how the present production systems of slide
get around this problem I would like to hear from people
who have implemented the present ACL (vanilla server
implementation for ACL) and build navigable access based
repository trees.
Any comments?
Thanks regards
Krishna
-Original Message-
From: Michael Smith [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 27, 2004 6:06 PM
To: Slide Users Mailing List
Subject: Re: Adding a non-inheritable permission to a folder
using webdav clie nt lib not working
Ingo Brunberg wrote:
The ACL spec states that you cannot modify an inherited or
protected
ACE.
What about adding a new ACE? I'm not sure. If you add an ACE to a
collection, isn't it automatically inheritable? Might that
depend on a
particular server implementation? I guess no implementation would
allow you to add a protected ACE. And maybe the ACL spec should be
changed to allow marking a new ACE as inheritable.
Reagrds,
Ingo
When setting an ACL (note that any modification to an ACL
requires you
to set the _entire_ ACL: there's no way to just add/remove/modify a
single ACE), the inheritability of ACEs in the request is
implementation
defined - anything could happen.
Slide interprets it as always being inheritable (this is the
best option
available in the current spec, since there's no way for the client to
specify desired inheritability).
I'd support changing the spec to allow setting inheritability on ACEs
explicitly. I'm not sure what problems this might have for other
implementations, though - I suspect slide is unusual in being able to
set this seperately per-ACE.
Mike
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED
RE: Adding a non-inheritable permission to a folder using webdav clie nt lib not working
Jason, Do you mean to say that it is not possible to set a permission to a folder that would not inherit to its children. Somehow if I set a permission in Domain.xml with inheritable=false, it does not job (I know it uses slide API directly). This contradicts your statement. Also, I am using webdav client-lib API. Do you think this would be a bug in the webdav client-lib API? Thanks, Krishna -Original Message- From: James Mason [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 12:34 AM To: Slide Users Mailing List Subject: Re: Adding a non-inheritable permission to a folder using webdav clie nt lib not working Krishna, As far as I know Slide always sets permissions on collections to inheritable. -James On Mon, 2004-10-25 at 16:49 -0400, Krishna Kankipati wrote: Hi, I have been trying for quiet some time to add a permission to a folder using webdav client-lib that does not inherit to the downstream folders. I have taken the code from client-lib that is shipped with slide and am using slide 2.1 B1. In my code I use the following fragment to create an ACE object and bind it to ACL. The code works perfectly if 4th parameter (isInherited) is set to false // Create new ACE object bIsInherited = false aceNew = new Ace(sPrincipal, bDenyPrivilege, false, bIsInherited, null); The code does not work if 4th parameter (isInherited) is set to true. I am assuming that you set the 4th parameter to true if you are trying to make the permission non-inheritable (not allow it to percolate to the downstream folders). With 4th parameter set to true, webdav client does not throw any error but does not add the permission. Later when I get the ACL for the resource I find that the ace has not been added. Please let me know if I am missing something ... or if it is possible at all to create a permission(ace) in a ACL which does not percolate to downstream folders using webdav client lib. I found that adding a inheritable(false) permission in domain.xml does the job as desired. I am wondering why it is not working from webdav client lib. Any help is appreciated !! /*** code fragment */ // Fetch ACL from slide for a folder AclProperty acl = webDavResource.aclfindMethod(sResourcePath); // Fetch the ACE's (access control entities) of the existing ACL Ace[] aces = acl.getAces(); // Create new ACE object none exists if (aces == null) aces = new Ace[0]; Ace[] oldAces = aces; // Create a new ace array (larger then the earlier ace array by 1) aces = new Ace[oldAces.length + 1]; // Copy the old array into the new array System.arraycopy(oldAces,0,aces,0,oldAces.length); // Create new ACE object bIsInherited = true aceNew = new Ace(sPrincipal, bDenyPrivilege, false, bIsInherited, null); // Copy the new ace into the new ace array aces[oldAces.length] = aceMatchingPrincipal; // Create a new privilege Privilege privilegeNew = new Privilege(qnPermission.getNamespaceURI(), qnPermission.getLocalName(), null); // Update the ace object with the new privilege settings aceNew.addPrivilege(privilegeNew); // Update repository with new acl for the resource bSuccess = webDavResource.aclMethod(sResourcePath, aces); Krishna (303) 274 3027 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Adding a non-inheritable permission to a folder using webdav clie nt lib not working
Michael, I did not get your sentence So this means that you may be unable to preserve the meaning of existing ACEs when adding a new one. Although it is true that you cannot add/remove/modify each ace individually, . adding a new ace will not alter the meaning of existing aces at all. Correct me if I mis-read you statement So, do you mean to say that slide ACL protocol offers no way to set non-inheritable permissions to collections using webdav client lib. What is the meaning of the member variable isInherited in Ace class, if it cannot be set to true. Do you mean to say that it has to be set to false all the time? What is the true meaning of this member variable, it is kind of confusing Krishna -Original Message- From: Michael Smith [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 1:10 AM To: Slide Users Mailing List Subject: Re: Adding a non-inheritable permission to a folder using webdav clie nt lib not working James Mason wrote: Krishna, As far as I know Slide always sets permissions on collections to inheritable. -James Right. The webdav ACL protocol has a strange asymmetry here: it can tell you whether a permission is inheritable or not, but it has no way to specify that (either way) when _setting_ an ACL (whether the ACEs set are inheritable or not is implementation defined). This is particularly troubling since you have to set all the ACEs at once, you can't just add/remove/modify one at a time. So this means that you may be unable to preserve the meaning of existing ACEs when adding a new one. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Adding a non-inheritable permission to a folder using webdav clie nt lib not working
Ingo, Why is Ace class exposing its isInherited member variable if cannot be set explicitly. It also has a mutator method called setIsInherited(). If value set to false, it works. If set to true it just doesn't do anything (does not throw error too). Seems like a bug. Also, using domain.xml you can create non-inheritable permissions. I have tried that and it works. All I am asking is if I can achieve the same using webdav client lib. Thanks, Krishna -Original Message- From: Ingo Brunberg [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 1:22 AM To: Slide Users Mailing List Subject: Re: Adding a non-inheritable permission to a folder using webdav clie nt lib not working You can't set a permission that is inherited. Inherited means the ACE is really inherited (believe me) from a parent resource. In fact you should filter the ACEs with the inherited flag set before calling the aclMethod(). Luckily the client library does this for you. Ingo Hi, I have been trying for quiet some time to add a permission to a folder using webdav client-lib that does not inherit to the downstream folders. I have taken the code from client-lib that is shipped with slide and am using slide 2.1 B1. In my code I use the following fragment to create an ACE object and bind it to ACL. The code works perfectly if 4th parameter (isInherited) is set to false // Create new ACE object bIsInherited = false aceNew = new Ace(sPrincipal, bDenyPrivilege, false, bIsInherited, null); The code does not work if 4th parameter (isInherited) is set to true. I am assuming that you set the 4th parameter to true if you are trying to make the permission non-inheritable (not allow it to percolate to the downstream folders). With 4th parameter set to true, webdav client does not throw any error but does not add the permission. Later when I get the ACL for the resource I find that the ace has not been added. Please let me know if I am missing something ... or if it is possible at all to create a permission(ace) in a ACL which does not percolate to downstream folders using webdav client lib. I found that adding a inheritable(false) permission in domain.xml does the job as desired. I am wondering why it is not working from webdav client lib. Any help is appreciated !! /*** code fragment */ // Fetch ACL from slide for a folder AclProperty acl = webDavResource.aclfindMethod(sResourcePath); // Fetch the ACE's (access control entities) of the existing ACL Ace[] aces = acl.getAces(); // Create new ACE object none exists if (aces == null) aces = new Ace[0]; Ace[] oldAces = aces; // Create a new ace array (larger then the earlier ace array by 1) aces = new Ace[oldAces.length + 1]; // Copy the old array into the new array System.arraycopy(oldAces,0,aces,0,oldAces.length); // Create new ACE object bIsInherited = true aceNew = new Ace(sPrincipal, bDenyPrivilege, false, bIsInherited, null); // Copy the new ace into the new ace array aces[oldAces.length] = aceMatchingPrincipal; // Create a new privilege Privilege privilegeNew = new Privilege(qnPermission.getNamespaceURI(), qnPermission.getLocalName(), null); // Update the ace object with the new privilege settings aceNew.addPrivilege(privilegeNew); // Update repository with new acl for the resource bSuccess = webDavResource.aclMethod(sResourcePath, aces); Krishna (303) 274 3027 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ACL Inheritance
Hi, Can anyone explain how the Slide ACL inheritance works? Can we switch on inheritance on any specific collection in the repository tree structure and expect all its children to have the permissions that are granted/denied to it. Let me give an example: Consider the structure below: root-- read for all - dir1 -- write for sales - dir 1.2 - dir2 - dir 2.2 Since read was assigned to all for root, how does slide know to inherit that ace to all children, is there a property where we ask slide to inherit a particular ace. Now lets say I want to assign write to sales on dir1 and want all its children to inherit that ACE, is it possible? If so, how do I do it. I know that every ACE has a property called isInherited, what does this property mean. Does it mean that this particular ace was inherited from its parent (or root folder) or does it mean that this ace will be inherited to all its children whenever children are created? Any help would be appreciated Krishna
Authorization without authentication with Slide2.1B1
Hi,
I just installed Slide2.1B1 and having problems with authorization
if I switch off the authentication. In Slide 2.1M1 it worked fine. After
switching off the authentication by deleting all security elements from
web.xml, I can let all users in through Tomcat. But the problem is that if
authentication is dis-abled, Slide2.1B1 is taking unauthenticated as the
principal. I am using webdav client to connect to Slide and I make sure that
I set username and password before connecting. Here is the code:
Note that I set the userinfo for HttpURL using the call:
httpURL.setUserinfo(sRootUser, sRootPwd);
Slide 2.1 M1 was taking this user as principal for authorization although
Tomcat did not authenticate this user. I was expecting similar behaviour
from Slide2.1B1. Is this a bug or has the functionality changed? Should I
create a BugZilla issue for this? Can anyone validate if this has been
noticed with Slide2.1B1?
We want to do custom authentication in web application, which invokes slide
from within it. We want to dis-able slide authentication completely,
although we want to use the rich authorization features. Is it possible to
do this without touching/extending code on the slide server? Any help would
be appreciated ...
/* Code to connect to slide using Webdav client, picked up from commandline
client code **/
private boolean connect(String sURI) throws IOException
{
if (!sURI.endsWith(/) !sURI.endsWith(\\))
{
// append / to the path
sURI+=/;
}
// Trace to terminal
write(connect + sURI + @ + sRootUser + / + sRootPwd);
try
{
// Set up for processing WebDAV resources
httpURL = uriToHttpURL(sURI);
// Set user and pwd for HttpURL
httpURL.setUserinfo(sRootUser, sRootPwd);
httpURL.setUser(root);
httpURL.setPassword(root);
if (webDavResource == null)
{
webDavResource = new WebdavResource(httpURL);
webDavResource.setDebug(getDebugLevel());
/* Why should I not allow connections to files
// is not a collection?
if
(!((ResourceTypeProperty)webDavResource.getResourceType()).isCollection())
{
webDavResource = null;
httpURL = null;
write(Error: + sURI + is not a collection! Use
open/connect only for collections!);
return false;
}
*/
}
else
{
webDavResource.close();
webDavResource.setHttpURL(httpURL);
}
}
catch (HttpException we)
{
write(HttpException.getReasonCode(): + we.getReasonCode());
httpURL = null;
if(webDavResource != null)
{
webDavResource.close();
webDavResource = null;
}
return false;
}
return true;
}
thanks,
Krishna
Krishna Kankipati
Software Engineer
SSA Global
* 1626 Cole Blvd. Golden, CO 80401, USA
* 303-274-3027
Fax:303-274-3137
* [EMAIL PROTECTED]
RE: User Authorization based on permissions set to role in Slide2 .1
Andrey , I will try that and see if it helps thanks, Krishna -Original Message- From: Andrey Shulinsky [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 04, 2004 6:13 PM To: 'Slide Users Mailing List' Subject: RE: User Authorization based on permissions set to role in Slide2 .1 Krishna, try to remove /Slide Here's how this property should look like in the xml descriptor (approximately): property name=group-member-set namespace=DAV: value=lt;D:href xmlns:D=quot;DAV:quot;gt;/users/user1lt;/D:hrefgt; type= protected=false permissions / /property ' symbol might not be replaced by quot; but the user's uri should start from /users. Yours sincerely, Andrey Shulinskiy. -Original Message- From: Slide Users Mailing List [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 04, 2004 7:54 PM To: [EMAIL PROTECTED] Subject: RE: User Authorization based on permissions set to role in Slide2 .1 Importance: Low James, Here is the output of the group-member-set property of the role user. Note the value has lot of empty and tab spaces /Slide/users/user1 Java code used to get this property value == == === String sPropertyName = group-member-set; Enumeration enumProperties = webDavResource.propfindMethod(sPropertyName); == == = Krishna -Original Message- From: James Mason [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 04, 2004 4:57 PM To: Slide Users Mailing List Subject: Re: User Authorization based on permissions set to role in Slide2 .1 Can you paste the contents of the group-member-set property of the user role? If you notice the root user doesn't have any explicit rights to the /files node, everything is inherited through the root role. My guess is your user isn't making it into the role properly. -James Krishna Kankipati wrote: Jason, I checked the acl for this folder, it looks like this: ACL for /Slide/files/folder1: granted to /Slide/roles/user(not protected) (not inherited) DAV:all DAV:write granted to property(not protected) (inherited from '/Slide/files') DAV:read-acl granted to /Slide/roles/root(not protected) (inherited from '/Slide/') DAV:all granted to all(not protected) (inherited from '/Slide/') DAV:read I added my user 'user1' to role called 'user' using group-member-set property (also checked it). Since the role 'user' has the permissions to write to folder 'folder1', as seen by the ACL output, and there seems to be no contradiction to any other ace's in the acl list, I expected my user 'user1' to have necessary permissions to upload a file to 'folder1'. But I get 403 forbidden error. I can login as root and using the same command can upload a file to 'folder1'. So, I am not sure whats wrong. Initially I thought may be the group-member-set is not set properly, so used DAVExplorer to do the same with no avail. Do you think I am missing something, how do I debug this situation? thanks, regards, Krishna -Original Message- From: James Mason [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 04, 2004 2:34 PM To: Slide Users Mailing List Subject: Re: User Authorization based on permissions set to role in Slide2.1 Krishna, Permissions on a role are inherited by the members of that role, yes. One thing to check is that your user isn't being denied write access but another ACL that's higher in the list. ACLs are checked in order and the first one that applies takes precedence. If user1 is in a role that has been denied the ability to write, and that ACE appears in the ACL before the permission that grants write access, user1 will not have write access. -James Krishna Kankipati wrote: Hi Folks, I am re-posting this mail since I haven't got any replies yet. I am hoping there is some developer there who might have tried to play around with permissions in Slide2.1M1. My problem is that when I assign some permissions to a role, those permissions are not propogated to the users in that role. If not for permissions what else is the purpose of having roles at all? I am sure it is not just for logical grouping of users. Any help is appreciated .. thanks in advance regards, Krishna -Original Message- From: Krishna Kankipati Sent: Tuesday, August 03, 2004 5:47 PM To:'[EMAIL PROTECTED
RE: User Authorization based on permissions set to role in Slide2 .1
Andrey, I ran a few tests using DAVExplorer0.9 to asssign users to role and check if the permissions are propogated, and looks like it works if I use the syntax for the group-member-set property value as you mentioned. Using CDATA section for the property value is highly mis-leading, since it seems like it works but does not let the permissions propogate (althoug the property is set right and you can also view the property right). So, using CDATA section for any XML property value is Slide is dangerous. Better use the XML escape tags like 'lt;' Now I will try to update my java code to use the xml escape tags instead of CDATA, I think it will work OK. Thanks for all the help, you really saved my day, you are my hero regards, Krishna -Original Message- From: Andrey Shulinsky [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 04, 2004 6:13 PM To: 'Slide Users Mailing List' Subject: RE: User Authorization based on permissions set to role in Slide2 .1 Krishna, try to remove /Slide Here's how this property should look like in the xml descriptor (approximately): property name=group-member-set namespace=DAV: value=lt;D:href xmlns:D=quot;DAV:quot;gt;/users/user1lt;/D:hrefgt; type= protected=false permissions / /property ' symbol might not be replaced by quot; but the user's uri should start from /users. Yours sincerely, Andrey Shulinskiy. -Original Message- From: Slide Users Mailing List [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 04, 2004 7:54 PM To: [EMAIL PROTECTED] Subject: RE: User Authorization based on permissions set to role in Slide2 .1 Importance: Low James, Here is the output of the group-member-set property of the role user. Note the value has lot of empty and tab spaces /Slide/users/user1 Java code used to get this property value == == === String sPropertyName = group-member-set; Enumeration enumProperties = webDavResource.propfindMethod(sPropertyName); == == = Krishna -Original Message- From: James Mason [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 04, 2004 4:57 PM To: Slide Users Mailing List Subject: Re: User Authorization based on permissions set to role in Slide2 .1 Can you paste the contents of the group-member-set property of the user role? If you notice the root user doesn't have any explicit rights to the /files node, everything is inherited through the root role. My guess is your user isn't making it into the role properly. -James Krishna Kankipati wrote: Jason, I checked the acl for this folder, it looks like this: ACL for /Slide/files/folder1: granted to /Slide/roles/user(not protected) (not inherited) DAV:all DAV:write granted to property(not protected) (inherited from '/Slide/files') DAV:read-acl granted to /Slide/roles/root(not protected) (inherited from '/Slide/') DAV:all granted to all(not protected) (inherited from '/Slide/') DAV:read I added my user 'user1' to role called 'user' using group-member-set property (also checked it). Since the role 'user' has the permissions to write to folder 'folder1', as seen by the ACL output, and there seems to be no contradiction to any other ace's in the acl list, I expected my user 'user1' to have necessary permissions to upload a file to 'folder1'. But I get 403 forbidden error. I can login as root and using the same command can upload a file to 'folder1'. So, I am not sure whats wrong. Initially I thought may be the group-member-set is not set properly, so used DAVExplorer to do the same with no avail. Do you think I am missing something, how do I debug this situation? thanks, regards, Krishna -Original Message- From: James Mason [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 04, 2004 2:34 PM To: Slide Users Mailing List Subject: Re: User Authorization based on permissions set to role in Slide2.1 Krishna, Permissions on a role are inherited by the members of that role, yes. One thing to check is that your user isn't being denied write access but another ACL that's higher in the list. ACLs are checked in order and the first one that applies takes precedence. If user1 is in a role that has been denied the ability to write, and that ACE appears in the ACL before the permission that grants write access, user1 will not have write access. -James Krishna Kankipati wrote: Hi Folks
User Authorization based on permissions set to role in Slide2.1
Hi Folks, I am re-posting this mail since I haven't got any replies yet. I am hoping there is some developer there who might have tried to play around with permissions in Slide2.1M1. My problem is that when I assign some permissions to a role, those permissions are not propogated to the users in that role. If not for permissions what else is the purpose of having roles at all? I am sure it is not just for logical grouping of users. Any help is appreciated .. thanks in advance regards, Krishna -Original Message- From: Krishna Kankipati Sent: Tuesday, August 03, 2004 5:47 PM To: '[EMAIL PROTECTED]'; [EMAIL PROTECTED] Subject: User Authorization based on permissions set to role in Slide2.1 Michael, I was searching the mail archive for some help on permissions and came upon this discussion you were having with some developer which seemed relevant to my question: http://www.mail-archive.com/[EMAIL PROTECTED]/msg05056.html Does slide permissions propogate based on role memberships. I mean, if I create a role called role1, and add a user called user1 to it, will user1 get all the permissions that are assigned to role1. I've seen in my tests that although I gave enough write permissions to role1, Slide does not allow user1 to write unless I add the write permission to user1 itself. Am I missing something or is it a bug. What is your opinion on this? I am using Slide 2.1M1 and command line client to grant permissions to /Slide/files collection. thanks regards, Krishna Krishna Kankipati Software Engineer SSA Global * 1626 Cole Blvd. Golden, CO 80401, USA * 303-274-3027 Fax:303-274-3137 * [EMAIL PROTECTED]
RE: User Authorization based on permissions set to role in Slide2 .1
Guido, I did check both that you mentioned. The auto-versioning was set to false in Domain.xml and when I check for property current-user-privilege-set for folder1, it returns 'Read'. Although acl for folder1 looks like this: Note that my user 'user1' was added to role 'user' by setting the group-member-set property for the role 'user'. ACL for /Slide/files/folder1: granted to /Slide/roles/user(not protected) (not inherited) DAV:all DAV:write granted to property(not protected) (inherited from '/Slide/files') DAV:read-acl granted to /Slide/roles/root(not protected) (inherited from '/Slide/') DAV:all granted to all(not protected) (inherited from '/Slide/') DAV:read So, looks like assigning the user 'user1' to role 'user' is not propogating the permissions of role 'user' to user 'user1' To make sure I also used DAVExplorer to edit the group-member-set property of the role 'user' to include user 'user1' ... didn't help. Any thoughts? thanks, regards, Krishna -Original Message- From: Guido Casper [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 04, 2004 2:25 PM To: Slide Users Mailing List Subject: Re: User Authorization based on permissions set to role in Slide2 .1 Krishna Kankipati wrote: Hi Andrey, Thanks for the response. As we speak I am doing some tests using the Slide Command Line tool (it uses Webdav Client internally). I added a new user (user1) and a new role (role1) using webdav client. I did this using mkcol command on users and roles collection. After that I use Webdav client (proppatchMethod()) to set the property group-member-set of role role1 to include user1 as member of this role. This seemed to work fine. Also, when I use propfindMethod() from webdav client to check the property value of group-member-set, it shows user1 as a member of role1. After that I use command line tool to login as root and assign write permission on a new folder I created under /files to /roles/role1. The command I use is: grant write on /Slide/files/folder1 to /Slide/roles/role1 If I check acl propery for /Slide/files/folder1, I can see that write permission is assigned to role1 for folder1. Now, when I login back as user1, I cannot upload a file to the above folder, I get 403 Forbidden error. A possible reason for 403s might be that you have auto-versioning set but inadequate permissions on the /history folder. You may also want to check the current-user-privilege-set property of folder1 to see if the write permission gets properly propagated from role to user. HTH Guido Can you validate that this works for you (I'll appreciate if you can grant permissions using command line tool and validate that the permission works properly). You can use acl command to find the permissions on any folder/file. thanks, regards, Krishna -Original Message- From: Andrey Shulinsky [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 04, 2004 12:56 PM To: 'Slide Users Mailing List' Subject: RE: User Authorization based on permissions set to role in Slide2.1 Hi, Krishna! Everything should work fine in the case you've described. Actually, I'm testing permissions at the moment and it's one of my own test cases. I am using the Security helper directly though, not the client. Haven't you checked the descriptors of the role1 and the file you're granting access to ensure that user1 is really in the group-member-set property of the role and that the permission is set in the file descriptor? Yours sincerely, Andrey. -Original Message- From: Slide Users Mailing List [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 04, 2004 11:50 AM To: '[EMAIL PROTECTED]' Subject: User Authorization based on permissions set to role in Slide2.1 Importance: Low Hi Folks, I am re-posting this mail since I haven't got any replies yet. I am hoping there is some developer there who might have tried to play around with permissions in Slide2.1M1. My problem is that when I assign some permissions to a role, those permissions are not propogated to the users in that role. If not for permissions what else is the purpose of having roles at all? I am sure it is not just for logical grouping of users. Any help is appreciated .. thanks in advance regards, Krishna -Original Message- From:Krishna Kankipati Sent:Tuesday, August 03, 2004 5:47 PM To: '[EMAIL PROTECTED]'; [EMAIL PROTECTED] Subject: User Authorization based on permissions set to role in Slide2.1 Michael, I was searching the mail archive for some help on permissions and came upon this discussion you were having with some developer which seemed relevant to my question: http://www.mail-archive.com/[EMAIL PROTECTED]/msg05056.htm l Does slide
RE: User Authorization based on permissions set to role in Slide2 .1
Jason, I checked the acl for this folder, it looks like this: ACL for /Slide/files/folder1: granted to /Slide/roles/user(not protected) (not inherited) DAV:all DAV:write granted to property(not protected) (inherited from '/Slide/files') DAV:read-acl granted to /Slide/roles/root(not protected) (inherited from '/Slide/') DAV:all granted to all(not protected) (inherited from '/Slide/') DAV:read I added my user 'user1' to role called 'user' using group-member-set property (also checked it). Since the role 'user' has the permissions to write to folder 'folder1', as seen by the ACL output, and there seems to be no contradiction to any other ace's in the acl list, I expected my user 'user1' to have necessary permissions to upload a file to 'folder1'. But I get 403 forbidden error. I can login as root and using the same command can upload a file to 'folder1'. So, I am not sure whats wrong. Initially I thought may be the group-member-set is not set properly, so used DAVExplorer to do the same with no avail. Do you think I am missing something, how do I debug this situation? thanks, regards, Krishna -Original Message- From: James Mason [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 04, 2004 2:34 PM To: Slide Users Mailing List Subject: Re: User Authorization based on permissions set to role in Slide2.1 Krishna, Permissions on a role are inherited by the members of that role, yes. One thing to check is that your user isn't being denied write access but another ACL that's higher in the list. ACLs are checked in order and the first one that applies takes precedence. If user1 is in a role that has been denied the ability to write, and that ACE appears in the ACL before the permission that grants write access, user1 will not have write access. -James Krishna Kankipati wrote: Hi Folks, I am re-posting this mail since I haven't got any replies yet. I am hoping there is some developer there who might have tried to play around with permissions in Slide2.1M1. My problem is that when I assign some permissions to a role, those permissions are not propogated to the users in that role. If not for permissions what else is the purpose of having roles at all? I am sure it is not just for logical grouping of users. Any help is appreciated .. thanks in advance regards, Krishna -Original Message- From: Krishna Kankipati Sent: Tuesday, August 03, 2004 5:47 PM To: '[EMAIL PROTECTED]'; [EMAIL PROTECTED] Subject: User Authorization based on permissions set to role in Slide2.1 Michael, I was searching the mail archive for some help on permissions and came upon this discussion you were having with some developer which seemed relevant to my question: http://www.mail-archive.com/[EMAIL PROTECTED]/msg05056.html Does slide permissions propogate based on role memberships. I mean, if I create a role called role1, and add a user called user1 to it, will user1 get all the permissions that are assigned to role1. I've seen in my tests that although I gave enough write permissions to role1, Slide does not allow user1 to write unless I add the write permission to user1 itself. Am I missing something or is it a bug. What is your opinion on this? I am using Slide 2.1M1 and command line client to grant permissions to /Slide/files collection. thanks regards, Krishna Krishna Kankipati Software Engineer SSA Global * 1626 Cole Blvd. Golden, CO 80401, USA * 303-274-3027 Fax:303-274-3137 * [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: User Authorization based on permissions set to role in Slide2 .1
James, Here is the output of the group-member-set property of the role user. Note the value has lot of empty and tab spaces /Slide/users/user1 Java code used to get this property value === String sPropertyName = group-member-set; Enumeration enumProperties = webDavResource.propfindMethod(sPropertyName); = Krishna -Original Message- From: James Mason [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 04, 2004 4:57 PM To: Slide Users Mailing List Subject: Re: User Authorization based on permissions set to role in Slide2 .1 Can you paste the contents of the group-member-set property of the user role? If you notice the root user doesn't have any explicit rights to the /files node, everything is inherited through the root role. My guess is your user isn't making it into the role properly. -James Krishna Kankipati wrote: Jason, I checked the acl for this folder, it looks like this: ACL for /Slide/files/folder1: granted to /Slide/roles/user(not protected) (not inherited) DAV:all DAV:write granted to property(not protected) (inherited from '/Slide/files') DAV:read-acl granted to /Slide/roles/root(not protected) (inherited from '/Slide/') DAV:all granted to all(not protected) (inherited from '/Slide/') DAV:read I added my user 'user1' to role called 'user' using group-member-set property (also checked it). Since the role 'user' has the permissions to write to folder 'folder1', as seen by the ACL output, and there seems to be no contradiction to any other ace's in the acl list, I expected my user 'user1' to have necessary permissions to upload a file to 'folder1'. But I get 403 forbidden error. I can login as root and using the same command can upload a file to 'folder1'. So, I am not sure whats wrong. Initially I thought may be the group-member-set is not set properly, so used DAVExplorer to do the same with no avail. Do you think I am missing something, how do I debug this situation? thanks, regards, Krishna -Original Message- From: James Mason [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 04, 2004 2:34 PM To: Slide Users Mailing List Subject: Re: User Authorization based on permissions set to role in Slide2.1 Krishna, Permissions on a role are inherited by the members of that role, yes. One thing to check is that your user isn't being denied write access but another ACL that's higher in the list. ACLs are checked in order and the first one that applies takes precedence. If user1 is in a role that has been denied the ability to write, and that ACE appears in the ACL before the permission that grants write access, user1 will not have write access. -James Krishna Kankipati wrote: Hi Folks, I am re-posting this mail since I haven't got any replies yet. I am hoping there is some developer there who might have tried to play around with permissions in Slide2.1M1. My problem is that when I assign some permissions to a role, those permissions are not propogated to the users in that role. If not for permissions what else is the purpose of having roles at all? I am sure it is not just for logical grouping of users. Any help is appreciated .. thanks in advance regards, Krishna -Original Message- From:Krishna Kankipati Sent:Tuesday, August 03, 2004 5:47 PM To: '[EMAIL PROTECTED]'; [EMAIL PROTECTED] Subject: User Authorization based on permissions set to role in Slide2.1 Michael, I was searching the mail archive for some help on permissions and came upon this discussion you were having with some developer which seemed relevant to my question: http://www.mail-archive.com/[EMAIL PROTECTED]/msg05056.html Does slide permissions propogate based on role memberships. I mean, if I create a role called role1, and add a user called user1 to it, will user1 get all the permissions that are assigned to role1. I've seen in my tests that although I gave enough write permissions to role1, Slide does not allow user1 to write unless I add the write permission to user1 itself. Am I missing something or is it a bug. What is your opinion on this? I am using Slide 2.1M1 and command line client to grant permissions to /Slide/files collection. thanks regards, Krishna Krishna Kankipati Software Engineer SSA Global * 1626 Cole Blvd. Golden, CO 80401, USA * 303-274-3027 Fax:303-274-3137 * [EMAIL PROTECTED] - To unsubscribe, e-mail
RE: User Authorization based on permissions set to role in Slide2 .1
Andrey, No, I haven't tried that, but I've tried giving all permission to the role, didn't work. If I give the write permission to the particular user it works. Kirshna -Original Message- From: Andrey Shulinsky [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 04, 2004 4:52 PM To: 'Slide Users Mailing List' Subject: RE: User Authorization based on permissions set to role in Slide2.1 One more thing - try to give your user read permission to the folder along with the write permission. Does it help? Yours sincerely, Andrey. -Original Message- From: Slide Users Mailing List [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 04, 2004 11:50 AM To: '[EMAIL PROTECTED]' Subject: User Authorization based on permissions set to role in Slide2.1 Importance: Low Hi Folks, I am re-posting this mail since I haven't got any replies yet. I am hoping there is some developer there who might have tried to play around with permissions in Slide2.1M1. My problem is that when I assign some permissions to a role, those permissions are not propogated to the users in that role. If not for permissions what else is the purpose of having roles at all? I am sure it is not just for logical grouping of users. Any help is appreciated .. thanks in advance regards, Krishna -Original Message- From: Krishna Kankipati Sent: Tuesday, August 03, 2004 5:47 PM To: '[EMAIL PROTECTED]'; [EMAIL PROTECTED] Subject:User Authorization based on permissions set to role in Slide2.1 Michael, I was searching the mail archive for some help on permissions and came upon this discussion you were having with some developer which seemed relevant to my question: http://www.mail-archive.com/[EMAIL PROTECTED]/msg05056.htm l Does slide permissions propogate based on role memberships. I mean, if I create a role called role1, and add a user called user1 to it, will user1 get all the permissions that are assigned to role1. I've seen in my tests that although I gave enough write permissions to role1, Slide does not allow user1 to write unless I add the write permission to user1 itself. Am I missing something or is it a bug. What is your opinion on this? I am using Slide 2.1M1 and command line client to grant permissions to /Slide/files collection. thanks regards, Krishna Krishna Kankipati Software Engineer SSA Global * 1626 Cole Blvd. Golden, CO 80401, USA * 303-274-3027 Fax:303-274-3137 * [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problem with proppatchMethod for property group-member-set
James,
Your trick # 1 worked. I had to use the same method that the
commandline client was using. Here is the method I used to make it work. I
could keep the CDATA element.
Code that worked:
PropertyName pName = new PropertyName(DAV:, group-member-set);
if(webDavResource.proppatchMethod(sRolePathURI, pName,
sbNewMemberSetProperty.toString(), true))
{
write(Prop patch worked);
bSuccess = true;
}
I appreciate your timely help .
thanks,
Krishna
-Original Message-
From: James Mason [mailto:[EMAIL PROTECTED]
Sent: Monday, August 02, 2004 10:13 PM
To: [EMAIL PROTECTED]
Subject: RE: Problem with proppatchMethod for property
group-member-set
Two things to try:
1) Look at the code the command line client uses to send proppatches to
the server. The client library supports multiple methods for most
operations, and whichever one the command line client uses seems to get
the most testing ::shrug::.
2) Try dropping the enclosing !CDATA[ ]]. I could be wrong, but I
don't think it's necessary, and it may be interfering.
Post back to list after you've looked at those two options. Maybe with
more data to go on someone who knows the client library well will be
able to give you a better answer.
-James
Krishna Kankipati [EMAIL PROTECTED] 08/02/04 3:54 PM
James,
I did not get any responses from anyone, i am assuming no one
has
tried this yet. What is your opinion, I did some debugging and found
that
Webdav Client is doing its job of sending data to servlet. I think Slide
Server is not handling the XML data for group-member-set property
properly.
Can you please let me know what you think about this issue .
thanks,
Krishna
-Original Message-
From: Krishna Kankipati [mailto:[EMAIL PROTECTED]
Sent: Monday, August 02, 2004 11:46 AM
To: [EMAIL PROTECTED]; '[EMAIL PROTECTED]'
Subject: Problem with proppatchMethod for property group-member-set
Hi,
I am writing a wrapper on top of WebDav Client 2.1 M1 (with
latest
CVS code for DOMUtils.java). I am having a problem executing
proppatchMethod() for the property group-member-set. I am trying to
assign
user john to role root. If I try the same through DAVExplorer 0.9,
it is
working fine. The group-member-set property value that my algorithm
generates before it calls proppatchMethod is:
The group-member-set property value that I am trying to set using
webdavResource.proppatchMethod
[CDATA[D:href xmlns:D='DAV:'/Slide/users/root/D:hrefD:href
xmlns:D='DAV:'/Slide/users/john/D:hrefD:href
xmlns:D='DAV:'/Slide/users/guest/D:href]]
I get the following error:
[CDATA[D:href xmlns:D='DAV:'/Slide/users/root/D:hrefD:href
xmlns:D='DAV:'/Slide/users/john/D:hrefD:href
xmlns:D='DAV:'/Slide/users/guest/D:href]]
Prop patch failed::Bad Request (400)
If I take this same string and add the property through DAVExplorer it
works
fine. So I am sure that the string that I am generating for the property
is
right. I guess there is a bug with the Slide2.1 M1 Webdav Client while
handling XML data.
Has anyone worked on this, any clues what could be wrong, or can anyone
validate that this is a bug with Webdav Client .
any help is appreciated ...
thanks and regards,
Krishna
PS: Source code for the method that assigns user to role
public boolean assignUserToRole(String sUserName, String
sRoleName)
throws IOException
{
// URI pointing to the given role
String sURI = BASE_URL + roles/ + sRoleName;
String sNewUserURI = /Slide/users/ + sUserName;
boolean bSuccess = false;
boolean bUserAlreadyBelongsToRole = false;
try
{
// Connect to Slide resource
if(connect(sURI))
{
write(Connected to slide
successfully);
// Try to set the group-member-set
property
as follows
/*
* proppatch /roles/role1
* group-member-set =
[CDATA[D:href
xmlns:D='DAV:'/users/user1/D:hrefD:href
xmlns:D='DAV:'/users/user2/D:href
User Authorization based on permissions set to role in Slide2.1
Michael, I was searching the mail archive for some help on permissions and came upon this discussion you were having with some developer which seemed relevant to my question: http://www.mail-archive.com/[EMAIL PROTECTED]/msg05056.html Does slide permissions propogate based on role memberships. I mean, if I create a role called role1, and add a user called user1 to it, will user1 get all the permissions that are assigned to role1. I've seen in my tests that although I gave enough write permissions to role1, Slide does not allow user1 to write unless I add the write permission to user1 itself. Am I missing something or is it a bug. What is your opinion on this? I am using Slide 2.1M1 and command line client to grant permissions to /Slide/files collection. thanks regards, Krishna Krishna Kankipati Software Engineer SSA Global * 1626 Cole Blvd. Golden, CO 80401, USA * 303-274-3027 Fax:303-274-3137 * [EMAIL PROTECTED]
Problem with proppatchMethod for property group-member-set
:');
sbNewMemberSetProperty.append(sUserInRoleURI);
sbNewMemberSetProperty.append(/D:href);
}
} // end for() loop
// Add the href element with new user URI
(this is where new user gets assigned to the role)
if(bUserAlreadyBelongsToRole == false)
{
sbNewMemberSetProperty.append(D:href xmlns:D='DAV:');
sbNewMemberSetProperty.append(sNewUserURI);
sbNewMemberSetProperty.append(/D:href);
}
// Append the CDATA closing brackets
sbNewMemberSetProperty.append(]]);
write(sbNewMemberSetProperty.toString());
// Now that the xml property string is
build, it has to be set as new property for the given webresource
Hashtable htProperties = new Hashtable();
htProperties.put(group-member-set,
sbNewMemberSetProperty.toString());
// String sProperty = lt;D:href
xmlns:D='DAV:'gt;/users/kkankipalt;/D:hrefgt;;
// htProperties.put(group-member-set,
sProperty);
// Set the new property value for the
resource property if the user is not already
// member of the role
if(bUserAlreadyBelongsToRole == false)
{
if(webDavResource.proppatchMethod(htProperties, true))
{
write(Prop patch worked);
bSuccess = true;
}
else
{
String sStatus =
webDavResource.getStatusMessage();
write(Prop patch failed::
+ sStatus);
bSuccess = false;
}
}
}
else
{
throw new IOException(Connection to Slide
failed);
}
}
catch(IOException ex)
{
write(ex.getMessage());
throw ex;
}
finally
{
disconnect();
}
return bSuccess;
}
end PS:
-Original Message-
From: James Mason [mailto:[EMAIL PROTECTED]
Sent: Friday, July 30, 2004 2:55 PM
To: [EMAIL PROTECTED]
Subject: RE: Problem with propFind for property group-member-set
Good :).
Krishna Kankipati [EMAIL PROTECTED] 7/30/2004 1:51:33 PM
James,
It works .
Krishna
-Original Message-
From: James Mason [mailto:[EMAIL PROTECTED]
Sent: Friday, July 30, 2004 2:19 PM
To: [EMAIL PROTECTED]
Subject: RE: Problem with propFind for property group-member-set
Let me know how it goes.
-James
Krishna Kankipati [EMAIL PROTECTED] 7/30/2004 1:15:56 PM
James,
Please ignore my e-mail, I looked at the CVS web site and it
was
pretty clear how to download the latest and greatest source code, I
will try
with the latest code and get back to you thanks a bunch!
Krishna
-Original Message-
From: James Mason [mailto:[EMAIL PROTECTED]
Sent: Friday, July 30, 2004 2:02 PM
To: [EMAIL PROTECTED]
Subject: Re: Problem with propFind for property group-member-set
You'll need to get it from CVS or wait until August 10 for the next
beta
release. The actual change was made to the DOMUtils class in
org.apache.util.
-James
Krishna Kankipati [EMAIL PROTECTED] 7/30/2004 12:59:31 PM
Hi James,
I am writing a wrapper on top of webdav client for our
application.
I am using Slide2.1M1. I found that the propfindMethod call on
property
group-member-set is always returning blank string. In the archived
discussion you had with Oliver
(http://www.mail-archive.com/[EMAIL PROTECTED]/msg06713.html),
you were saying that you fixed this and that you had a patch that
solves
this problem, where can I find the patch?
Code
String sPropertyName = group-member
RE: Anyone running Slide 2.0 on Websphere 5.0 platform
Hi Mihir, I have been struggling for a week to get Slide2.0 working on Websphere5.0 without much success. Looks like most of the folks out there are running Slide on Tomcat, so not getting much help either, did not find any documents for this on Slide website. Here are the steps to get it up and running to the extent that I could. 1) Download the released source code zip (2.0.1) from jakarta.apache.org 2) Download the following jar files (For your convenience I've copied them to vss_keystone\eDoc\References\lib) jdom.jar log4j.jar jta.jar jmxri.jar commons-collections-2.1.jar commons-dbcp-1.2.1.jar commons-httpclient-2.0.jar commons-pool-1.2.jar 3) Add the following projects to Eclipse/Websphere Slide-Util (Point to src/Util) Slide-Share (Point to src/Share) [Depends on Slide-Util] Slide-Stores (Point to src/Stores) [Depends on Slide-Util, Slide-Share] Slide-Wrappers (Point to src/Wrappers) [Depends on Slide-Share] Slide-WebDav-Server (Point to src/webdav/server) [Depends on Slide-Util, Slide-Share] 5) Add the external jars from step no.2 to resolve the compilation errors 6) Copy the web.xml, Domain.xml,tomcat-users.xml and properties files from src/conf/webapps to WEB-INF 7) Remove the authentication and security elements/generic tags from web.xml (specific help here is found in Slide website section for authentication and authorization). 8. Run the servlet on websphere server. Hope this works for you. I could get to a point where I can view folders, cannot create any files, getting 403 Forbidden error. Let me know if you make any progress or find any useful information about authorization for slide or how to deal with authentication for Slide in websphere. regards, Krishna -Original Message- From: Mihir Solanki [mailto:[EMAIL PROTECTED] Sent: Thursday, July 22, 2004 10:05 PM To: 'Slide Users Mailing List' Subject: RE: Anyone running Slide 2.0 on Websphere 5.0 platform Hi Krishna, I would also want to run the slide 2.0 on Websphere platform (5.0 version). If you have done it, then could you please provide me steps for the configuration. Or if possible could you please tell me the reference site for the same. This will be the great help for me if you provide such kind of information... Thanks in advance... Regards, Mihir -Original Message- From: Krishna Kankipati [mailto:[EMAIL PROTECTED] Sent: Thursday, July 22, 2004 4:43 AM To: '[EMAIL PROTECTED]' Subject: Anyone running Slide 2.0 on Websphere 5.0 platform Hi, I am trying to run Slide on WebSphere Platform 5.0 [BASE 5.0.2 ptf2M0325.01] After a lot of effort I could get the Slide servlet to run successfully and show output on Websphere browser output when pointed to the webdav servlet. I had to configure slide.properties to dis-able security by setting org.apache.slide.security=false. I also had to remove all the security-constraint and login-config elements in web.xml as mentioned in Slide documentation to dis-able authentication. When pointing IE browser to the servlet I get a output showing 7 folders (users/, roles/, actions/, files/, history/, workspace/, workingresource/). I installed DAV Explorer 0.9 and pointed it to webdav. I get following error on the server and DAV Explorer displays HTTP:500 Internal Error Encountered message: /* [7/21/04 16:35:06:530 MDT] 15e32762 SystemOut O 21 Jul 2004 16:35:06 - org.apache.slide.webdav.WebdavServlet - ERROR - java.lang.VerifyError: (class: org/apache/slide/webdav/util/PropertyHelper, method: createActiveLockElement signature: (Lorg/apache/slide/lock/NodeLock;Ljava/lang/String;Ljava/lang/String;)Lo rg/j dom/Element;) Incompatible argument to method [7/21/04 16:35:06:530 MDT] 15e32762 SystemErr R java.lang.VerifyError: (class: org/apache/slide/webdav/util/PropertyHelper, method: createActiveLockElement signature: (Lorg/apache/slide/lock/NodeLock;Ljava/lang/String;Ljava/lang/String;)Lo rg/j dom/Element;) Incompatible argument to method [7/21/04 16:35:06:560 MDT] 15e32762 SystemErr R at org.apache.slide.webdav.util.VersioningHelper.init(VersioningHelper.ja va:1 55) [7/21/04 16:35:06:560 MDT] 15e32762 SystemErr R at org.apache.slide.webdav.util.VersioningHelper.getVersioningHelper(Versio ning Helper.java:113) [7/21/04 16:35:06:560 MDT] 15e32762 SystemErr R at org.apache.slide.webdav.method.PropFindMethod.parseRequest(PropFindMetho d.ja va:168) [7/21/04 16:35:06:560 MDT] 15e32762 SystemErr R at org.apache.slide.webdav.method.AbstractWebdavMethod.run(AbstractWebdavMe thod .java:312) [7/21/04 16:35:06:560 MDT] 15e32762 SystemErr R at org.apache.slide.webdav.WebdavServlet.service(WebdavServlet.java:165) [7/21/04 16:35:06:560 MDT] 15e32762 SystemErr R at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) [7/21/04 16:35:06:570 MDT] 15e32762 SystemErr R
RE: Anyone running Slide 2.0 on Websphere 5.0 platform
Kiran, Your suggestion helped, thanks a bunch, the problem was that Websphere was using a different version of jdom.jar from its lib folder at runtime. I renamed that file (sitting in Websphere library folder) and now I assumed its picking the jdom-b9.jar from WEB-INF/lib folder and things seems to be working. I still need to figure out how to set set CLASSLOADER sequence of jar files if multiple versions exist in websphere. I could not find a way to tweak CLASSPATH for Websphere web project at runtime. When I try to write a file to webdav using Webdav explorer, I get following error message: [7/22/04 10:22:57:489 MDT] 504ee369 SystemOut O Servlet.Engine.Transports : 1, 22-Jul-2004 10:22:57, , PUT, 403 Forbidden, 30 ms, / I have dis-abled security in slide.properties and removed all the security elements from web.xml, do you think thats the reason why it does not allow me to PUT files? kind regards, Krishna -Original Message- From: Kiran Patchigolla [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 21, 2004 5:20 PM To: 'Slide Users Mailing List' Subject: RE: Anyone running Slide 2.0 on Websphere 5.0 platform This is because of jdom.jar version mismatch. Websphere is probably picking up a jdom.jar from the libraries that it packages. Slide 2.0 needs the jdom-b9.jar that is packaged with it. To get around this problem you would have to force websphere to use the jdom-b9.jar for your web application. Its relatively easy to do this with other application servers (place the jdom-b9.jar in the web-inf/lib). I am not sure exactly how you would do this in websphere (I think you have to play with order of classloaders etc). Hopefully this info will get you started... Kiran. -Original Message- From: Krishna Kankipati [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 21, 2004 4:13 PM To: '[EMAIL PROTECTED]' Subject: Anyone running Slide 2.0 on Websphere 5.0 platform Hi, I am trying to run Slide on WebSphere Platform 5.0 [BASE 5.0.2 ptf2M0325.01] After a lot of effort I could get the Slide servlet to run successfully and show output on Websphere browser output when pointed to the webdav servlet. I had to configure slide.properties to dis-able security by setting org.apache.slide.security=false. I also had to remove all the security-constraint and login-config elements in web.xml as mentioned in Slide documentation to dis-able authentication. When pointing IE browser to the servlet I get a output showing 7 folders (users/, roles/, actions/, files/, history/, workspace/, workingresource/). I installed DAV Explorer 0.9 and pointed it to webdav. I get following error on the server and DAV Explorer displays HTTP:500 Internal Error Encountered message: /* [7/21/04 16:35:06:530 MDT] 15e32762 SystemOut O 21 Jul 2004 16:35:06 - org.apache.slide.webdav.WebdavServlet - ERROR - java.lang.VerifyError: (class: org/apache/slide/webdav/util/PropertyHelper, method: createActiveLockElement signature: (Lorg/apache/slide/lock/NodeLock;Ljava/lang/String;Ljava/lang/String;)Lorg/j dom/Element;) Incompatible argument to method [7/21/04 16:35:06:530 MDT] 15e32762 SystemErr R java.lang.VerifyError: (class: org/apache/slide/webdav/util/PropertyHelper, method: createActiveLockElement signature: (Lorg/apache/slide/lock/NodeLock;Ljava/lang/String;Ljava/lang/String;)Lorg/j dom/Element;) Incompatible argument to method [7/21/04 16:35:06:560 MDT] 15e32762 SystemErr R at org.apache.slide.webdav.util.VersioningHelper.init(VersioningHelper.java:1 55) [7/21/04 16:35:06:560 MDT] 15e32762 SystemErr R at org.apache.slide.webdav.util.VersioningHelper.getVersioningHelper(Versioning Helper.java:113) [7/21/04 16:35:06:560 MDT] 15e32762 SystemErr R at org.apache.slide.webdav.method.PropFindMethod.parseRequest(PropFindMethod.ja va:168) [7/21/04 16:35:06:560 MDT] 15e32762 SystemErr R at org.apache.slide.webdav.method.AbstractWebdavMethod.run(AbstractWebdavMethod .java:312) [7/21/04 16:35:06:560 MDT] 15e32762 SystemErr R at org.apache.slide.webdav.WebdavServlet.service(WebdavServlet.java:165) [7/21/04 16:35:06:560 MDT] 15e32762 SystemErr R at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) [7/21/04 16:35:06:570 MDT] 15e32762 SystemErr R at com.ibm.ws.webcontainer.servlet.StrictServletInstance.doService(StrictServle tInstance.java:110) [7/21/04 16:35:06:570 MDT] 15e32762 SystemErr R at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet._service(StrictLifecy cleServlet.java:174) [7/21/04 16:35:06:570 MDT] 15e32762 SystemErr R at com.ibm.ws.webcontainer.servlet.IdleServletState.service(StrictLifecycleServ let.java:313) [7/21/04 16:35:06:570 MDT] 15e32762 SystemErr R at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet.service(StrictLifecyc leServlet.java:116) [7/21/04 16:35:06:570 MDT] 15e32762 SystemErr R
403 Forbidden Error when uploading a file using DAV Exploere
Hi, I have Slide2.0 installed on Websphere 5.0 App server. In the present environment I have disabled authentication and authorization as mentioned in the Slide docs as follows: To dis-able authentication: (from Slide doc) To disable authentication, open the webapp deployment descriptor, i.e. WEB-INF/web.xml in the webapp directory, and uncomment the two elements given by the xpath expressions /web-app/security-constraint and /web-app/login-config: To dis-able authorization: (from Slide doc) To disable access control, search for a configuration file named slide.properties in the classpath (if not there, you can create a new one at e.g. $CATALINA_HOME/common/classes) and set or add: org.apache.slide.security=false When I try to upload a file using DAV Explorer or create a collection under /files context, I get the following error: [7/22/04 17:24:42:346 MDT] 7926d6a8 SystemOut O Servlet.Engine.Transports : 1, 22-Jul-2004 17:24:41, , PUT, 403 Forbidden, 391 ms, / I have tried all configuration settings, nothing seems to work, I have been stuck with this for past few days. Can any Slide experts among you help me get out this situation. I also tried using DAV Client command tool to run a few commands. When I run the command cd files, I get an error: Warning: Not found the path C:\JavaApps\WebdavClient\jakarta-slide-webdavclient-bin-2.0\binrun.bat [ Slide ] $ open http://localhost:9080/webdav-server/ connect http://localhost:9080/webdav-server/ [LOCALHOST] /webdav-server/ $ pwd /webdav-server/ [LOCALHOST] /webdav-server/ $ cd files Warning: Not found the path Any help here is highly appreciated, thanks in advance kind regards, Krishna Krishna Kankipati Software Engineer SSA Global * 1626 Cole Blvd. Golden, CO 80401, USA * 303-274-3027 Fax:303-274-3137 * [EMAIL PROTECTED]
