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: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
