aspose file tools*
The moose likes JSF and the fly likes Retrieving file path from JSF page drops info Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » JSF
Bookmark "Retrieving file path from JSF page drops info" Watch "Retrieving file path from JSF page drops info" New topic
Author

Retrieving file path from JSF page drops info

John Killman
Greenhorn

Joined: Aug 05, 2010
Posts: 7

Java 1.6.0_22-b03
JSF 1.2
JSTL 1.2
Eclipse 3.6.0 (Helios)
Tomcat 6.0.28
IE 7.0.5730.13
Firefox: 3.6.12


JSP/JSF page fileops.jsp has:

Input field with a browse button
Command button

<h:form id="xmlCmdForm">
<h:panelGrid width="350" columns="2" border="0" style="width: 350px; ">
<input
name=xmlDataFile
type="file"
size=50>
</h:panelGrid>

<h:panelGrid width="250" columns="2" border="0" style="width: 250px; ">
<h:commandButton
id="writeDataCmd"
action="#{fileopsBean.writeXmlData}"
value="#{msg.writeDataCmd}"
style="#{msg.widthFileopsButton}">
</h:commandButton>
</h:panelGrid>
</h:form>


Backing bean has:

public String writeXmlData() {

String value = FacesContext.getCurrentInstance().
getExternalContext().getRequestParameterMap().get("xmlDataFile");

System.out.println("Write the XML data" + ": " + value);

return "write";
}


There exists a file: c:/temp/abc.txt



Eclipse (internal Tomcat):
The local file system can be browsed and the full path appears in the input field.
If the command button is pressed then the backing bean writes out (correctly):
"Write the XML data: c:/temp/abc.txt"

IE:
If the Eclipse (and internal Tomcat) are left up then:
On IE, the local file system can be browsed and the full path appears in the input field.
The result is the same:
"Write the XML data: c:/temp/abc.txt"

Firefox:
If the Eclipse (and internal Tomcat) are left up then:
On Firefox, the local file system can be browsed and again, the full path appears in the input field.
However, only the filename without the path is sent across to the backing bean:
"Write the XML data: abc.txt"

Any ideas as to why?


Also, in Eclipse and IE, after browse, the displayed file path/name can be edited and sent to the backing bean.
On Firefox, clicking on the field brings up the file chooser (thus, no browse button is actually needed).
However, the path/filename cannot be altered.

Again, any ideas as to why?


Thanks,
John
Ilari Moilanen
Ranch Hand

Joined: Apr 15, 2008
Posts: 198
1.) Since your form is defined incorrectly i.e. it does not have the "enctype" attribute defined you can not send files with it. But apparently you can send the name of the file if you want (and maybe you even are planning to write only locally so you do not even need the file at the server side?)

2.) The input type "file" SHOULD send only the the name of the file to server (and the file itself obviously) so Firefox behaves correctly but IE and Eclipse do not. So you just have to remember that when you design your application. The bug is in IE and Eclipse, not in your code.

And what comes to the fact that you can change the name of the file and its path afterwards in IE and in Eclipse in my opinion that too should not be possible and is a bug. But I do not know for sure what the html specification says about that. If the change is possible for example with javascript then it is a obvious security risk but if only the user is able to change it then it is of no concern since if he/she puts a nonexistent file name there then nothing is sent (hopefully). But in this case too you just have to remember that.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16141
    
  21

It was a little hard to read this, so I may be saying meaningless things, but there are some "gotchas" when it comes to file uploading in HTML (and not only in JSF).

IE sends the entire pathname. That's A) useless and B) a security risk. I know, security risk, IE, whodathunkit.

It's useless since file upload isn't really "file" anything. The browser opens the file selected from the dialog box, but what it actually does is open that file and copy its contents into the HTTP request data stream. Since HTTP is not a file server protocol and is in any event not symmetrical, there's nothing the server can do with the client's directory path as far as actually accessing the file on the client (which is good, or rogue servers would be running rampant over people's files).

It's a security risk because it's gratuitously exposing a view of the client computer's filesystem layout. That's a clue that a Bad Person might be able to use.

Firefox only sends the simple filename. Again, the name of the file on the client is of no direct benefit to the server, but it does provide a convenient identifier that can be used (or ignored) as a little bit of side data.


Customer surveys are for companies who didn't pay proper attention to begin with.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Retrieving file path from JSF page drops info