Sinking in the JAVA quicksandbox

[S J Rulison]

A few days ago I posted a message regarding a problem I'm having with
establishing a socket connection between an applet and a server to
this group. I have recapped the crux of the situation below. After
conferring with some helpful individuals on this group and doing some
additional research on my own, I now believe that this has something
to do with the java SecurityManager. While I have been doing a lot of
research in this area I have yet to find what program, server /
applet, needs to be modified and which methods need to be overridden
in the SecurityManager. Some code samples in this area would really
be helpful. Any help would be greatly appreciated.

Thank you.

Sincerely,
Steve Rulison

PREVIUOUS POSTING:
I have a JAVA Applet and Server application written in version
1.4.2_05 running on a Windows XP platform. I use the socket (String
host, int port) class on the applet side to establish a connection
with the Server and the ServerSocket (int port) class on the server
side. When I run both the Server and Applet on the same workstation,
everything works fine but if I move the Server portion onto another
machine, I am unable to establish a connection with that Server (see
exceptions listed below). I've tried using the IP address of the
server, the name of the server, and the fully qualified name (server
name. domain name). All of these conventions work fine when both the
applet and the server are run from the same machine but as soon as I
separate the two programs to two different computers, it stops
working.
I even went so far as to purposely feed the server a factitious IP
Address and machine ID when I was running both processes from the same
machine to see if it would run anyway. It did not, which tells me
that the server application is doing something with that parameter
when it establishes a connection.

EXCEPTIONS:
java.security.AccessControlException: access denied
(java.net.SocketPermission 10.44.1.250 resolve)
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkConnect(Unknown Source)
at java.net.InetAddress.getAllByName0(Unknown Source)
at java.net.InetAddress.getAllByName0(Unknown Source)
at java.net.InetAddress.getAllByName(Unknown Source)
at java.net.InetAddress.getByName(Unknown Source)
at java.net.InetSocketAddress.<init>(Unknown Source)
at java.net.Socket.<init>(Unknown Source)
at PTABLookup.createSocket(PTABLookup.java:110)
at PTABLookup.init(PTABLookup.java:87)
at sun.applet.AppletPanel.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

 

[Andrew Thompson]

A few days ago I posted a message ..

Yes, I saw it..
<http://google.com/[email protected]>

Why did you start a new thread?

While we are on the subject, why did you give the new thread a
silly name of "Sinking in the JAVA quicksandbox" (It's 'Java' BTW),
rather than something useful and descriptive like 'Applet
socket SecurityException'?

And further, how did you go with the advice I gave you late in the thread..

..I have recapped the crux of the situation below.

Can you perhaps respond to my suggestions before you go
calling for further help? It might save everybody time,
and you from slipping beneath the quicksand.. ;-)

 

[Tim Jowers]

Yes, I saw it..
<http://google.com/[email protected]>

Why did you start a new thread?

While we are on the subject, why did you give the new thread a
silly name of "Sinking in the JAVA quicksandbox" (It's 'Java' BTW),
rather than something useful and descriptive like 'Applet
socket SecurityException'?

And further, how did you go with the advice I gave you late in the thread..


Can you perhaps respond to my suggestions before you go
calling for further help? It might save everybody time,
and you from slipping beneath the quicksand.. ;-)

RJ,

Andrew is correct. One the hot features of Java Applets was/is
sandboxing which means you cannot generally access the network or
filesystem from an applet. You can only access the server from which
you came to the browser and can access a scratch space on the disk
(sandbox). (This is why it works on your box but not when you try to
hit the server remotely.) Gotta sign that applet.

You can do it for free but then your user has to accept the applet.

TimJowers

 

[S J Rulison]

Yes, I saw it..
<http://google.com/[email protected]>

Why did you start a new thread?

While we are on the subject, why did you give the new thread a
silly name of "Sinking in the JAVA quicksandbox" (It's 'Java' BTW),
rather than something useful and descriptive like 'Applet
socket SecurityException'?

And further, how did you go with the advice I gave you late in the thread..


Can you perhaps respond to my suggestions before you go
calling for further help? It might save everybody time,
and you from slipping beneath the quicksand.. ;-)

1. I started a new thread because, a lot had changed since the first
thread and I wanted to narrow down the scope of the problem to a more
specific area that's directly on point. In addition, if you had bother
to read the entire, thread you would have noticed that the last post
suggested that I start a new thread.

2. The title may be a bit on the silly side but I didn't think that
some jerk would get all bent out of shape about it and it does sort of
describe my situation.

3. I tried adjusting the security settings on the web browser DAH, it
didn't help.

4. I checked into signing the applet and I guess if I have to go there
I will but that really seems like its overkill for solving this
problem.

5. If you read my post in the new thread, you would see that I am
interested in learning how to override the methods in the
SecurityManager and which programs APPLET or APPLICATION should be
modified.

6. . I am not really interested downloading java webstart and trying
to learn how that works.

If you want to help I would really appreciate it but if all I'm going
to get is a #@%ing attitude from you, please save it for somebody
else. I've spent a lot of time working on this and I don't need to
see this crap staring back at me at the end of the day!

 

[Andrew Thompson]

2. The title may be a bit on the silly side but I didn't think that
some jerk would get all bent out of shape about it and it does sort of
describe my situation.

(chuckle) let's hope not!

3. I tried adjusting the security settings on the web browser DAH,

DAH? What langaunge is that?

..it
didn't help.

That is not very specific.

Did you fail to figure how to adjust the settings?
Were the settings adjusted but had no effect?

4. I checked into signing the applet and I guess if I have to go there
I will but that really seems like its overkill for solving this
problem.

Breaking an applet out of the security sandbox is no straightforward
matter, probably for good reason. Get used to that thought.

5. If you read my post in the new thread, you would see that I am
interested in learning how to override the methods in the
SecurityManager and which programs APPLET or APPLICATION should be
modified.

OoooK. To what end? It will do you no good for getting
this applet talking to it's socket. You won't be able to
make this work on a client machine by overriding security
managers, that is something suited only to development,
or perhaps a stand-alone (application) development tool.

6. . I am not really interested downloading java webstart and trying
to learn how that works.

Seems you're f*cked then, no?

If you want to help I would really appreciate it but if all I'm going
to get is a #@%ing attitude from you,

...I haven't given you any yet. You'll be in no doubt
about it when I do.

..please save it for somebody
else. I've spent a lot of time working on this and I don't need to
see this crap staring back at me at the end of the day!

You *POOOooooor* thing. :-/

I suppose I better not stress your pretty little head further.

Good luck with that.

 

[Filip Larsen]

S J Rulison wrote

A few days ago I posted a message regarding a problem I'm having with
establishing a socket connection between an applet and a server to
this group. I have recapped the crux of the situation below. After
conferring with some helpful individuals on this group and doing some
additional research on my own, I now believe that this has something
to do with the java SecurityManager. While I have been doing a lot of
research in this area I have yet to find what program, server /
applet, needs to be modified and which methods need to be overridden
in the SecurityManager.

You seem to be disregarding the comments you got the first time around
and it looks like you are heading down a dead end.

The default installed SecurityManager for applet enforce a certain
security policy on behalf of the user to guard against malicious
applets. Modifying the SecurityManager will not get you anywhere.

If your applet get a security exception when it try to connect to a host
this means that the SecurityManager believes that this host is different
that the host from where the applet was loaded. If you want to connect
to this host you can use applet.getCodeBase().getHost() to get the
originating hostname. If this host is not what you think it is, then
maybe the applet is loaded from a different place that you think. You
host must run a web server from which the browser plugin can load the
applet.

If you really want to connect to a different host, then you must either
sign the applet with permissions that include (or implies) that you can
connect to that host, or you must get the user to grant such permission
(using bin/policytool) for you. There is really no other way around if
you want it to run as an applet.



Regards,

 

[Filip Larsen]

S J Rulison wrote

A few days ago I posted a message regarding a problem I'm having with
establishing a socket connection between an applet and a server to
this group. I have recapped the crux of the situation below. After
conferring with some helpful individuals on this group and doing some
additional research on my own, I now believe that this has something
to do with the java SecurityManager. While I have been doing a lot of
research in this area I have yet to find what program, server /
applet, needs to be modified and which methods need to be overridden
in the SecurityManager.

You seem to be disregarding the comments you got the first time around
and it looks like you are heading down a dead end.

The default installed SecurityManager for applet enforce a certain
security policy on behalf of the user to guard against malicious
applets. Modifying the SecurityManager will not get you anywhere.

If your applet get a security exception when it try to connect to a host
this means that the SecurityManager believes that this host is different
that the host from where the applet was loaded. If you want to connect
to this host you can use applet.getCodeBase().getHost() to get the
originating hostname. If this host is not what you think it is, then
maybe the applet is loaded from a different place that you think. You
host must run a web server from which the browser plugin can load the
applet.

If you really want to connect to a different host, then you must either
sign the applet with permissions that include (or implies) that you can
connect to that host, or you must get the user to grant such permission
(using bin/policytool) for you. There is really no other way around if
you want it to run as an applet.



Regards,

 

[S J Rulison]

RJ,

Andrew is correct. One the hot features of Java Applets was/is
sandboxing which means you cannot generally access the network or
filesystem from an applet. You can only access the server from which
you came to the browser and can access a scratch space on the disk
(sandbox). (This is why it works on your box but not when you try to
hit the server remotely.) Gotta sign that applet.

You can do it for free but then your user has to accept the applet.

TimJowers

Okay Tim I'll look into it. Guess I'm going to have to hit Barns &
Nobel tonight. Thanks for you help.