cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - When posting, your subject should be specific and summarize your question. Here are some additional tips on asking a great question. X

How to disable Java Login in Internet Explorer

mdebower
18-Opal

How to disable Java Login in Internet Explorer

Hey Y'all:

We are currently on Windchill 9.0 m060, and when we use Internet Explorer to access Windchill, whenever a java applet launches, we have to "login" or Authenticate to get the applet to run. I will attach a screenshot showing the login window.

Funny thing is when you do the same thing using FireFox, no authentication window appears. MUCH nicer. Because of that, I don't think it is the server requiring us to authenticate.

So: How to get rid of the authenticate login?

-marc

CAD / PLM Manager

27 REPLIES 27
jessh
12-Amethyst
(To:mdebower)

The server requires the same authentication in either case.

The issue is all around how the browser and Java Plug-In share
credentials so you don't have to re-enter them -- or fails to do so as
the case may be.

In the case of Firefox (on Windows at least), this sharing just plain
works -- as you noted.

In the case of Internet Explorer, this will /not /work /unless/ you
check the "Remember my password" checkbox when logging into Windchill at
the browser level. This is due to an architectural shortcoming in
Internet Explorer according to the various folk I've asked (e.g. Sun
engineers).

I've had reports of cases where Internet Explorer and the Java Plug-In
fail to share the password even when this checkbox has been checked, but
have not managed to reproduce this, much less determine why this ever
occurs or how to fix this. This is a failing in Internet Explorer
and/or the Java Plug-In whose nature I've not been able to discover and
which is quite independent of Windchill as best I can tell.

Where possible the best solution is to simply to use Firefox (which is
faster too).

--
Jess Holle

Marc DeBower wrote:
>
> Hey Y'all:
>
> We are currently on Windchill 9.0 m060, and when we use Internet
> Explorer to access Windchill, whenever a java applet launches, we have
> to "login" or Authenticate to get the applet to run. I will attach a
> screenshot showing the login window.
>
> Funny thing is when you do the same thing using FireFox, no
> authentication window appears. MUCH nicer. Because of that, I don't
> think it is the server requiring us to authenticate.
>
> So: How to get rid of the authenticate login?
>
> -marc
>
> CAD / PLM Manager
>

Jess,

Thanks for the info. We do experience the case where IE and Java fail to share the credentials. If you check the "Remember my password" box on the Java Authentication window, it will only remember it for that session. If you log out and back into Windchill you will have to re-enter the credentials every time.

Most of our users here have, and I do myself, have the Remember my Password checkbox selected on the IE log in window too, which does not help either.

Guess we will need to look at moving over to FF "officially".

-marc

In Reply to Jess Holle:

The server requires the same authentication in either case.

The issue is all around how the browser and Java Plug-In share
credentials so you don't have to re-enter them -- or fails to do so as
the case may be.

In the case of Firefox (on Windows at least), this sharing just plain
works -- as you noted.

In the case of Internet Explorer, this will /not /work /unless/ you
check the "Remember my password" checkbox when logging into Windchill at
the browser level. This is due to an architectural shortcoming in
Internet Explorer according to the various folk I've asked (e.g. Sun
engineers).

I've had reports of cases where Internet Explorer and the Java Plug-In
fail to share the password even when this checkbox has been checked, but
have not managed to reproduce this, much less determine why this ever
occurs or how to fix this. This is a failing in Internet Explorer
and/or the Java Plug-In whose nature I've not been able to discover and
which is quite independent of Windchill as best I can tell.

Where possible the best solution is to simply to use Firefox (which is
faster too).

--
Jess Holle

@marc DeBower wrote:
>
> Hey Y'all:
>
> We are currently on Windchill 9.0 m060, and when we use Internet
> Explorer to access Windchill, whenever a java applet launches, we have
> to "login" or Authenticate to get the applet to run. I will attach a
> screenshot showing the login window.
>
> Funny thing is when you do the same thing using FireFox, no
> authentication window appears. MUCH nicer. Because of that, I don't
> think it is the server requiring us to authenticate.
>
> So: How to get rid of the authenticate login?
>
> -marc
>
> CAD / PLM Manager
>
jessh
12-Amethyst
(To:mdebower)

Marc DeBower wrote:
>
> Jess,
>
> Thanks for the info. We do experience the case where IE and Java
> fail to share the credentials. If you check the "Remember my
> password" box on the Java Authentication window, it will only remember
> it for that session. If you log out and back into Windchill you will
> have to re-enter the credentials every time.
>
Yeah -- that checkbox won't help much.
>
> Most of our users here have, and I do myself, have the Remember my
> Password checkbox selected on the IE log in window too, which does not
> help either.
>
I wish I knew why or how to resolve this case. It could be as simple as
some obscure MSIE setting, but so far no one has figured this out.
>
> Guess we will need to look at moving over to FF "officially".
>

ddemay
7-Bedrock
(To:mdebower)

Yeah there is no easy way to accomplish this. Not impossible though. In the
Java Control Panel, you have a Network Settings box. From there, you can
configure a proxy http server or have a direct connection. Since Apache is
configured to authenticate you could configure the applet URL's to not
authenticate the same way as everything else does. You could hook onto the
session tracking cookie (JSESSIONID usually) and IP Address to indicate the
person is a current valid user. An SSL connection also helps because you
can combine the IP Address, session cookie, and various SSL properties which
should be unique. Don't see many obviously trying this, just thought I'd
post the thought though.



Firefox is just smarter in sharing its connection with the plugins. IE does
it separately.



_____
jessh
12-Amethyst
(To:mdebower)

The *connection* is separate in each case. [All recent Java Plug-In's
use Java's own HTTP, JSSE, etc, libraries to form connections.]

The credentials, etc, are certainly shared more intelligently in
Firefox's case, though.

David DeMay wrote:
>
> Yeah there is no easy way to accomplish this. Not impossible though.
> In the Java Control Panel, you have a Network Settings box. From
> there, you can configure a proxy http server or have a direct
> connection. Since Apache is configured to authenticate you could
> configure the applet URL's to not authenticate the same way as
> everything else does. You could hook onto the session tracking cookie
> (JSESSIONID usually) and IP Address to indicate the person is a
> current valid user. An SSL connection also helps because you can
> combine the IP Address, session cookie, and various SSL properties
> which should be unique. Don't see many obviously trying this, just
> thought I'd post the thought though.
>
>
>
> Firefox is just smarter in sharing its connection with the plugins.
> IE does it separately.
>
>
>
ddemay
7-Bedrock
(To:mdebower)

*connection* is separate - So you saying what the JESSIONID and SSL Keys
would be different or what?



You can still configure apache to disallow authentication by url for the
applets and come up with some other way if you think about it long enough.
Point was not to hammer out the specifics but just to think it wasn't
completely impossible. Just might not be cost effective to figure out.





Was also thinking after sending the last response that once could have the
server side generate a base url reference for the applet to load where it
output into html
vmcdaniel
12-Amethyst
(To:mdebower)

Has anyone found a solution to this for IE 7?
jessh
12-Amethyst
(To:mdebower)

If you mean the dreaded double-authentication, then the solution is Java
6 Update 23 -- due one of these weeks...

jessh
12-Amethyst
(To:mdebower)

FYI, Java 6 Update 23 was released today.

tbusch
1-Visitor
(To:mdebower)

It's true! However, I don't see it on java.com yet. You can get the JDK and JRE here:
vmcdaniel
12-Amethyst
(To:mdebower)

Thanks for the heads up. I was reading they put it on Java.com usually a week after release.

-Vaughn

Hi,


i know that in 9.1 there is preference which can stop this double authentication, im not sure whether its applicable for 9.0

Set the Home#Utilities#PreferenceManager#PSE #Java Web Start preference to No in the Preference Manager.

DISCLAIMER: Author doesn't responsible for any unforeseen things happened due to implementing the suggested process

vmcdaniel
12-Amethyst
(To:mdebower)

Have any of you guys tried 1.6.23 yet?

I get a Windows error 'getCacheDescriptor' failed error preventing uploading of a new document. I was getting this with 1.6.22 as well.



In Reply to Thomas Busch:

Is there something additional that needs to be done? We've had 3 people so far try this and only 1 doesn't require authentication anymore.

It's true! However, I don't see it on java.com yet. You can get the JDK and JRE here: http://www.oracle.com/technetwork/java/javase/downloads/index-jsp-138363.html

-Thomas R. Busch
Sr. Software Developer
Stryker Instruments
(269) 323-7700 x4014
tom.busch@stryker.com<mailto:tom.busch@stryker.com>

vmcdaniel
12-Amethyst
(To:mdebower)

I attempted to clear all the Java cache, including docandsetting\username\app data\sun... I still get the error. I reverted to 1.6.16.

-Vaughn
jessh
12-Amethyst
(To:mdebower)

You must check the Java Plug-In's own "remember this password"-like
checkbox to resolve known cases where double authentication would
otherwise occur.

YoonKim
6-Contributor
(To:mdebower)

Jesse,

It seems that the double authentication would not occur in the same Windows session. If I logged out and back in the Windows or restart the computer, the Applet authentication reappears in the first HTML client page with Applet. Is this still a limitation for new Windows session?

Regards,
Peter (Yoon) Kim
281-483-0629

From: Jess Holle [

jessh
12-Amethyst
(To:mdebower)

Once you select the Java Plug-In's checkbox (in its dialog on the
initial double authentication), then the double-authentication should no
longer occur.

Of course if anything removes %USERPROFILE%\Application
Data\Sun\Java\Deployment\security\auth.dat (or the Windows 7 equivalent
of this location), then, yes, you'll have to reauthenticate -- as this
is the file that retains the login information so as to prevent
reauthentication.

On 12/13/2010 1:04 PM, Kim, Yoon S. (JSC-EA2)[Jacobs Technology] wrote:
>
> Jesse,
>
> It seems that the double authentication would not occur in the same
> Windows session. If I logged out and back in the Windows or restart
> the computer, the Applet authentication reappears in the first HTML
> client page with Applet. Is this still a limitation for new Windows
> session?
>
> Regards,
>
> Peter (Yoon) Kim
>
> 281-483-0629
>
> *From:*Jess Holle [
> checkbox to resolve known cases where double authentication would
> otherwise occur.
>
>

This has been a real issue for us so we're delighted it has finally been addressed...but we're not sure how it works. You still have to check the 'Remember password..' box but now it really does remember it. Our concern is that the login credentials (in our case windows login credentials) are being stored in that auth.dat. However, when the user changes their windows password it still seems to work ok. So, is that file actually storing the userid/password or is it somehow forcing the current credentials to be passed through?

jessh
12-Amethyst
(To:mdebower)

I am not 100% certain how this file works internally.

What has come to light, however, is that the file only applies to a
single Windows login session. If you logout and log back in, you'll
have to re-authenticate with Java the first time you use an applet --
checking its own checkbox to remember the password.

There is now a Java request for enhancement (#7006861) to make this data
apply indefinitely rather than having it remain valid only for the
duration of a Windows login.

We're not seeing that at all. Are you talking about release 23? We've installed this as pre-release and it retains the credentials forever...somehow.
jessh
12-Amethyst
(To:mdebower)

Hmm....

Someone from the forum and I are both seeing the auth.dat still existing
in the new Windows session -- but having to log in again in the new session.

I guess I obtained a "new Windows session" by rebooting. Perhaps it
does not impact logout/login the same way?

YoonKim
6-Contributor
(To:mdebower)

Whether it is a new Windows login or rebooting of computer, it requires me to re-authenticate with Java at the first time it uses an applet.

Regards,
Peter (Yoon) Kim
281-483-0629

I stand corrected. My tester was using http...where the problem never occurs. Using https we see the prompt suppressed for the current windows session only. After logging off windows the prompt does come back. That's really disappointing.

jessh
12-Amethyst
(To:mdebower)

Agreed -- I was rather shocked to see this behavior myself.

I have requested an enhancement from Oracle to allow this behavior to be
disabled via the Java Control panel -- #7006861 in the Java bug
database. [I assume /someone/ wants the current behavior -- it's quite
intentionally implemented that way apparently.]

--
Jess Holle

We are now getting the same error "getCacheDescriptor" error for 1.6.0_31 for upload of docs (because of applet issues). I hope that a ptc help desk call will find a resolution.


L Jett

In Reply to Vaughn McDaniel:



Have any of you guys tried 1.6.23 yet?


I get a Windows error 'getCacheDescriptor' failed error preventing uploading of a new document. I was getting this with 1.6.22 as well.


One solution is in the user Preference manager to change the upload mechanism to use the browser functionality. We haven’t tracked down the root cause for the ‘getCacheDescriptor’ error yet but the workaround is effective. You just lose the drag-and-drop upload capability.

Bob Lohbauer
Announcements


Top Tags