Opened 12 years ago

Closed 12 years ago

#1426 closed defect (invalid)

Problem viewing/downloading file with special characters in folder/file names

Reported by: base Owned by: everyone
Priority: major Milestone:
Component: web Version:
Keywords: special character folder name Cc:

Description

It is possible to create folder with '+' in the name. When trying to download files in folder with such a name, the link gets corrupted (since + has a special meaning in links) and it is impossible to download a file. I guess it will be similar with filenames (have not tested) and other characters like ? or =. A check could be done when creating file/folder so that these characters are not used.

Change History (9)

comment:1 Changed 12 years ago by Nicklas Nordborg

+ and = are valid in file names. ? is not and this is already checked together with a few other characters. See http://base.thep.lu.se/browser/trunk/src/core/net/sf/basedb/core/Path.java#L56.

I am not able to reproduce the problem. I have created a directory named 'a+b=c' and I have no problem uploading or downloading files in it. I am currently trying this with Firefox 3.5 on Windows. It may be a browser/os-related problem. If so, please give us more details about your environment.

comment:2 Changed 12 years ago by Nicklas Nordborg

I can not reproduce the problem with IE 8 on Windows or with Firefox 3.0.14 on Linux. This was tested against BASE 2.14. Is this maybe the same as #1307 that was fixed some time ago?

comment:3 Changed 12 years ago by base

I will come back with more feedback soon. Currently out of time:/

comment:4 Changed 12 years ago by base

I created folder with name a+b=c, uploaded a file and when downloading I get the following message:

On page /filemanager/files/download/-b8d27650300d10fa-/home/pawels/other/a+b=c/Spleising.pdf Item not found: File[path=/home/pawels/other/a b=c/Spleising.pdf]

Renaming folder to ab=c helps, so it is only + that messes things up. I am using FF 3.0.15 in CentOS. Here is the server config:

Version BASE 2.13.1 (build #5134; schema #75) Web server Apache Tomcat/6.0.20 Database Server PostgreSQL 8.3.8 Database Dialect org.hibernate.dialect.PostgreSQLDialect JDBC Driver org.postgresql.Driver (version 8.4) Java runtime Java(TM) SE Runtime Environment (1.6.0_03-b05), Sun Microsystems Inc. Operating system Linux amd64 2.6.9-78.0.22.ELsmp

comment:5 Changed 12 years ago by Nicklas Nordborg

.../home/pawels/other/a+b=c/Spleising.pdf

This path is clearly incorrect. The path I get with a similar directory name is:

.../home/a1/a%2Bb%3Dc/foo.txt

+ has been encoded with %2B and = with %3D which I assume is correct because the file is loaded and displayed as expected in Firefox. I am on BASE 2.14.1 and Java 1.6.0_14-b08. Looking at our own code I can't find any changes since 2.11.1 that are related to the file download functionality so it should work in BASE 2.13. There are several Java versions between 1.6.0_03 and 1.6.0_14. Maybe there is something that was broken that has been fixed.

I would try to update Java and see if that helps and if not, then also update BASE to 2.14.1.

I also noticed that different methods are used for encoding the URL in the 'view' and 'download' function. Both encodes the + to %2B but the download leaves the equal sign unencoded. Does the view function work?

comment:6 Changed 12 years ago by Nicklas Nordborg

Hmmm.... I just tested on the demo server and I get the same error there. The weird thing is that the URL in the browser is:

http://base2.thep.lu.se/demo/filemanager/files/view/-74ed0316af6ce588-/home/base2/a%2Bb%3Dc/foo.txt

which seems like a correct encoding of the path to the file. Still, BASE complains with:

Item not found: File[path=/home/base2/a b=c/foo.txt]

So for some reason the %2B is translated to a space. The demo server is running:

Version  	BASE 2.14.1 (build #5183; schema #76)
Web server 	Apache Tomcat/6.0.20
Database Server 	MySQL 5.0.51a-log
Database Dialect 	org.hibernate.dialect.MySQLInnoDBDialect
JDBC Driver 	com.mysql.jdbc.Driver (version 5.1)
Java runtime 	Java(TM) SE Runtime Environment (1.6.0_04-b12), Sun Microsystems Inc.
Operating system 	Linux i386 2.6.18-53.1.14.el5PAE

On my development machine everything works. I am using the same browser so it should not be a browser issue. Here are the details for my development machine:

Version  	BASE 2.15.0pre (build #5185; schema #76)
Web server 	Apache Tomcat/6.0.20
Database Server 	MySQL 5.0.83-log
Database Dialect 	org.hibernate.dialect.MySQLInnoDBDialect
JDBC Driver 	com.mysql.jdbc.Driver (version 5.1)
Java runtime 	Java(TM) SE Runtime Environment (1.6.0_14-b08), Sun Microsystems Inc.
Operating system 	Linux i386 2.6.25.20-0.5-default

I also discovered that the following URL works on the demo server:

http://base2.thep.lu.se/demo/filemanager/files/view/-74ed0316af6ce588-/home/base2/a%252Bb%3Dc/foo.txt

The interesting part is a%252Bb%3Dc.

  • %25 is the escape sequence for %, and if decoded once it gives a%2Bb=c.
  • If this is decoded a second time we get a+b=c which is the correct name of the directory.

It seems like the URL is decoded twice on the demo server. The big question is why this happens there but not on my development machine... we are only decoding it once in our code. The main difference is the Java version... is it maybe a bug in the URLDecoder.decode() function... or could it be some Tomcat configuration setting....

comment:7 Changed 12 years ago by Nicklas Nordborg

I think it is the Apache front-end that does the first decoding. I tried this setup at home and if I use direct access to Tomcat it works, but if I access through Apache it breaks down as above. I found this rather old post: http://markmail.org/message/64oc4t3uf4wrormq#query:apache%20tomcat%20decode%20uri+page:1+mid:64oc4t3uf4wrormq+state:results

If I add JkOptions +ForwardURICompatUnparsed it works with Apache also.

comment:8 Changed 12 years ago by Martin Svensson

The problem disappeared on the demo-server when using the suggested mod-jk parameter.

comment:9 Changed 12 years ago by Nicklas Nordborg

Resolution: invalid
Status: newclosed
Summary: Missing checks for special characters in folder/file namesProblem viewing/downloading file with special characters in folder/file names

Seems like it was a configuration issue when Tomcat + Apache both decoded the URL.

Note: See TracTickets for help on using tickets.