securing code on a webserver

[server_crash]

Ok, it's like this:

I can't have any class file downloaded from my website, for personal reasons.

A user could view the applet like this:

applet.html

then change the url easily to this:

applet.class

and have my program that easy.

Is there way I can secure this somehow???

[jwenting]

no. Applets are clientside code, the classfiles will always have to be downloaded to the client.
In fact, your user won't even have to do that, he can just pull the classfile from your browsercache.
You can do things to prevent the classfile from being used from any other location though.
Think about applet restrictions and it becomes obvious :)

Still doesn't stop someone from decompiling your applet and changing it, but what are the chances of that (iow, how many people will want to go to the trouble? What makes your code so brilliant that people will actually want to decompile and crack it?).

If you don't want that, you'll have to use servlets/JSP and send over the generated html.

[server_crash]

What makes your code so brilliant that people will actually want to decompile and crack it?).

It's not that. This program has great value to ME. I will be selling it, and if I can ever figure this out, I can show it to you and you will understand a bit better. Some fellow is selling the same thing(not quit as good as mine) for 175$, and if I'm going to sell it, I don't want people just to get it for free. Someone told me this:

"you can use the applets getDocumentBase() method to see if a user downloaded the class file....But what then? Is there something you can do to them if they download it? Is that correct about getDocumentBase()?

[freesoft_2000]

Hi everyone,

The best thing you can do is try to obfuscate your code but then again there are some people that can actually still make sense of obfuscated code.

You could do encryption but people can still get into your code - (I am not going to describe how to get into encrpted code in java here or to anyone as someone could use that information for misuse.)

See even people like Microsoft which most probably have the best encrypted code still get their codes broken.

Don't worry if your program is as good as you say it is then trust me even if charge $200 you will still have buyers. One thing about people they always have nose for quality.

Don't mind me if i ask this but what is your program about. What does it do and what is it about. It seems interesting

Richard West

[server_crash]

Thanks for the reply Richard. I'll be posting a link as soon as I can get something fixed. It's very nice, but you won't understand untill you see it!

It's like J said, there's really nothing I can do, and it's a lot of trouble to decompile and stuff like that, so I've come up with a new solution:

getDocumentBase() method of the applet class allows you to see where it's placed. So, I was thinking that I could check to make sure it's running from my website, otherwise, it would not run. That still leaves the option of decompilation, but I think that's just a measure that I'll have to not worry about.

I will show it to you guys, but it will be about a day or two.

[jwenting]

getDocumentBase() is one thing, but I was really thinking of something else (maybe in combination with that).
Let your applet contact your server (which of course is the only one it's allowed to talk with by the sandbox) and get the really sensitive stuff using and RMI or socket connection to a process running there either as a standalone application or as a servlet.

That way the sensitive code is never deployed with the servlet so the thief (if any) will have to write that all himself.

If you then make sure only authorised IP addresses can connect to your server you also have a nice subscription based service in place almost for free.

[server_crash]

getDocumentBase() is one thing, but I was really thinking of something else (maybe in combination with that).
Let your applet contact your server (which of course is the only one it's allowed to talk with by the sandbox) and get the really sensitive stuff using and RMI or socket connection to a process running there either as a standalone application or as a servlet.

That way the sensitive code is never deployed with the servlet so the thief (if any) will have to write that all himself.

If you then make sure only authorised IP addresses can connect to your server you also have a nice subscription based service in place almost for free.

Thanks, that's an excellent idea. I'm looking into getting a new webhost since the one I have doesn't support java. But I can't afford very much. I'm paying for a host that's 1.95$ right now, and that's about all I can afford. I think I just might set everything up before switching.