Scenario: server provides same Webstart Applet to many different (but authenticated) clients. Each Applet has to "know" which client it is on. Therefor the server has to be able to pass some parameters to the client, which is then read by the Applet, running on that client.
Is it possible for a Webstart Applet to access the cookies of the web browser from which it was launched?
Is it possible for a Webstart Applet to access the URL by which it was identified?
Some other options?
EDIT: Perhaps Webstart Applet is a wrong term. I mean just a Webstart Client App.
See the applet-desc element in JNLP File Syntax for details.
Addendum: See also Accessing Cookies.
More pertaining to your 2nd point. URL query parameters can be parsed using JavaScript and added to the applet element. Attributes in the applet element will add to, or overwrite, the values set in the JNLP file.
Related
Here's what I would like to do.
I have a PHP file in my server where I would like to call java applet. The applet function will send a get request to read a page from third party server. Now I want page read from applet function to be sent to PHP script. To simply put ,i want the return value of the applet request function in a PHP variable. Is it possible to do?
I want to do this way because I already have the code to parse the page information in PHP, so I don't want to rewrite that in java again.
I wanted the Java applet because the request has to be sent using the client information like IP. So I don't want to use proxies.
Note: I am not trying to hack anyone's server. I am not a advanced programmer of either Java or PHP. Please reply me in a descriptive manner possibly with pseudo code.
I already have the code to parse the page information in PHP, so I don't want to rewrite that in java again.
PHP should be able to get that page more easily than can a Java applet. The applet would need to be trusted or in communication with a site that uses the 'cross-domain resources' file that explicitly allows hot-linking.
Searches on 'php proxie' seemed to spill out around 7.32 million hits. I'd start there.
Is there any interaction between applets and their hosting browser when making HTTP requests, or are requests made completely independently of native browser code?
Specifically, do Java applets running in a browser have some implicit way of sharing the browser's session state and cache?
I've read a few posts from non-authoritative sources saying that when an applet makes an HTTP request that it will use the browser's cache, and that it will also have access (somehow) to the browser's cookies.
Tests I've done using URLConnection suggest that this is not the case, and my gut feeling is that it sounds far too convenient to be true. I would assume that nothing in the JVM knows anything about the world outside of that JVM, meaning the only other way this could work would be if the JVM implementation is specific to the browser its implementation of the URL-related methods delegate to native browser code?
If cookie data is not implicitly shared or available, is best practice to pass a session ID in a param tag to the applet? Are there security concerns with this approach? If the applet doesn't use the browser's cache for requests, how does caching requests in an applet work?
Applets are executed by the Java Plugin, which is a browser plugin. The applet is indeed part of an HTML page loaded by the browser, can communicate with the browser DOM and with JavaScript code in the page, and uses the browser to send requests to its originating server.
See http://docs.oracle.com/javase/tutorial/deployment/applet/appletExecutionEnv.html and http://docs.oracle.com/javase/tutorial/deployment/applet/server.html for more information.
My testing with Windows 7, Java 1.6.23 and Firefox, Chrome and Internet Explorer is that HttpURLConnections from within an applet's JVM interact in no way with the browser. They don't use the cache, and don't have cookie headers added.
I think it depends on the Java plugin. My experience is that usually it uses the browser cache for network connections, and usually it transmits the cookies. I have had to empty the browser cache before to get a new file in an applet.
If you look at the Oracle Java 7 Plugin Control Panel, you will see an option in the network parameters to use direct connections for the applets, but the default is to use "browser parameters".
As for the cookies, I have seen in the past some Java plugins that did not transmit the session cookies, in particular on MacOS X (Apple even suggested a workaround). But most developers now assume that they are transmitted, and in practice it usually works.
Applets do not share the session information by default, but you can pass the session ID via Applet parameter while initializing. And use the session ID for each HTTP request.
Applets can interact with the browser to make HTTP requests via JavaScript calls.
If you use any Java HTTP APIs e.g. UrlConnection, Apache HTTPClient, java.net.Socket these libraries will not interact with the browser. They behave as if they were in a standalone JVM.
Caching id depenednt onthe API you use, Apache HttpClient has a cache. URLConnection lets you write your own cache easy enough.
You can not directly access the existing cache in JavaScript yet, its comming tho. https://developer.mozilla.org/en-US/docs/Web/API/CacheStorage.
A param tag can not change once the page is rendered, e.g. OAuth tokens need refreshing periodically.
You could fetch cookies from the browser via JavaScript and manually add them to a Java initiated HTTP request. This mechanism allows them to be updated.
There is not much added risk sharing a cookie. You would have to remove the HTTPOnly flag on the cookie if there is one.
If you are allowing Java in the browser your users are letting you do pretty much anything. Java inside the browser does have a sandbox but its worryingly easy to break out. If you can design apps without Java they will be much more secure for users.
From the point of view of the person writing the Applet, Java is secure and much more flexible than JavaScript in a Browser.
Can we read cookies using core-java, that has been written using .NET MVC code? I have not find any help how to read cookies using core java code?
More Background Details -
Actually we have a java desktop application and we are planning to launch that java desktop application using JWS and that is working absolutely fine.
The issue is -- we ask some user related information from user on web page and launch java desktop application using JWS. Now we would like to have that information provided by user on web page in our java application.
We have write that information into cookies and how can we read that information from java code ?
Yes, you can receive cookies that have been set by another application (as long as the path value in the cookie matches). Cookies are part of the HTTP protocol and it does not matter how thay were defined. The client sends them in future requests depending on the URL path.
To access cookies in Java, have a look at getCookies() in HttpServletRequest.
update
The cookies set by your web-application that launches the Java client will have been set in the context of the browser client. Cookies are added to a HTTP response and cached by the client receiving them.
In the case that you describe you cannot access the same server-session from the Java client without trickery.
The solution I would use is to generate a unique ID in the web-app that is passed as argument to the Java client which can in turn request the values needed from the other session using a fetch of a URL using the generated ID as parameter. (This in essence connects the two HTTP sessions as being part of the same user process.)
For instance you could use a HttpURLConnection and a URL like <web-app>/data?id=<ID> to fetch/download the values as XML from your web application.
Core-java? Then try java.net.*:
A cookie is just a header line with "Set-Cookie: " before the URL content.
http://www.hccp.org/java-net-cookie-how-to.html
Why doesn't my Java Applet ask me for permission to start when I open HTML page with it on my localhost?
What is more, the applet starts but it cannot do anything. One of its duties is to connect with a webpage. But it doesn't. In console I can read:
java.security.AccessControlException: access denied (java.net.SocketPermission www.onet.pl:80 connect,resolve)
I guess there is a problem with the security settings of my Java.
It's some time since I programmed my last Applet, but I think you probably need to sign your jars.
The general policy for untrusted (i.e. not signed) applets is that they are only allowed (network-wise) to connect to the server they are loaded from. For applets loaded locally from the file system, this means they can connect localhost.
Asking the user for permission will only occur if either the applet is signed (but then the user gives permission for everything, if there is not a special security policy file) or the applet uses the JNLP functions to request some access (but this is only for local access) - for this, you would need the latest plugin (1.6.0_10 or later).
As Tom mentioned, a remote server can permit applets (and other dynamic web-content like JavaScript, Flash and so on) from other sites to access his server with a cross domain policy file. I'm not sure from which version on the Java plugin implements this, though.
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()).