Applet security restrictions and aliased domains

[douggunnoe]

I recently changed web hosts. My former host did not have support for
Java. As a work around, I created an applet that opened a connection
to a cgi script. The script dynamically created an html file and
returned the address of the file back to the applet, which opened the
new file.

When I moved everything over to the new host, I made sure that the
paths and addresses referenced in the script and applet remained the
same so that I would not have to change anything.

However, I am getting an IO exception.

My new hosting account is set up with one primary domain, and several
aliased domains, such that the aliased domains are each folders under
the primary domain account. When someone types in www.my_aliased_domain.com,
I assume it is the A records or cname records or what have you that
point to the subfolder primary_domain/my_aliased_domain.

My questions are (assuming the file paths and addresses are all
correct) :

1.Since Java applets can only communicate with the host from whence
they came, would these security restrictions block a connection to an
aliased domain?

2.And if so, should I get an IO exception or some other exception?

3.Should I try instead to connect to www.primary_domain.com/aliased_domain_folder/somefile.cgi
instead of www.aliased_domain .com/somefile.cgi?

 

[Andrew Thompson]

...As a work around, I created an applet ..

That often turns into 'more work'.

..that opened a connection
to a cgi script. The script dynamically created an html file and
returned the address of the file back to the applet,

How? Was the paramater written into the HTML
as an applet param? But..

..which opened the
new file.

When I moved everything over to the new host, I made sure that the
paths and addresses referenced in the script and applet remained the
same so that I would not have to change anything.
*

However, I am getting an IO exception.
*

My new hosting account is set up with one primary domain, and several
aliased domains, such that the aliased domains are each folders under
the primary domain account. When someone types in www.my_aliased_domain.com,

..these things are very much easier to investigate when
you can provide an actual URL of the actual applet
(or a test case facsimile) failing right in *my* browser,
then I would not have had to ask the questions above,
nor the two I might have asked, denoted by '*' that I
simply could not be bothered asking, nore any that
cropped up from the latter part of your message
(trimmed).

So. Have you got an URL for us?

 

[douggunnoe]

I recently changed web hosts. My former host did not have support for
Java. As a work around, I created an applet that opened a connection
to a cgi script. The script dynamically created an html file and
returned the address of the file back to the applet, which opened the
new file.

When I moved everything over to the new host, I made sure that the
paths and addresses referenced in the script and applet remained the
same so that I would not have to change anything.

However, I am getting an IO exception.

My new hosting account is set up with one primary domain, and several
aliased domains, such that the aliased domains are each folders under
the primary domain account. When someone types inwww.my_aliased_domain.com,
I assume it is the A records or cname records or what have you that
point to the subfolder primary_domain/my_aliased_domain.

My questions are (assuming the file paths and addresses are all
correct) :

1.Since Java applets can only communicate with the host from whence
they came, would these security restrictions block a connection to an
aliased domain?

2.And if so, should I get an IO exception or some other exception?

3.Should I try instead to connect towww.primary_domain.com/aliased_domain_folder/somefile.cgi
instead ofwww.aliased_domain.com/somefile.cgi?

The answer, I discovered, is that a domain alias is not a problem for
the applet's security safeguards.

I also discovered that when one changes hosts, one should not panic
when something goes wrong and assume there is some exotic problem.

The mundane is the most likely culprit. :|

 

[douggunnoe]

(e-mail address removed) wrote:

.


That often turns into 'more work'.


How? Was the paramater written into the HTML
as an applet param? But..



.these things are very much easier to investigate when
you can provide an actual URL of the actual applet
(or a test case facsimile) failing right in *my* browser,
then I would not have had to ask the questions above,
nor the two I might have asked, denoted by '*' that I
simply could not be bothered asking, nore any that
cropped up from the latter part of your message
(trimmed).

So. Have you got an URL for us?

"That often turns into 'more work'."

Tis true Andrew.

The applet is at

http://www.knowcasinos.com/sims/bjcalc/bja.html

But it works now, so...

In my OP I said "assuming the file paths and addresses are all
correct". Assuming is bad.