Re: web.xml's JSP interception
Paul, Miguel, I'm quite sure this is the way to go if you only want to expose /files over webdav. I've been playing around with this for some time now, and haven't run into troubles for that matter. What I don't know is howto set ACL when only exposing /files over webdav. rgrds, Waling On 12-12-2006 22:17, Miguel Figueiredo [EMAIL PROTECTED] wrote: Hello Paul, The usual configuration for /users path means that it's where slide does its user lookup. If /users does not exist, slide might not work at all, if it's empty, we won't be able to identify any single user. Anyway since you had success with the web.xml parameter configuration, I can only speculate that although only /files is publish, internally slide does know where to find the needed /users path (if it is the case, that's news for me). Best Regards, Miguel Figueiredo -Original Message- From: Paul Hammant [mailto:[EMAIL PROTECTED] Sent: terça-feira, 12 de Dezembro de 2006 19:14 To: Slide Users Mailing List Subject: Re: web.xml's JSP interception The web.xml change works nicely - thanks. The purpose of /users is so that they can be edited over DAV (for those on suitable ACLs) ? - Paul On Dec 12, 2006, at 6:42 AM, Miguel Figueiredo wrote: Hello Paul, Waling, Many thanks for your feedback! I'll keep tuned for more of it :) Regarding paths, Waling suggestion rings true to me. I'll give a word of warning though, if the users, roles, or other paths are not well defined, slide features will stop to work, or worse, slide will stop altogether. For example, if you don¹t have the users path defined, it won't be possible to define ACLs to any user. Never tried to use that web.xml configuration parameter, so I don't know how it will behave if you configure it to serve the /files path (will ACL feature still work? If yes, how do we identify a user in a, for example, ACL command?). Many thanks, Miguel -Original Message- From: Waling Dijkstra [mailto:[EMAIL PROTECTED] Sent: terça-feira, 12 de Dezembro de 2006 12:00 To: Slide Users Mailing List Subject: Re: web.xml's JSP interception Paul, you might consider setting param-namescope/param-name to param-value/files/param-value in web.xml. This will disable access to /users etc.. over webdav though. (unless I've overlooked something) (anyone?) rgrds, Waling On 12-12-2006 06:11, Paul Hammant [EMAIL PROTECTED] wrote: Miguel, Yes you're right, this is Sitemesh and Slide merged into one web app. We'll tell more another day! - perhaps when we've done something interesting with the concepts. In this case the JSP is the Sitemesh decorator (not under slide control) and it works sweetly you'll be pleased to know. We wonder if it is possible to remap the directories for slide. For example, i wish I could have Slide serve files-under-dav control from / rather than /files. With exceptions for other directories like /decorators. We have tried to change Domain.xml and change the relevant section, but it does not seem to change the preferred location - /files. We kinda want to hide the other directories / users /groups etc and only concentrate on files under DAV control. To get Slide to kinda work like mod_dav does :) Thoughts? - Paul On Dec 11, 2006, at 8:16 AM, Miguel Figueiredo wrote: Hello Hammant, If you remove the configuration fragment, the web server will handle de JSP file before Slide do. That means, it will compile the JSP, and serve you it's compiled contents (witch probably might present you with an internal server error page). Since you're asking that question, seems to me that you are trying to deploy a web application inside slide namespace. Although it is interesting, don't know if it brings more problems that anyone can handle. I don't know Sitemesh, but is it true? You're trying to deploy a web app inside slide namespace? If yes, I would be very interested to know any problems you might encounter. Best regards, Miguel Figueiredo - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
User management / Ghosts
Hello, After reading the documentation relative to user management, I tried to modifiy existing users declared in my Domain.xml and there is a strange behavior that I don't understand : Context : I use JAAS to authenticate a user declared in slide (this works nice) I've renamed the user root/root to admin/admin in the Domain.xml Scenario : I open a connexion using root/root, the connexion succeed ! I open a connexion using admin/admin, the connexion succeed but I got limited rights My question is : why does the user root still exists and work ? Are these informations stored in the associated Store or somewhere else ? Thanks for your help Ektor
Re: User management / Ghosts
Ektor Ektor wrote: Hello, After reading the documentation relative to user management, I tried to modifiy existing users declared in my Domain.xml and there is a strange behavior that I don't understand : Context : I use JAAS to authenticate a user declared in slide (this works nice) I've renamed the user root/root to admin/admin in the Domain.xml Scenario : I open a connexion using root/root, the connexion succeed ! I open a connexion using admin/admin, the connexion succeed but I got limited rights My question is : why does the user root still exists and work ? Are these informations stored in the associated Store or somewhere else ? Thanks for your help Ektor When you launch Slide the users get written into the store(s). Look for a /users/root directory. If you delete it the root user should be gone, but that won't help you with the admin user's permissions, so you might end up locking yourself out that way. If this is just a test setup without any valuable data stored in it, you might want to simply delete the entire store. That way Slide would re-initialize it on next start, creating a new empty store from your Domain.xml (ie without the root user). Obviously you shouldn't do that if there's anything in the store you want to keep. Cheers, Edmund - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: User management / Ghosts
Thanks a lot. I took a look in the database and things are clearer for me now ! I also understand why there is so many messages like INFO - Loading object /history INFO - Object already exists at /history ... At each starts slide parse Domain.xl and create what doesn't exists in database. 2006/12/13, Edmund Urbani [EMAIL PROTECTED]: Ektor Ektor wrote: Hello, After reading the documentation relative to user management, I tried to modifiy existing users declared in my Domain.xml and there is a strange behavior that I don't understand : Context : I use JAAS to authenticate a user declared in slide (this works nice) I've renamed the user root/root to admin/admin in the Domain.xml Scenario : I open a connexion using root/root, the connexion succeed ! I open a connexion using admin/admin, the connexion succeed but I got limited rights My question is : why does the user root still exists and work ? Are these informations stored in the associated Store or somewhere else ? Thanks for your help Ektor When you launch Slide the users get written into the store(s). Look for a /users/root directory. If you delete it the root user should be gone, but that won't help you with the admin user's permissions, so you might end up locking yourself out that way. If this is just a test setup without any valuable data stored in it, you might want to simply delete the entire store. That way Slide would re-initialize it on next start, creating a new empty store from your Domain.xml (ie without the root user). Obviously you shouldn't do that if there's anything in the store you want to keep. Cheers, Edmund - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
PUT to a Microsoft Sharepoint working with Slide
Well since I've seen others with similar issues I thought I'd share how
I managed to get it working - it does take a modification to both the
slide and the httpclient libraries. Please Note I've done my work with
HTTPClient 3.01 and Slide 2.1 (I've also done the same work with the
trunks of both projects and the result is the same)
Problem: Need to upload files to Microsoft Sharepoint with NTLM
authentication. NTLM authentication will cause an exception about
unbuffered enclosing entity can't be resent or retried (I'm sorry I no
longer get the message so I can't paste it in). Contrary to other
messages if the server is Microsoft and the client is java turning off
expect-continue does not fix the problem. The problem stems from the
fact that the Put Method on http client is setting the size of the
content when it creates an InputStreamRequestEntity. This causes the
entity to not buffer itself (Why you would want this I don't know since
it only buffers 4k at a time). I haven't tried large files yet so
there may still be additional work that has to be done to get this to
work out correctly if the file is large. Anyhow the buffering is
important simply because when you try to put a file to an NTLM
authenticated resource the first attempt will fail with a not
authorized. This will cause a challenge response handshake and then a
retry happens. The problem is with an unbuffered input stream the
retry does not occur because the enclosing entity claims its not
repeatable. Failure every time.
My solution which is not necessarily elegant but may help some desperate
developer out there consists of the following changes:
1: In the jakarta.commons.httpclient project modify:
org.apache.commons.httpclient.methods.InputStreamRequestEntity
When contentlength is declared set it equal to
CONTENT_LENGTH_AUTO // This change is probably not absolutely required
but its what I did.
org.apache.commons.httpclient.methods.EntityEnclosingMethod
Modify method generateRequestEntity - change the new for
new InputStreamRequestEntity to use the single arge constructor as in
new InputStreamRequestEntity(is)// By not passing the size it
stays in CONTENT_LENGTH_AUTO mode which permits buffering.
2: In the Slide webdavclient project modify
org.apache.webdav.lib.WebdavResource
In the put(String,InputStream) method remove the content length
chunked set command.
Sample code that now works:
public static void main(String[] args){
try {
File file = new File(src);
if (file.exists()) {
System.out.println(Uploading ' + file.getCanonicalPath()
+ ' to ' + dest + ' );
uploadWebDav(file);
} catch (Exception e) {
System.out.println(e.getMessage());
}
private static void uploadWebDav(File file) {
WebdavResource webdavResource = null;
try {
NTCredentials creds2 = new NTCredentials(myusername, mypassword,
myclientpc, NTDOMAIN);
webdavResource = new WebdavResource(
http://SHAREPOINTSERVER/Shared Documents, creds2);
String[] list = webdavResource.list();
for (String s :list){
System.out.println(s);
}
System.out.println(Uploading);
// Note - use the putmethod where specify a destination path and that
you include the desired filename
if (webdavResource.putMethod(http://SHAREPOINTSERVER/Shared
Documents/cofs9.zip , new FileInputStream(file))) {
System.out.println(succeeded.);
}
} catch (Exception e1) {
System.out.println(e1.getMessage());
}
}
RE: PUT to a Microsoft Sharepoint working with Slide
Hey Chandler,
Many thanks for this important piece of the information!
I'm sure it can be used in many other situations related with NTLM
authentication.
Best regards,
Miguel Figueiredo
-Original Message-
From: Andy Chandler [mailto:[EMAIL PROTECTED]
Sent: quarta-feira, 13 de Dezembro de 2006 17:53
To: slide-user@jakarta.apache.org
Subject: PUT to a Microsoft Sharepoint working with Slide
Well since I've seen others with similar issues I thought I'd share how
I managed to get it working - it does take a modification to both the
slide and the httpclient libraries. Please Note I've done my work with
HTTPClient 3.01 and Slide 2.1 (I've also done the same work with the
trunks of both projects and the result is the same)
Problem: Need to upload files to Microsoft Sharepoint with NTLM
authentication. NTLM authentication will cause an exception about
unbuffered enclosing entity can't be resent or retried (I'm sorry I no
longer get the message so I can't paste it in). Contrary to other
messages if the server is Microsoft and the client is java turning off
expect-continue does not fix the problem. The problem stems from the
fact that the Put Method on http client is setting the size of the
content when it creates an InputStreamRequestEntity. This causes the
entity to not buffer itself (Why you would want this I don't know since
it only buffers 4k at a time). I haven't tried large files yet so
there may still be additional work that has to be done to get this to
work out correctly if the file is large. Anyhow the buffering is
important simply because when you try to put a file to an NTLM
authenticated resource the first attempt will fail with a not
authorized. This will cause a challenge response handshake and then a
retry happens. The problem is with an unbuffered input stream the
retry does not occur because the enclosing entity claims its not
repeatable. Failure every time.
My solution which is not necessarily elegant but may help some desperate
developer out there consists of the following changes:
1: In the jakarta.commons.httpclient project modify:
org.apache.commons.httpclient.methods.InputStreamRequestEntity
When contentlength is declared set it equal to
CONTENT_LENGTH_AUTO // This change is probably not absolutely required
but its what I did.
org.apache.commons.httpclient.methods.EntityEnclosingMethod
Modify method generateRequestEntity - change the new for
new InputStreamRequestEntity to use the single arge constructor as in
new InputStreamRequestEntity(is)// By not passing the size it
stays in CONTENT_LENGTH_AUTO mode which permits buffering.
2: In the Slide webdavclient project modify
org.apache.webdav.lib.WebdavResource
In the put(String,InputStream) method remove the content length
chunked set command.
Sample code that now works:
public static void main(String[] args){
try {
File file = new File(src);
if (file.exists()) {
System.out.println(Uploading ' + file.getCanonicalPath()
+ ' to ' + dest + ' );
uploadWebDav(file);
} catch (Exception e) {
System.out.println(e.getMessage());
}
private static void uploadWebDav(File file) {
WebdavResource webdavResource = null;
try {
NTCredentials creds2 = new NTCredentials(myusername, mypassword,
myclientpc, NTDOMAIN);
webdavResource = new WebdavResource(
http://SHAREPOINTSERVER/Shared Documents, creds2);
String[] list = webdavResource.list();
for (String s :list){
System.out.println(s);
}
System.out.println(Uploading);
// Note - use the putmethod where specify a destination path and that
you include the desired filename
if (webdavResource.putMethod(http://SHAREPOINTSERVER/Shared
Documents/cofs9.zip , new FileInputStream(file))) {
System.out.println(succeeded.);
}
} catch (Exception e1) {
System.out.println(e1.getMessage());
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: PUT to a Microsoft Sharepoint working with Slide
I actually have an improvement - you no longer have to modify the
httpclient library at all. Simply a 1 line change to the
webdavresource method does the trick! I can't figure out why httpclient
doesn't handle chunked code better but since auto seems to chunk if
needed it seems a harmless change and makes sharepoint much happier.
Change this method
public boolean putMethod(String path, InputStream is)
throws HttpException, IOException {
setClient();
PutMethod method = new PutMethod(URIUtil.encodePathQuery(path));
generateIfHeader(method);
if (getGetContentType() != null
!getGetContentType().equals())
method.setRequestHeader(Content-Type,
getGetContentType());
method.setRequestContentLength(method.CONTENT_LENGTH_CHUNKED);
method.setRequestBody(is);
generateTransactionHeader(method);
int statusCode = client.executeMethod(method);
setStatusCode(statusCode);
return (statusCode = 200 statusCode 300) ? true : false;
}
To:
public boolean putMethod(String path, InputStream is)
throws HttpException, IOException {
setClient();
PutMethod method = new PutMethod(URIUtil.encodePathQuery(path));
generateIfHeader(method);
if (getGetContentType() != null
!getGetContentType().equals())
method.setRequestHeader(Content-Type,
getGetContentType());
method.setRequestContentLength(method.CONTENT_LENGTH_AUTO);
method.setRequestBody(is);
generateTransactionHeader(method);
int statusCode = client.executeMethod(method);
setStatusCode(statusCode);
return (statusCode = 200 statusCode 300) ? true : false;
}
-Original Message-
From: Miguel Figueiredo [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 13, 2006 12:24 PM
To: 'Slide Users Mailing List'
Subject: RE: PUT to a Microsoft Sharepoint working with Slide
Hey Chandler,
Many thanks for this important piece of the information!
I'm sure it can be used in many other situations related with NTLM
authentication.
Best regards,
Miguel Figueiredo
-Original Message-
From: Andy Chandler [mailto:[EMAIL PROTECTED]
Sent: quarta-feira, 13 de Dezembro de 2006 17:53
To: slide-user@jakarta.apache.org
Subject: PUT to a Microsoft Sharepoint working with Slide
Well since I've seen others with similar issues I thought I'd share how
I managed to get it working - it does take a modification to both the
slide and the httpclient libraries. Please Note I've done my work with
HTTPClient 3.01 and Slide 2.1 (I've also done the same work with the
trunks of both projects and the result is the same)
Problem: Need to upload files to Microsoft Sharepoint with NTLM
authentication. NTLM authentication will cause an exception about
unbuffered enclosing entity can't be resent or retried (I'm sorry I no
longer get the message so I can't paste it in). Contrary to other
messages if the server is Microsoft and the client is java turning off
expect-continue does not fix the problem. The problem stems from the
fact that the Put Method on http client is setting the size of the
content when it creates an InputStreamRequestEntity. This causes the
entity to not buffer itself (Why you would want this I don't know since
it only buffers 4k at a time). I haven't tried large files yet so
there may still be additional work that has to be done to get this to
work out correctly if the file is large. Anyhow the buffering is
important simply because when you try to put a file to an NTLM
authenticated resource the first attempt will fail with a not
authorized. This will cause a challenge response handshake and then a
retry happens. The problem is with an unbuffered input stream the
retry does not occur because the enclosing entity claims its not
repeatable. Failure every time.
My solution which is not necessarily elegant but may help some desperate
developer out there consists of the following changes:
1: In the jakarta.commons.httpclient project modify:
org.apache.commons.httpclient.methods.InputStreamRequestEntity
When contentlength is declared set it equal to
CONTENT_LENGTH_AUTO // This change is probably not absolutely required
but its what I did.
org.apache.commons.httpclient.methods.EntityEnclosingMethod
Modify method generateRequestEntity - change the new for
new InputStreamRequestEntity to use the single arge constructor as in
new InputStreamRequestEntity(is)// By not passing the size it
stays in CONTENT_LENGTH_AUTO mode which permits buffering.
2: In the Slide webdavclient project modify
org.apache.webdav.lib.WebdavResource
In the put(String,InputStream) method remove the content length
chunked set command.
Sample code that now works:
public static void main(String[] args){
try {
File file = new File(src);
if (file.exists()) {
System.out.println(Uploading ' +
