You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2002/07/08 01:51:18 UTC
DO NOT REPLY [Bug 10539] New: -
Active lock discovery returns invalid lock tokens ("dummytoken")
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10539>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10539
Active lock discovery returns invalid lock tokens ("dummytoken")
Summary: Active lock discovery returns invalid lock tokens
("dummytoken")
Product: Tomcat 4
Version: Nightly Build
Platform: All
OS/Version: All
Status: NEW
Severity: Normal
Priority: Other
Component: Servlets:WebDAV
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: fredrikv@biotech.kth.se
Problem:
========
The reply to PROPFIND queries returns "dummytoken" as lock token
instead of the correct lock token. This confuses Adobe Golive 6.0
and Macromedia Dreamweaver MX and they can't be used for editing
resources on a Tomcat 4 server.
The behaviour is observed on Tomcat 4.x (4.0.4-4.1.7b).
Discussion:
===========
This issue has been discussed at least once before, see URL
http://faqchest.dynhost.com/prgm/tomcat-l/tmct-01/tmct-0111/tmct-011114/tmct0111
0721_30463.html
where, Remy Maucherat says
>the behavior is correct (servers are allowed to obsfucate
>lock-tokens returned by a PROPFIND)
I guess this is based on section 13.8 that states:
>13.8 lockdiscovery Property
[---]
>Description: The lockdiscovery property returns a listing of who has
>a lock,
what type of lock he has, the timeout type and the time
>remaining on the
timeout, and the associated lock token. The server
>is free to withhold any or
all of this information if the requesting
>principal does not have sufficient
access rights to see the requested
>data.
As I understand it, the server can only refuse to show the lock token
if the user is not authenticated. Now, even when using the right
credentials, the lock token is not returned by Tomcat.
There is one other applicable example 13.8.1 in the RFC that returns
the correct token, and as Golive and Dreamweaver does not work at all
with the dummy token enabled, I suggest changing Tomcat's reply to the
correct lock token for PROPFIND queries.
The main reason I can see for providing a dummy token would be that
anybody listening can unlock it if the correct token is used. This is
covered in RFC2518 section 6.3:
>Having a lock token provides no special access rights. Anyone can
>find out
anyone else's lock token by performing lock discovery.
>Locks MUST be enforced
based upon whatever authentication mechanism
>is used by the server, not based
on the secrecy of the token values.
Solution:
=========
Change WebdavServlet.java to return the correct lock token every time.
For example, the change can be done according to this diff -u file:
(not tested because I can't build Tomcat from sources)
--- WebdavServlet.java Sun Jul 7 23:37:28 2002
+++ WebdavServlet.java.orig
Sun Jul 7 22:35:29 2002
@@ -2667,7 +2667,7 @@
* append an XML
fragment to the given XML writer.
*/
public void toXML(XMLWriter generatedXML) {
- toXML(generatedXML, true);
+ toXML(generatedXML, false);
}
Alternatively, there should be a possibility to set the behaviour
(dummytoken=no/yes) in a configuration file. As this problem is
quite convoluted to find, the default should be not to use dummies.
Example:
========
Using Golive 6.0 and Tomcat 4.1.7-beta (as recorded by httpsniffer.pl)
The file /davtest/test.txt contains a short text and was locked by the
same application in the last transaction when the correct lock token
was returned. Now it does a PROPFIND when I'm trying to unlock the file.
>> Query
--> C05 --> S06 ==== (60) Request <PROPFIND /davtest/test.txt HTTP/1.0>
--> C05 --> S06 PROPFIND /davtest/test.txt HTTP/1.0
--> C05 --> S06 accept-language: en_US
--> C05 --> S06 depth: 0
--> C05 --> S06 Mime-Version: 1.0
--> C05 --> S06 Content-Type: text/xml
--> C05 --> S06 Content-Length: 332
--> C05 --> S06 Host: localhost:80
--> C05 --> S06 Connection: keep-alive
--> C05 --> S06 Keep-Alive: 300
--> C05 --> S06 Accept: */*
--> C05 --> S06 ==== Body 332 bytes
--> C05 --> S06 Body => <?xml version="1.0" encoding="utf-8" ?><D:propfind
xmlns:D="DAV:"><D:prop
xmlns:AGL="http://ns.adobe.com/golive/5.0/"><D:creationdate/><D:displayname/><D:
getcontentlanguage/><D:getcontentlength/><D:getcontenttype/><D:getetag/><D:getla
stmodified/><D:lockdiscovery/><D:resourcetype/><D:source/><D:supportedlock/></D:
prop></D:propfind>
<< Reply
<-- C05 <-- S06 ==== (60) Response 207 to <PROPFIND /davtest/test.txt HTTP/1.0>
<-- C05 <-- S06 HTTP/1.1 207 Multi-Status
<-- C05 <-- S06 Content-Type: text/xml; charset=UTF-8
<-- C05 <-- S06 Connection: close
<-- C05 <-- S06 Date: Sun, 07 Jul 2002 20:04:18 GMT
<-- C05 <-- S06 Server: Apache Tomcat/4.1.7 (HTTP/1.1 Connector)
<-- C05 <-- S06 ==== Body 1031 bytes
<-- C05 <-- S06 Body => <?xml version="1.0" encoding="utf-8" ?>
<multistatus xmlns="DAV:"><response><href>/davtest/test.txt</href>
<propstat><prop><creationdate>2002-07-07T19:47:44Z</creationdate>
<displayname><![CDATA[test.txt]]></displayname>
<getcontentlanguage>sv_SE</getcontentlanguage>
<getcontentlength>24</getcontentlength>
<getcontenttype>text/plain</getcontenttype>
<getetag>24-1026071264185</getetag>
<getlastmodified>Sun, 07 Jul 2002 19:47:44 GMT</getlastmodified>
<lockdiscovery><activelock><locktype><write/></locktype>
<lockscope><exclusive/></lockscope>
<depth>0</depth>
<owner>fredrikv</owner>
<timeout>Second-604799</timeout>
<locktoken><href>opaquelocktoken:dummytoken</href>
</locktoken>
</activelock>
</lockdiscovery>
<resourcetype/><source></source>
<supportedlock><lockentry><lockscope><exclusive/></lockscope><locktype><write/><
/locktype></lockentry><lockentry><lockscope><shared/></lockscope><locktype><writ
e/></locktype></lockentry></supportedlock>
</prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
</response>
</multistatus>
/Fredrik
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>