Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / September 2007

Tip: Looking for answers? Try searching our database.

Signed Applet Generates 403 Error

Thread view: 
Dr.Zoidberb - 04 Sep 2007 18:51 GMT
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 - 05 Sep 2007 04:01 GMT
...
>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>

Signature

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

Roedy Green - 05 Sep 2007 05:15 GMT
On Tue, 04 Sep 2007 17:51:40 -0000, "Dr.Zoidberb"
<chris.dufresne@gmail.com> wrote, quoted or indirectly quoted someone
who said :

>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

Signature

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

Roedy Green - 05 Sep 2007 06:01 GMT
On Wed, 05 Sep 2007 04:15:06 GMT, Roedy Green
<see_website@mindprod.com.invalid> wrote, quoted or indirectly quoted
someone who said :

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

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-a.s restriction on
unsigned Applets.
Signature

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

Dr.Zoidberb - 05 Sep 2007 14:57 GMT
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 - 05 Sep 2007 15:14 GMT
On Wed, 05 Sep 2007 13:57:27 -0000, "Dr.Zoidberb"
<chris.dufresne@gmail.com> wrote, quoted or indirectly quoted someone
who said :

> 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.
Signature

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

Roedy Green - 05 Sep 2007 15:15 GMT
On Wed, 05 Sep 2007 13:57:27 -0000, "Dr.Zoidberb"
<chris.dufresne@gmail.com> wrote, quoted or indirectly quoted someone
who said :

>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.

Signature

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

Dr.Zoidberb - 05 Sep 2007 15:34 GMT
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 - 05 Sep 2007 17:00 GMT
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 - 06 Sep 2007 04:44 GMT
On Wed, 05 Sep 2007 14:34:35 -0000, "Dr.Zoidberb"
<chris.dufresne@gmail.com> wrote, quoted or indirectly quoted someone
who said :

>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.
Signature

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

Roedy Green - 06 Sep 2007 04:57 GMT
On Wed, 05 Sep 2007 14:34:35 -0000, "Dr.Zoidberb"
<chris.dufresne@gmail.com> wrote, quoted or indirectly quoted someone
who said :

>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.
Signature

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com



Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.