[
https://issues.apache.org/jira/browse/FILEUPLOAD-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14625673#comment-14625673
]
David edited comment on FILEUPLOAD-235 at 7/14/15 1:40 AM:
-----------------------------------------------------------
Hi Jochen, I'll reply in an in-line style to your comment.
{quote}Besides, I fail to see any security hazards. It is the Fileupload users
decision, where to store uploaded files, and how to name them, not ours.{quote}
The issue is that I have seen developers who did not read the javadoc for
{{FileItem.getName()}} and just assume that it would provide the same behaviour
as {{File.getName()}} does use {{FileItem.getName()}} to construct a path to
save an uploaded file. By the way others such as Philippe Arteau also have
noted concern about {{FileItem.getName()}} in one way or another. For example,
Philippe Arteau added a [findbugs
detector|https://github.com/h3xstream/find-sec-bugs/blob/master/plugin/src/main/java/com/h3xstream/findsecbugs/FileUploadFilenameDetector.java]
to his find-sec-bugs findbugs plugin for usages of {{FileItem.getName()}}
{quote}Finally, this issue hasn't been a poblem for a real lots of Fileupload
users (you, being the exception). So, again: When weighing <our concerns
against the issue of a binary incompatibility, the latter problem clearly is of
more concern.{quote}
Okay but do you see my point that there is no "value add" in having
{{FileItem.getName()}} return anything different than what {{File.getName()}}
returns?
was (Author: dblack):
Hi Jochen, I'll reply in an in-line style to your comment.
{quote}Besides, I fail to see any security hazards. It is the Fileupload users
decision, where to store uploaded files, and how to name them, not ours.{quote}
The issue is that I have seen developers who did not read the javadoc for
{{FileItem.getName()}} and just assume that it would provide the same behaviour
as {{File.getName()}} does use {{FileItem.getName()}} to construct a path to
save an uploaded file. By the way others such as Philippe Arteau also have
noted concern about {{FileItem.getName()}} in one way or another. For example,
Philippe Arteau added a [findbugs
detector|https://github.com/h3xstream/find-sec-bugs/blob/master/plugin/src/main/java/com/h3xstream/findsecbugs/FileUploadFilenameDetector.java]
to his find-sec-bugs findbugs plugin for usages of {{FileItem.getName()}}
{quote}Finally, this issue hasn't been a poblem for a real lots of Fileupload
users (you, being the exception). So, again: When weighing <our concerns
against the issue of a binary incompatibility, the latter problem clearly is of
more concern.{quote}
Okay but do you see my point that there is no "value add" in having
{{FileItem.getName()}} return anything different than what {{File.getname()}}
returns?
> FileItem.getName() does not conform to the Java File.getName behaviour and
> *returns* a full path when provided with one
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: FILEUPLOAD-235
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-235
> Project: Commons FileUpload
> Issue Type: Bug
> Affects Versions: 1.3
> Reporter: David
> Assignee: Jochen Wiedmann
> Priority: Minor
> Fix For: 2.x
>
>
> I understand that FileItem is simply following RFC 1867, but the
> implementation of 'getName'
> method on a file related class IMHO should follow the behaviour of the java
> File class which
> bq. Returns the name of the file or directory denoted by this abstract
> pathname. This is just the last name in the pathname's name sequence. If the
> pathname's name sequence is empty, then the empty string is returned.
> http://docs.oracle.com/javase/7/docs/api/java/io/File.html#getName()
> I propose that FileItem.getName() is changed to *match* the java File class
> behaviour and that another method called something like 'getRawName' be added
> to the FileItem class. The rational for this change is to make it less easy
> to shoot oneself in the foot (in no modern web application is a 'full
> filepath' useful, especially when most browsers do not send one!).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
