Please, can anyone tell me how can i get the size in java code of the applet (jar file). It is possible? Or can i get a unique applet propertie that i can use to identify a particulary applet?
Thanks a lot for your time.
Thanks a lot for your replies!
Well, what i am looking for, is something that i can use or get in applet to use like a piece of a unique key. My boss told me for use the size of my jar, but, like you said, it is only possible with a http request... So now, i want something (a property or something else) that a can get and use in the applet and it is not explicit in code...
I think i had understood your solution, but, to pass the UUID like a param tag to the applet, i need to have de UUID stored in my code, it's right? Well, i want something that i can obtain in the applet without any http request and dont want to store the UUID in the applet or in the jsp page (where i call the applet).
As an aside, why no HTTP? The browser uses HTTP anyway to retrieve the applet; why would one more request coming from the applet make a difference?
Well, i'd like to have something i can get in runtime, do you understand? Something that i can get in runtime and send it to the server. The inconvenience of an http request to the server to return the size of my jar increments a lot of possibilities to fail, like permissions to access to my jar file; one more connection only to do that... I dont know if i am thinking right, but ok, thank a lot for your replies....
i'd like to have something i can get in runtime
Everything we talked would happen dynamically at runtime; I'm not sure what other possibilities you see.
Something that i can get in runtime and send it to the server.
That would be possible either with an applet-generated UUID, or with a server-generated one that gets sent to the applet via a <param> tag.
The inconvenience of an http request to the server to return the size of my jar increments a lot of possibilities to fail, like permissions to access to my jar file; one more connection only to do that
The jar file size wasn't part of what I suggested, but in order for the applet to work at all, the jar must have proper permissions to be read anyway. So that's not a concern.
As to inconvenience, it's just 10 lines of code, and a single request - what's inconvenient about that?
Plus, you will need to perform an HTTP request anyway to send the key -whatever that ends up being- to the server anyway, don't you?
When a request comes in for the page with the applet, the server generates a unique key and stores it in a know place/a file that that applet can read with an HTTP reguest. When the applet starts, it does an HTTP Get for the file with the key and now it has the key that it can send back to the server. At some point the server deletes the key. The weak point is the name of the file that the applet does a GET for. The file will only exist while the applet is "active" in the browser. When the applet dies(??) the file is erased.
The filename could also be generated and passed to the applet via a <PARAM tag.
How secure does it need to be?
Thanks for your attention to my case. Well... When you tell me:
"That would be possible either with an applet-generated UUID, or with a server-generated one that gets sent to the applet via a <param> tag."
I suppose that i dont explain all that you must to know. When i want to use something to create my key in runtime, it must be something that i can get in runtime, and do not have the key stored in the applet. So, i need to use something else, and the idea is to use de applet size (for example), and in server a store in a file the size of all my jars, by authorized client. So, when we receive a message from a web server of our client, i will receive a key and a client id. In our server i create de key, with the fields that is suppose to be, and i will get the size of this client jar file saved in a file (for example, or database). If the keys match so the message is valid.
It is more clear now?
It is more clear now?
Actually, no. Now you don't mention applets any more at all, but client web servers instead. How do those fit into the picture? I thought the web server (and the applet it serves) where those of your company.
Since you once again mention "runtime" and "stored in the applet", I repeat: Eveything I'm proposing happens at runtime, and -if I understand the problem correctly, which is not a given- the applet must store the key at least temporarily - otherwise, how could it send the key to the server if it doesn't have it?
Sorry but.. I dont speak very well english, its probably one reason of the dificulty to you understand me.
Well, the applet is always in the scenario... Maybe i forget to tell that the applet is in a web server of our client, and this one will send messages to our servlet...
Yes, of course a need to set a variable with my key to send the value from the applet to our server, but i dont want the key stored in the applet, i want to calculate that in runtime and send it.
I hope that you understand me!
In that case the size of the jar file is an option because that can be known by your server. (UUIDs would in fact not be a solution, because they can't be known by your server.)
The applet will need to be signed in order to access your company's server.