I need to display uploaded files on a web application, the flow is as follows
User uploads file through web UI
Validation on image
Makes call to imageRepository.store( uploadedImage, user.getSite() )
The user wants the image displayed which adds <img src="${anUploadedImage.getUrl()}"/>
but that is where I'm stuck, what can getUrl() do? The simple solution is to put it someplace and let Apache serve the file, but then I can't use the application to ensure that one user isn't modifying the URL to view other users files, which in this case is important
You have a couple of options if you want to manage the path to the file.
You can create a service to return a file by ID. Essentially this controller-action (or servlet) would load the image back from the repository store and serialize it back to the user. This provides the most control.
You can create a filter that performs the control you want, then delegates back to the web server to perform the actual file serving. This still gives you control, but takes the responsibility off of your app to serialize the file efficiently.
The one thing I would want to verify (since I'm not sure what type the ${anUploadedImage} is) is what URL getUrl() is returning. If it is a File object, then getUrl() provides a file URL which is useless in the HTML. Essentially the web browser would go looking on the user's drive or report some sort of fishy activity.
The URL you include in your HTML needs to point to where your service will send the desired image.
Related
I know solution of the above problem using HTML form in which user chooses a file from computer and upload it and then download it but how to do it without using HTML with the already given path of file.
Thank you For your concern in Advance.
I assume the scenario is that the user accesses your server from a browser.
In this case you will not be able to access the file system given file paths. Only the user can grant access to certain files by selecting them in a file upload input.
If the user uses a mobile/desktop application that sends the file to your server, you must implement the upload in the app itself.
I'm working on a web application at the moment using Tomcat and spring framework. A CSV file is stored on the server, the path to the file and the filename is stored in the database.
A search button on a webpage would list all records in database, if user click on one listed item, a saving dialog would be displayed and the file will be saved locally.
I want a dialog like this opened when user click on one item, how can I do it with httpServlet? I can think about a solution is set content-disposition type in response header to 'attachment'. It would force the browser to download the file instead of trying to display it in browser. But I want user to be able to select the type for file download. Please take a look at the image below
Setting the Content-Type response header to something that the browser is unable to render should prompt the user to save the file upon receiving the response. A value of application/octet-stream (arbitrary binary data) should do the trick.
However, since you expect the actual file content to be in different format depending on user choice, here's what you would need to do:
create a link/form on your html page that will allow user to select a type and make a request to URL with proper extension (like download/file.xls for XLS or download/file.csv for CSV).
in your servlet that handles these URLs, check the extension requested (easy) and then convert the file to expected format within your servlet (not so easy) and send it in response.
The scenario is like : I have a page on which when we submit a file number, the client is given a link to download the file. But I don't know how to write one servlet which will decide which file to send to the client. This has to happen on clicking of a link, so I can't send parameters which can help me determine which file to download.
Please help.
you submit a file number;
you build a link based on that file number (it's a link for a GET. GET can have parameters, so you can put parameters in the URL path or in the query string);
user clicks the link;
the link is handled by a servlet;
the servlet uses the parameters from the GET request to determine what file to send;
you send the content of that file in the response.
Those are the steps.
Here is an example on BalusC's blog: http://balusc.blogspot.ro/2007/07/fileservlet.html
What you need to take care of is security:
don't expose the file directly as path on the server otherwise users can navigate the path to access other files on your application;
if users of your application have different rights, make sure you check those rights before returning the file, so that you a user can't access somebody else's files.
I have a web application in which one of the workflows, users can download files that are dynamically generated. The input is a form which has parameters needed to generate the file.
My current solution is to let them submit this form & on the servlet side I change the response header - content disposition to be an attachment & also provide an appropriate mime-type.
But I find this approach to be inadequate. Because there are chances that the generation of file can take a very long time, in such cases after a certain timeout I directly get 500 or 503 errors in the browser. I guess this is to be expected for the current approach.
I want my workflow to be flexible enough to tell the users as soon as they submit the form that it might take time for the file to generate & that we will display the link to the file as soon as it is ready. I guess I can also email the file or this message to them, but this is not ideal.
Can you guys suggest me an approach for this problem? Should I be more specific in providing information? Any help appreciated.
If you want to do this synchronously (i.e. make the user wait for the document to be ready rather than have them go off and do other things while waiting) a traditional approach is to bring them to a "report loading" page.
This would be a page that:
1) informs them that the report is loading.
2) refreshes itself (either using the meta refresh tag or javascript)
3) upon refresh, checks to see if the report is ready and either:
a) goes back to step 1 if it isn't ready
b) gives them the document if it is ready.
Synchronous is kind of old-school, but your question sounded like that was the approach you wanted.
Asynchronous approaches would include:
Use Ajax to make a link to the document appear on the page once it is ready.
Have a separate page that shows previously generated documents. The use can go to this page at their leisure, and, meanwhile, they can browse the rest of the site. This requires keeping a history of generated documents.
As you suggested, send it via e-mail.
You can make an asynchronous Ajax Call to the server with the form data instead of submiting the form direct.
On the server you create a temp file and return a link to the client with the download URL.
After submitting the answer via Javascript you can show the user a hint, that the download link will appear in a minute. Don't forget to cleanup the temp file!
For submitting the Ajax Call I would suggest using an Javascript Framework. Have a look at JQuery:
http://api.jquery.com/category/ajax/
In firefox 2 I was able to get the path using Browse - I use the path in our project to then write out files to that location. So now that browse does not get the path, does anyone know a way for a user to go to a directory and have the path returned via a web page so I could pass that along to the server for processing?
execCommand does not work in firefox and had limites save type capaility, and entering by hand is not a useable option. Thanks.
The ability to see a complete client file path is now considered a security risk, and all modern browsers prevent you from seeing it (both via Javascript and via information sent back to the server on the form POST).
This is not possible with HTML/JavaScript. In HTML you can at highest use <input type="file"> to select a file, but not a folder or so. In JS you can't do anything at the local disk file system, let alone with a <input type="file"> element in the DOM tree. You're prohibited by security restrictions (you as being an enduser would of course not like if websites are able to do stuff at the local disk file system unaskingly).
You can only do that with a small application which runs straight at the client machine. For example a (signed!) applet which is basically just a piece of Java code served by a webpage which runs right at the client machine. You can communicate between applet and servlet using java.net.URL and consorts. Then, in the applet use Swing's JFileChooser to have a folder or file selection dialogue.
Update: by the way, MSIE and some other ancient browsers sends the full client-side disk file system path along the <input type="file"> to the server side. This is technically wrong (only the filename+extension should have been sent) and completely superfluous. This information is worthless in the server side, because it cannot access the file using the normal java.io.File stuff (unless both the server and the client runs at physically the same machine which of course wouldn't occur in real world). The normal way to get the uploaded file is to parse the multipart/form-data request body (for which one would normally use Apache Commons FileUpload or the Servlet 3.0 provided HttpServletRequest#getParts()).