click here for details... Sakai Executive Director Position Search now open
Issue Details (XML | Word | Printable)

Key: SAK-15001
Type: Bug Bug
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: Charles Hedrick
Votes: 0
Watchers: 3
Operations

If you were logged in you would be able to see more operations.
Sakai

webdav can create file names that content can't fetch

Created: 01-Dec-2008 11:26   Updated: 11-Feb-2010 03:21
Component/s: Content service (Pre-K1/2.6)
Affects Version/s: 2.5.0
Fix Version/s: None

Time Tracking:
Not Specified

Issue Links:
Incorporate
 

2.6.x Status: None
2.5.x Status: None
2.4.x Status: None


 Description  « Hide
We had a user create a name with # in it via webdav. It couldn't be downloaded from resources, because # has a special meaning in URLs.

There are two different issues:

1) Webdav uses addResource(id) to create resources. In BaseContentService/addResource(String), the following code appears:
               String justName = isolateName(id);
               Validator.checkResourceId(justName);
This is probably intended to prohibit names with odd characters. However checkResourceId is a boolean function. The return value is not used, so this test is a no-op. But we really want it to be a no-op. Webdav clients expect to be able to create any legal file name. Validator.checkResourceId prohibits any name containing "^/\\{}[]()%*?#&=\n\r\t\b\f". This is far too strict. It would be a disaster to disallow any file with these characters in it. Note particularly the presence of blank, but other characters would be a problem as well. So in my opinion these two lines of code should simply be removed. If the fact that they don't do anything was a problem, we would have seen it by now.

2) When generating the URL for use in the Resources tool, special characters are not escaped. If you create a file in the resources tool itself, special characters tend to get turned into _. But this is not the case if DAV creates the file. We really need to escape URLs properly, so that any file created by DAV can be fetched. That simply requires getUrl to call Validator.escapeUrl. I can't tell when the three different getUrl's are used. I fixed the two that didn't have escapeUrl, and that fixed my problem.

--- content-impl/impl/src/java/org/sakaiproject/content/impl/BaseContentService.java (revision 992)
+++ content-impl/impl/src/java/org/sakaiproject/content/impl/BaseContentService.java (working copy)
@@ -9958,7 +9958,7 @@
          */
         public String getUrl(boolean relative)
         {
- return getAccessPoint(relative) + convertIdToUserEid(m_id);
+ return getAccessPoint(relative) + Validator.escapeUrl(convertIdToUserEid(m_id));
         }
 
                /**
@@ -11116,7 +11116,7 @@
                {
                        return (relative ? m_serverConfigurationService.getAccessPath() : m_serverConfigurationService.getAccessUrl())
                                        + getAlternateReferenceRoot(rootProperty) + m_relativeAccessPoint
- + convertIdToUserEid(m_id);
+ + Validator.escapeUrl(convertIdToUserEid(m_id));
                }
 
                /**



 All   Comments   Work Log   Change History   Subversion Commits   git Commits      Sort Order: Ascending order - Click to sort in descending order
Charles Hedrick added a comment - 26-Jan-2009 12:17
Note by the way that turning all special characters into _ would be a real problem for DAV. DAV clients think they are talking to a file system. They expect to be able to create the same kinds of files they could on a Unix system, and they expect that the name used to create the file will be the name the file actually has. No extra extensions, no characters turned into other characters.