commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (FILEUPLOAD-235) FileItem.getName() does not conform to the Java File.getName behaviour and *returns* a full path when provided with one
Date Tue, 14 Jul 2015 01:40:05 GMT

    [ 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)

Mime
View raw message