I have a web-application that I want to have the ability to read a file from a specific directory on the users PC (and send this file to a remote DB via some REST call) - and vice-versa, get this file from the remote DB and write to the users PC in this specific directory. Besides an Applet, what are some of the more common / secure ways of achieving this?
Unfortunately, this is not possible using a web-application. The browser will not allow this - as it represents a security breach on the client side.
You will need explicit permission from the user to upload a file onto the server - most web-applications use a file upload mechanism - which is a manual process.
You could, however use HTML 5 Web Storage, which is similar to cookies, but allows the browser to store key value pairs.
From what I understand, an applet is a Java program which is run outside of the browser on the client machine - which is therefore able to read / write to the local machine.
Hope this helps.
Related
I have been working with Laravel for a little less than a month; so, not aware of all the pre-defined functionality it has to offer. I have a bunch of CSV files in my Laravel application storage and I want to access them from another application (a Java application that processes those CSV files to produce some results).
What would be the best way to go about it?
I have a basic user management system set up and the users fill in an application form (which is where the csv files come from). These files are stored in the Laravel storage.
My current approach without using any built-in authentication (because I am not confident about how to use it in this case) is to have a controller return a downloadable file on a POST request (the file just gets downloaded upon request). The data sent with the POST request is the filename and a password, which if correct, returns the file; otherwise, gives an error. Is this a good way to approach the problem?
I simply want to retrieve the files by making a request from the Java application. Also, some basic protection is required so that everyone cannot access the files by making such requests. Any help or resources would be helpful. Thanks!
Use digitalocean space as additional shared storage between two servers (php and java) then make storage access private using digitalocean dashboard and finally add new website cors on space settings has your java domain and its http verbs (get post delete...). With this configuration you could access your cloud storage between two servers safely using access key and secret key.
Ok, I'm a beginner so this maybe stupid but i afraid that clients can modify static resources (css/javascript files) on server if they can load them directly through URL path (Of course I have to put css/javascript files outside of WEB-INF folder).
If my hypothesis is wrong, could you give me links or quotes to help me expand my knowledge ? Thank you :)
When a user's browser requests resources from your server, they are performing a GET request. This request will not directly change any file on your server. The request will go through your web server and will be processed. In the case of the resources such as css/javascript files, the web server sees the user is requesting the file and sends the contents of the file back. There is no way the user can update the contents of those files on the server unless you write code on the server to allow them to update the files. If the user has direct access to the server via ssh or other protocol and has permissions on the folder that holds the resources, they would be able to change them.
The whole process is much more complex for going through the web server, but for brevity left out here. Here is a good article that explains what really happens when you go to an address in a browser:
https://medium.com/#maneesha.wijesinghe1/what-happens-when-you-type-an-url-in-the-browser-and-press-enter-bb0aa2449c1a
We have a Java class that is supposed to fetch an HTML file and then read some content in it based on the id of certain divs and then return the content to a frontend which will then render it.
Now we have a set of HTML files on a common file system somewhere on the network. Multiple applications will access it. It is like a homegrown GUI help guide for our customer facing screens with a centralized storage.
We have managed to load the html file in 2 ways
Start an Apache web server and put all html files in htdocs. The calling Java class then makes an http call http://someIP:80/helpguide/userguide.html #firstname. This will fetch the help guide related to FirstName field on the screen. The Apache service has to be managed as it is accessed in Live but only accessible within our network.
Create a Shared directory and grant access to it to the Windows logon used to run the Windows service that runs Tomcat where the client facing web application is deployed. Then the Java client class uses new File("<file location>") to load the file and read its content. This works as well.
Basically we have 2 ways to load the html file. Now we are confused whether to use route 1 or 2?
The html files won't be that massive and will be of reasonable size. It may have inline css or youtube video links embedded in them.
Downside of (2) is if we want to include images later it won't work while it should work with (1).
However in terms of performance and efficiency how are teh 2 approaches different? (1) will open a Http socket connection over port 80 and get the html stream back. WIth (2) It will possibly use a File Inputstream to get the file on the server.
I'm working on the applet that reads data files from one specific folder (lets call it 'Data folder'). Number of files and their names can change over time so I don't want to add them rigidly into the code. I would like to be able to list all the files stored in that folder (note: folder is stored on the same server as applet). I tried to do that using Files.walkFileTree method. It worked just fine when I ran it in the Eclipse but I got AccessControlException:
java.security.AccessControlException: access denied ("java.io.FilePermission" "Data folder" "read")
when I tried to run in the browser.
I can see why would jvm want to restrict applets from listing files on local computer but is it possible to list files stored on the server?
You have to distinguish between client side and server side code. Your applet is executed at client side, so it is unable to access the server's file system directly with Files.walkFileTree().
What you can do is to implement a service (like a REST service or a simple servlet) and run it on server side in a Tomcat or Jetty servlet container and then call this service from your applet. But be careful to make your service secure, so that it is not allowed for erveryone to see your server's whole file system.
Currently i have a java applet (with tomcat 6 as backend) that allow users to upload file and download file for document sharing. However, many users forget to upload the edited file back to the server.
Hence, I would like to enhance the applet to allow user to choose a file* for edit and save directly to the web server. Without having the user to save the file to their local harddisk, and upload the file* back to server manually.
After a few goggling, it seems WebDav is the way. I have configure tomcat with the webdav enable in the web.xml, and now i can view file and edit with a Webdav client CyberDuck.
Questions:
is it possible view / edit / lock the file* without installing a webdav client?
Reason is because i have more than 3000 desktop client using the software. Deployment of the webdav is an issue and how do i let each user to access different webdav so they do not see each other's file?
Is it possible to trigger local application to open a file* inside WebDav?
file* = means any file that are able to open from their local machine; examples: ms word, ms excel, ms powerpoint, pdf, PNG, JPG, txt and etc.
Ah, i manage to open it with:
Runtime.getRuntime().exec("winword http://:/xyz/.../pgl_page-bi.doc");
Problem is, every single type of files will need to have a different string inside the .exec(""); not as clean as i expected but at least it works.