How to communicate from HTML page with an IP which is not the web-server?

[DavidNorep]

I want that when the visitor in my website clicks on a particular
button - text will be sent to a certain port at a certain IP, which is
not the web server.

Is Java the only technology to do this (except Microsoft technologies,
which I am not familiar with)?

If yes - must I have an applet, even though the Java code does not
need a GUI? I assume that the applet may be invisible.

I understand that the applet will face security obstacles in both
sides, and that it should be signed. Does it cost money to have a
signed applet?

 

[Daniel Dyer]

I want that when the visitor in my website clicks on a particular
button - text will be sent to a certain port at a certain IP, which is
not the web server.

Is Java the only technology to do this (except Microsoft technologies,
which I am not familiar with)?

You can do it with Flash, in which case it's probably easiest if the
button itself is the Flash movie. Flash is more likely to be installed on
the average user's PC than Java.

Better still, depending on your constraints, you might be able to do it
the AJAX way with JavaScript and XMLHttpRequest (I think the server that
you connect to would have to speak HTTP).

If yes - must I have an applet, even though the Java code does not
need a GUI? I assume that the applet may be invisible.

I understand that the applet will face security obstacles in both
sides, and that it should be signed. Does it cost money to have a
signed applet?

You can create a self-signed applet for free. The problem is that the
browser will put up a warning and a prompt because it can't validate that
you are who you say you are.

If you buy a certificate from a third party, they will be vouching for you
because you will have had to have identified yourself to them. The
browser implicitly trusts the certificate issuers (because their root
certificates are already installed in the browser), and won't need to
prompt the user.

Dan.

 

[DavidNorep]

You can do it with Flash, in which case it's probably easiest if the
button itself is the Flash movie. Flash is more likely to be installed on
the average user's PC than Java.

I do not know Flash, so this is not an option for me.

Better still, depending on your constraints, you might be able to do it
the AJAX way with JavaScript and XMLHttpRequest (I think the server that
you connect to would have to speak HTTP).

I thought that with HTTP I can communicate only with the server from
which the HTML page was downloaded. Am I wrong?

I am ready to study Javascript & AJAX. Can I use the XMLHttpRequest
object to send text to a specific port in another computer?

You can create a self-signed applet for free. The problem is that the
browser will put up a warning and a prompt because it can't validate that
you are who you say you are.

If you buy a certificate from a third party, they will be vouching for you
because you will have had to have identified yourself to them. The
browser implicitly trusts the certificate issuers (because their root
certificates are already installed in the browser), and won't need to
prompt the user.

Do you know the price of a third party certificate?

 

[Daniel Dyer]

I do not know Flash, so this is not an option for me.

I thought that with HTTP I can communicate only with the server from
which the HTML page was downloaded. Am I wrong?

I don't know. Probably best to ask on comp.lang.javascript. There may
well be a similar restriction as with applets. I believe that there is
such a thing as "signed JavaScript".

Do you know the price of a third party certificate?

No, but Thawte and Verisign do. Thawte also have a "personal e-mail
certificate" scheme which gives you a free, properly authenticated
certificate for use with e-mails. This can be used to sign code as well.
I can't remember how it differs from the regular pay-for certificate.

Dan.

 

[Andrew Thompson]

You can create a self-signed applet for free. The problem is that the
browser will put up a warning and a prompt

As an end user, I see that as a benefit.

...because it can't validate that
you are who you say you are.

No. It will put up a security warning even if the
digital certificate has been verified by Thawte or
Verisign.

The only difference is in the style of the dialog.
The dialog will note that the self-signed
certificate 'cannot be verified by a trusted
authority' or some such, but *no* certificate
gives an applet automatic (unchallenged)
unrestricted access to the local system.

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

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

 

[Daniel Dyer]

No. It will put up a security warning even if the
digital certificate has been verified by Thawte or
Verisign.

The only difference is in the style of the dialog.
The dialog will note that the self-signed
certificate 'cannot be verified by a trusted
authority' or some such, but *no* certificate
gives an applet automatic (unchallenged)
unrestricted access to the local system.

Yes, I was thinking of the way server certificates work. They don't
prompt you if everything is OK. It's been a while since I signed an
applet.

Dan.

 

[DavidNorep]

I am still not sure if I must have an applet, even though the Java
code does not
need a GUI? I assume that the applet may be invisible.

 

[Dag Sunde]

I am still not sure if I must have an applet, even though the Java
code does not
need a GUI? I assume that the applet may be invisible.

As Daniel say, you can do it with AJAX:
* You send an XMLHTTP call to the server.
* A server-script do the connection to the external port you
want (Servers don't have the cross-domain security restriction).
* When the server script get the response from your external call,
it returns HTML or XML to your JavaScript in your original page.

If you want to do it With an Applet, the Applet must be signed
(either with a self-signed or commercial certificate) to be able
to connect to anything else than the server the Applet originated
from.

The only difference between a self-signed and a commercial
certificate is the warning message that appears when the system
ask the user for permission to run this signed Applet.
Priviledges _will_ be granted to both kinds if the user say so.

The Applet may be invisible or have a GUI. The visibility of the
Applet does not influence its behaviour.

Just one point to be aware of:
If you call the (signed) Applet method that do the priviledged
task from a Javascript statement on the page, the method will
fail with a security exception. The JRE will notice that the call
came from a non-privilegded system (in this case JavaScript).

To walk around this, call a method in the Applet that only set
a flag, indicating that you want the method executed, and make
your Applet poll for this flag regularly.

 

[DavidNorep]

As Daniel say, you can do it with AJAX:

* You send an XMLHTTP call to the server.
* A server-script do the connection to the external port you
want (Servers don't have the cross-domain security restriction).
* When the server script get the response from your external call,
it returns HTML or XML to your JavaScript in your original page.

Maybe I was not clear enough - I do not want that the communication
will pass through the HTTP server, but directly between the two home
computers. So I assume that XMLHTTPRequest is not a solution.

If you want to do it With an Applet, ...

So I want to do this in Java. I understand that you say that doing it
in Java means doing it with an applet, which may be invisible.

Just one point to be aware of:
If you call the (signed) Applet method that do the priviledged
task from a Javascript statement on the page, the method will
fail with a security exception. The JRE will notice that the call
came from a non-privilegded system (in this case JavaScript).

To walk around this, call a method in the Applet that only set
a flag, indicating that you want the method executed, and make
your Applet poll for this flag regularly.

I thought that the HTML page is loaded and then the init() method of
the applet is invoked. Can you invoke from Javascript any public
method in the applet?

Thanks.

 

[Dag Sunde]

Maybe I was not clear enough - I do not want that the communication
will pass through the HTTP server, but directly between the two home
computers. So I assume that XMLHTTPRequest is not a solution.

So I want to do this in Java. I understand that you say that doing it
in Java means doing it with an applet, which may be invisible.

I thought that the HTML page is loaded and then the init() method of
the applet is invoked. Can you invoke from Javascript any public
method in the applet?

Yes, You can...

Something like this:

if ( document.getElementById('yourAppletId') ) {
var myApplet = document.getElementById('yourAppletId');
myApplet.yourmethod();
}

 

[Richard Maher]

Hi David,

I want that when the visitor in my website clicks on a particular
button - text will be sent to a certain port at a certain IP, which is
not the web server.

Is Java the only technology to do this (except Microsoft technologies,
which I am not familiar with)?

If yes - must I have an applet, even though the Java code does not
need a GUI? I assume that the applet may be invisible.

I understand that the applet will face security obstacles in both
sides, and that it should be signed. Does it cost money to have a
signed applet?

Not completely sure what everyone else is going on about in the thread (or
I've probably completely misunderstood your question) but my answer to you
is "The Java option works, and is straight-forward to implement".

If your Applet connects back to the same server as the codebase (as
specified in the <object> tag) then is does not need to be signed. Just
stick the JAR file on whatever server you want to connect back to. If it's
run-time determination of the target IP address that you're after, then
you're on your own

So as not to interfere with the format of the web-page that is hosting *my*
Applet, I pop-up seperate modal dialog boxes when I wish to interact with
the User. (Username/Password and then a Welcome panel) For security, I keep
the network connection up only while the hosting page (this includes all
sub-pages in sub-Frames) is displayed.

With the Microsoft/Eolas dispute (some?) Applets on IE result in the "Click
to activate and use this control" message, but I think what SUN refers to as
blind-applets (what we both wish to use) do not suffer from this
restriction. (And there are several published solutions/work-arounds for
this anyway)

Now, if whatever it is your hosting, on this "certain port and certain IP"
is not a web server then I have no idea why anyone would recommend going the
AJAX route. When will people start thinking outside the box on this one? If
you want to send HTML pages with embedded images/objects then HTTP is
absolutely the mut's nuts! As an application-middleware protocol it is a
complete pile of pooh! I suppose the sad fact is that "a.n.other
mono-lingual Web-Server" is the *only* application-server available on most
architectures :-(

Cheers Richard Maher

PS. I love the Java Applet approach primarily 'cos of it's cross-platform
appeal and 'cos you don't have to have things signed to achieve my aims, but
I am also interest in the .NET solution. Can anyone point to good web-site
for converting a Java Applet into a .NET compatible, browser resident,
ActiveX Socket calling "thingy"? In other words, I want to do a Socket and
Connect back to a server using whatever Microsoft's solution is; can someone
please point me to an example? (I know it's the wrong group but I'm sure
someone here must know)

 

[Andrew Thompson]

Richard Maher wrote:
..

...
If your Applet connects back to the same server as the codebase ...

This applet needs to communicate with a /foreign/ server.

 

[Luc The Perverse]

Richard Maher wrote:
.

This applet needs to communicate with a /foreign/ server.

I believe this is deliberately disallowed for security purposes.

You might have better luck with JNLP.

 

[Andrew Thompson]

I believe this is deliberately disallowed for security purposes.

Sandoxed applet - yes. Signed and trusted applet - no.

A trusted applet can do almost anything short of System.exit()
(which is something that does not occur to most people as
being disallowed in the first place).

You might have better luck with JNLP.

Huhh.. Cannot quite believe (looking back over this thread),
not only was that the first time web start was mentioned,
but that *I* wasn't the first to mention it. ;-)

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

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

 

[Richard Maher]

Hi Andrew,

This applet needs to communicate with a /foreign/ server.

I re-read this thread twice and cannot see how you attribute this
requirement to the OP, or your definition of /foreign/.

Cheers Richard Maher

 

[Richard Maher]

Hi Luc,

I believe this is deliberately disallowed for security purposes.

*What* do you believe is deliberately disallowed for security purposes?

Cheers Richard Maher

 

[Sherm Pendley]

Hi Andrew,

I re-read this thread twice and cannot see how you attribute this
requirement to the OP

The subject says "an IP which is not the web-server" - looks pretty clear
to me...

sherm--

 

[Sherm Pendley]

*What* do you believe is deliberately disallowed for security purposes?

Communicating with a foreign server. See what happens when you post upside-
down? You can even confuse yourself that way.

sherm--

 

[Richard Maher]

Hi Sherm,

The subject says "an IP which is not the web-server" - looks pretty clear
to me...

So is that *your* definition of a foreign server? Andrew's? or did the OP
discuss this on some post that my newsreader can't see?

"codebase" has absolutely bugger-all to do with "web-server"! If any of you
would try to string entire sentences together then maybe someone might be
able to pin you down on whatever it is you're claiming to be a restriction.

*I* say "Without the need to be signed, your Applet can connect to any
server, and certainly a server other than the web server, as long as that is
where the codebase parameter says the Archive (or class files) live". And it
certainly wasn't explicitly clear to me that the OP's requirements could not
be satisfied with this scenario.

So, once again, please tell me *what* has become "pretty clear" to you as a
result of "an IP which is not the web-server"? Are you aware that you can
also use FTP as a protocol for your Applets? (And I for one am currently
developing a lightweight Applet uploader that doesn't have the normal
bloated elephant carcass of a normal http web-server.)

Cheers Richard Maher

 

[Sherm Pendley]

Upside down. Obviously with intent to obfuscate.

So, once again, please tell me *what* has become "pretty clear" to you

That you're being absurdly pedantic. Yeah, sure you *can* serve an applet
from an FTP server - do you seriously think the OP is actually doing so?

Grow up. Your pedantry impresses no one.

sherm--