| 11:35 pm on Jun 29, 2003 (gmt 0)|
I don't know about apache, but as a general rule, you can't stop anyone from downloading the js file. In fact, if they want it, its most likely already in their cache, and they don't ever have to go back to your server to retrieve it.
| 12:56 am on Jul 1, 2003 (gmt 0)|
thats dumb though everyone knows how to decrpyt it, theres got to be a way of protecting source...
| 2:16 am on Jul 1, 2003 (gmt 0)|
>theres got to be a way of protecting source...
No, there isn't. If the browser can read it, a human can read it. You can make it difficult, but it can still be retrieved.
| 5:05 am on Jul 1, 2003 (gmt 0)|
In answer to your original question, you can "sort of" use .htaccess to stop direct type-in access, but at the cost of losing visitors who access your site from behind corporate firewalls, or those with firewalls or internet security software installed at home.
You could also implement some kind of fancy session tracking to make sure that anyone requesting a .js file has loaded the containing html page, but that would then require you to disable caching of the containing page in order to ensure that it was always loaded from your server. And that would slow down your user's experience and increase your server load.
I found it easier to just "get over it" in most cases. YMMV.
| 4:28 pm on Jul 1, 2003 (gmt 0)|
| 4:29 pm on Jul 1, 2003 (gmt 0)|
| 4:42 pm on Jul 1, 2003 (gmt 0)|
You need to beef up on lawyers and licenses then.
If you release your code to be run elsewhere, then they can reverse engineer it. Not even moving to Java or C will help you.
You can always invite them over to your house to play the game on your computers...
| 5:27 pm on Jul 1, 2003 (gmt 0)|
Beyond the suggestions mentioned here, there are NO other solutions. What you are asking is not technically possible. It someone wants your JS code, they will find a way to get it.
| 8:50 pm on Jul 1, 2003 (gmt 0)|
| 12:39 am on Jul 2, 2003 (gmt 0)|
cgi, php, etc, are not in realtime, hence the problem. and if what your saying is true, that there is absolutly no way to protect this code, out of the thousands of security measures and teams working on this stuff to date, then you are wrong, i dont care what you say.
| 1:01 am on Jul 2, 2003 (gmt 0)|
The problem here isn't security, really. JS is a client side technology ie, the code is delivered to the browser, which then runs it. Therefore you MUST deliver readable, runnable code to the browser, or it just doesn't work. If someone wants to get really fancy, they will run a packet sniffer on the traffic from the game server, strip the TCP/IP headers, and stitch the raw source back together to nick it, or intercept it at the transmission layer, modify it before delivering it to the application layer and presumably then screwing up the game mechanics etc
>> simply being able to take the source right out of my own .html files nad stick it ont heir site is out of hte question.
Then you need to use a non-web technology surely. HMTL, JS etc, its all explicitly designed to be open technology, to facilitate sharing. Its one of the reasons that security is so damn hard in ecommerce for instance. You have to create at best an extra layer (SSL), maybe a different protocol (HTTPS), or ultimately a proprietory, non-open system (EDI springs to mind) to have any chance of securely exchanging c/c details etc and then someones just going to leave all the c/c details on a database thats open to HTTP calls. D'oh!
What you really need is a non-open equivalent, your own proprietory file format etc, similar to Flash in that regard, I suppose. Then you supply a plug-in for the browser, and the files go up as meaningless binary files, useless unless you can decode them with the plugin.
| 1:49 am on Jul 2, 2003 (gmt 0)|
| 3:22 am on Jul 2, 2003 (gmt 0)|
Perhaps you can explain how you stopped the browser cacheing the .js file....
| 4:33 am on Jul 2, 2003 (gmt 0)|
IcyDash - let us know when you've fixed all your security issues. I'm sure a few of us would be happy to beta test your "solution". ;)
| 4:53 am on Jul 2, 2003 (gmt 0)|
Guys, I'm not to worried about beta testing, I work with the best and brightest out there, if there is a hole, it can be found by these people. I own <snip>, and I'll let you all know how its done once I resolve all security issues -- and to the comment above, with php headers you can stop browser catching.
[edited by: Woz at 6:39 am (utc) on July 2, 2003]
[edit reason] No URLs please, TOS#13. [/edit]
| 5:11 am on Jul 2, 2003 (gmt 0)|
Alternatively, I could just access your page the regular way, and have a packet sniffer grabbing your source as it flows into my machine.
| 5:13 am on Jul 2, 2003 (gmt 0)|
Urls are against the TOS, IcyDash...
You should write client side code using C++.
| 4:23 pm on Jul 2, 2003 (gmt 0)|
There's also Mozilla's about:cache, where you can pick out any 'ol file in your cache and view it, or the DOM Inspector where you can pick any 'ol JS file and view and save its contents, or Venkman, the JS debugger, where you can view any 'ol JS file and save it.
I doubt it would take any single person determined to get your JS more than an hour to download it and email it all to you. Certainly no more than a day.
Care to sticky me a URL, and email?
| 5:32 pm on Jul 2, 2003 (gmt 0)|
As i said above their are still some security issues, and contrary to your beliefs, it is not done with JUST a referrer, there are several security measures in place. We are also working on transfering the data encrypted so, no, a packet sniffer will not work. And as for the cache, i believe ive said it before, there are ways around that with php headers. And as you said, yes, my sites boards are all for hackers, so i am sure all security issues will be resolved quickly. I am not saying it is 100% secure now, i am just saying that we are on our way there, and i have allready managed to do 'the impossible' that you ALL said i couldn't do, so why not a little faith?
| 5:33 pm on Jul 2, 2003 (gmt 0)|
sorry about the url i didn't know it was against TOS.
| 5:35 pm on Jul 2, 2003 (gmt 0)|
Oh and for all you who think you can do it with js debuggers and so on, its in a .php not .js file, so no, you can not download the code, and js debuggers will not work since the code is stored server side unless the script is given the correct arguements from the correct file.
| 5:39 pm on Jul 2, 2003 (gmt 0)|
trust me--this is what i do, im not retarded, heh. :)
| 9:32 pm on Jul 2, 2003 (gmt 0)|
For what it's worth:
|Oh and for all you who think you can do it with js debuggers and so on, its in a .php not .js file, |
so no, you can not download the code, and js debuggers will not work since the code is stored
server side unless the script is given the correct arguements from the correct file.
Think I understand about what you are saying, I use a '<script src=whatever.js>'
which is really a server binary 'c' to deliver a js source file back to the browser.
If it's not called in the right way/place/path/etc, 'most' of the time you
won't get the js file, and if you do get it, it's most likely not useable anywhere else.
Likewise the js file in the cache is not useable elsewhere also.
But people can still get it.
| 10:28 pm on Jul 2, 2003 (gmt 0)|
|trust me--this is what i do, im not retarded, heh. :) |
| 3:41 am on Jul 3, 2003 (gmt 0)|
exactly thanks for the encouragement guys its nice to finally get some :) and im probably 50% there in my quest for secure js code ;]
| 4:00 am on Jul 3, 2003 (gmt 0)|
w00t baby make that 50% a 60%, now with all the measures in place the ONLY way of getting the code is with a packetsniffer. Going to the correct url, no matter what arugements you type in, it wont display the code. Now just to find a way to encrypt the data as it sends so its a big jumble in the packetsniffer and my 60% jumps to a 90%, leaving just other random ways i havnt thought of yet. :]
| 8:18 am on Jul 3, 2003 (gmt 0)|
I just don't hope you 'encrypt' it enough so that your browser cannot run the plain-text scripted code *g*
| 8:50 am on Jul 3, 2003 (gmt 0)|
>> leaving just other random ways i havnt thought of yet. :]
Like implementing a system freeze, and pulling the code straight out of RAM over a null modem connection?
I've seen that done... and I don't think theres a way around it
| 5:01 pm on Jul 3, 2003 (gmt 0)|
yea stuff like that
| This 31 message thread spans 2 pages: 31 (  2 ) > > |