Signed Applet Generates 403 Error

[Dr.Zoidberb]

Hi all,

I have a Java applet that needs to read a couple files from the server
it originates from. So I singed the jar file with keytool/jarsigner
process and that worked until I updated my Java SDK. The previous
version of jarsigner didn't have a -version option, the new one
returns 0.92. When I use the old version the jar is loaded and then
user is prompted to "trust" or "run" the applet. When I use the new
version there is no such prompt and I get the following error:

java.io.IOException: Server returned HTTP response code: 403 for URL:
http://my.url.net/test/myapplet.jar
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:
1152)
....

It still works with the old jarsigner but it's kind of a hassle to
have to carry that executable forward, so I'm wondering if anyone else
has had this problem and knows how to fix it.

 

[Andrew Thompson]

Dr.Zoidberb wrote:
...

I have a Java applet that needs to read a couple files from the server
it originates from.

Sure. I have a couple of my own, most of them
'unsigned' if they access the home server.

..So I singed the jar file with keytool/jarsigner
process ..
Why?

..and that worked until I updated my Java SDK. ...
java.io.IOException: Server returned HTTP response code: 403 for URL:
http://my.url.net/test/myapplet.jar

Jar signing is not the problem here. The *server*
is saying 'no'.
<http://www.checkupdown.com/status/E403.html>

--
Andrew Thompson
http://www.athompson.info/andrew/

Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.aspx/java-general/200709/1

 

[Roedy Green]

java.io.IOException: Server returned HTTP response code: 403 for URL:
http://my.url.net/test/myapplet.jar
at

that is a:
403 HTTP_FORBIDDEN Forbidden


It would be nice if you had used WireShark or other sniffer
http://mindprod.com/jgloss/wireshark.html

to verify it was the fetch of the jar that was forbidden, and that the
bitching happened before the jar were sent, not as it was unpacked.

So who is blocking your jar? IE loves to meddle. Get rid of it and
try another browser. See http://mindprod.com/jgloss/browser.html

 

[Roedy Green]

If the problem is coming after the jar has loaded you must read your
data files on the server from http://my.url.net/test/ or a
subdirectory of it. This is a major pain-in-the-ass restriction on
unsigned Applets.

 

[Dr.Zoidberb]

So here's the deal.

I was able to get rid of that particular exception, by adding a few
more arguments to the jarsigner. However the data files are still not
being read from the server and no exception is being thrown. I'm
thinking this has something to do with the new security features of
the newest version of Java, because according to Sun File I/O is no
longer allowed in applets. I am making a URLConnection back to the
originating server to get the data files, I don't know if that counts
as File I/O or not. I'd really rather not have to rewrite the applet
to make a connection to an application (that I'd also have to write)
on the server that just reads the files and sends the information.

What's really annoying is like I said if I sign the same exact code
with the old version of jarsigner everything works. New version the
jar loads but the data files do not.

 

[Roedy Green]

because according to Sun File I/O is no
longer allowed in applets.

File i/o to the local disk has never been allowed in unsigned Applets.
I/O to a server other than the one from which the jar was loaded has
also always been blocked in unsigned Applets. In fact the restriction
is even tighter. You must load from that same directory tree.

Perhaps you were fooled by running applets locally as applications
where the restrictions are turne off.

 

[Roedy Green]

I am making a URLConnection back to the
originating server to get the data files, I don't know if that counts
as File I/O or not

See http://mindprod.com/jgloss/applet.html
and http://mindprod.com/jgloss/signedapplets.html
for the rules. They are more complicated that your wildest dreams.

 

[Dr.Zoidberb]

I'm aware of the restrictions, which is why I signed my applet. I am
retrieving data files from the same directory on the server as the
applet lives.

I load the applet http://my.url.net/test/myapplet.jar

it loads and then is supposed to load data files using a URLConnection

http://my.url.net/test/data1.dat
http://my.url.net/test/data2.dat

This works just fine in every browser if I sign it with the old
version. But if I use the new jarsigner it fails. That to me says that
something changed in the jarsigner security policy.

 

[Dr.Zoidberb]

Alright, I tracked down the problem. It basically required me to put
debug statements everywhere, stepping through the debugger would have
done no good since appletviewer doesn't have the same security
restrictions as a browser.

So the problem turned out to be one statement:

HttpURLConnection.setFollowRedirects(false);

Which was permitted in previous versions of the JDK/JRE but is no
longer allowed. Turns out I didn't need the line anyways. Thanks to
everyone who tried to help me solve this.

 

[Roedy Green]

This works just fine in every browser if I sign it with the old
version. But if I use the new jarsigner it fails.

Do you have two different JDK's installed? Perhaps some wires are
getting crossed with part of one and part of another.

 

[Roedy Green]

This works just fine in every browser if I sign it with the old
version. But if I use the new jarsigner it fails. That to me says that
something changed in the jarsigner security policy.

Have you posted this on the pubic web? If so I can run you Applet to
see the precise behaviour you are complaining about. If I don't see
it, it may be something screwy in your browser.

I still don't know exactly what sort of behaviour you are talking
about.