|
Replies:
8
-
Last Post:
Aug 15, 2005 12:51 AM
by: 5er_levart
|
|
|
|
|
|
|
Webstart changes in Mustang
Posted:
Aug 11, 2005 5:07 PM
|
|
|
Webstart looks much more user friendly in Mustang when compared to 1.5. However I have some issues with it:
When running the Mustang webstart for the first time and it upgraded the cache, it reinstalled the shortcuts onto the start menu even though I had manually removed them by deleting them off the start menu using Windows Explorer. Shortcuts should not be reinstalled if they don't already exist or have been moved.
No prompt for removing applications from the cache viewer. OK, some people might like it this way but I think any time anything is deleted there should be a confirmation dialog. If some people insist that it is better off then put an optional to turn confirmation on/off in the Java Control Panel.
The 'downloading application' screen looks better now. However, I do miss the number of Kb downloaded and the estimated time remaining messages. Especially on dial-up, users would like to see an approximation of how much time is left for downloading if it is going to take more than 10 seconds. It is also good to see the number of Kb downloaded and the total size of the app. It's probably right that users no longer have to see the names of the JARs being downloaded - end users don't care about this.
|
|
|
|
|
|
|
Re: Webstart changes in Mustang
Posted:
Aug 12, 2005 8:15 AM
in response to: prunge
|
|
|
From an end-user point of view (dial-up or not) I always care about "estimated time left" and less so about the actual size being downloaded because if your ETA is right why should I care?  I definately think they should be brought back if possible.
|
|
|
|
|
|
|
|
|
Re: Webstart changes in Mustang
Posted:
Aug 12, 2005 9:00 AM
in response to: prunge
|
|
|
We used to use Java Webstart. Now we change back to Applet. The problem for Java Webstart is, I think, that Java Webstart can not inherit the security from the browser like applet. In other words, if I have already signed in to a page, then I click a link to launch JWS, JWS need another sigon. But for applet, we do not need do that. For basic authentication, siteminder integration etc, we have same problem. Even we found solutions, but the solution are complicate. I think JWS should support same security as applet.
|
|
|
|
|
|
|
|
|
Re: Webstart changes in Mustang
Posted:
Aug 12, 2005 9:16 AM
in response to: chen_yingchun
|
|
|
Chen,
I'm not sure that is a realistic thing to expect from JWS. Signing into a site has absolutely nothing to do with giving an application the rights to run outside its sandbox on your system. This is what you're asking for, right?
Gili
|
|
|
|
|
|
|
|
|
Re: Webstart changes in Mustang
Posted:
Aug 12, 2005 1:37 PM
in response to: cowwoc
|
|
|
Gili,
Let me explain the problem we had before. We have a html-based console web app to let user to sign in. After the user signs in, we send cookie back to the browser. In the console html page, we have a link to point to jnlp url, and another link pointing to an applet. If we click the link to applet, we will show an applet in the browser. Then every url posted back to app server will use the cookie from the browser. But for jws, when you click the link to jnlp, we have to use a servlet call to dynamicly create jnlp, and also save the cookie from the servlet to the jnlp file. The reason we do like this is that we need use this cookie to call back to app server from our jws app. If we have siteminder, we also need find a way to save SMSESSION cookie in the jnlp. If we have basic auth, we need save the AUTHORIZATION in the jnlp.
To hold security data in the jnlp file is really a security problem. If JWS agent can get the security environment from the browser where jws is launched, and also put into the server http call like applet, then we can solve this problem. I think that's the thing SUN should think about for JWS.
|
|
|
|
|
|
|
|
|
Re: Webstart changes in Mustang
Posted:
Aug 12, 2005 1:40 PM
in response to: chen_yingchun
|
|
|
I stand corrected then. I had no idea you could do this kind of stuff with Webstart. You obviously know more about this problem than me Good luck! I hope Sun solves this one for you.
Gili
|
|
|
|
|
|
|
|
|
Re: Webstart changes in Mustang
Posted:
Aug 13, 2005 1:27 PM
in response to: chen_yingchun
|
|
|
I suppose you could hack around it, if you don't mind another browser window opening and making a few assumptions.
The JNLP app sends the server a random value. The server responds with a session id. The app the opens a web page with both numbers. Assuming the JNLP implementation supports it and the same browser is used, the server gets sent both numbers and the browser authentication. The server can now send the JNLP app a copy of whatever authentication details are necessary. It can respond to the opened web page with say a quick okay message and perhaps a bit of JavaScript to close the window, as if it wasn't a hack..
|
|
|
|
|
|
|
|
|
Re: Webstart changes in Mustang
Posted:
Aug 15, 2005 12:39 AM
in response to: chen_yingchun
|
|
|
Or perhaps a variant that does not need to start another browser window of the already authenticated browser and goes like this:
- Let servlet dinamicaly generate JNLP file that passes a cryptographicaly signed time-limited (expires in few seconds) session id to the JWS app.
- JWS app uses this session id to connect to server and obtain any additional authentication data that it needs to communicate with the world.
If anyone gets hold of this session id it would only work if it hasn't expired yet (few seconds after download).
Regards, Peter
|
|
|
|
|
|
|
|
|
Re: Webstart changes in Mustang
Posted:
Aug 15, 2005 12:51 AM
in response to: 5er_levart
|
|
|
Ok, I have a counter-attack:
- someone would plant a "fake" javaws.exe on the computer and wait for a user to authenticate and try to start JWS app. Fake javaws.exe would get a signed session id and request other authentication info from the server immediately.
But then again someone could plant a "fake" java applet plugin on the computer and wait for a user to use the applet. So you have to trust the client environment in both cases.
Peter
|
|
|
|
|
java.net RSS
