Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Need the power to lock out the "view code" option.
- Thread starter canix
- Start date
The users pay well for this (fortunately). That is the 4th book I have done for them. Originally I did it server side but at times of heavy use it was SLOOOW so I went client side and the customers were very happy. Also I sell the tool to create these tests and it is selling well and used many places. My conclusion is that even if JavaScript was not made to do this, it does it well.
Carl
ps:I am fairly certain that there is very little cheating less than 1 in a 1000.
Carl
ps:I am fairly certain that there is very little cheating less than 1 in a 1000.
Hey, silly puddy wasn't "made" to be a toy, but the inventor didn't give a sh#%. It was an incredible money maker.
The microvave oven was an accident. Not the original intent of the inventor. The list goes on and on. Carl, if it's puttin' food on the table, run with it.
Kevin
slanek@ssd.fsi.com
The microvave oven was an accident. Not the original intent of the inventor. The list goes on and on. Carl, if it's puttin' food on the table, run with it.
Kevin
slanek@ssd.fsi.com
There is no reason that reading a text file with Perl or C or using SSI should have any noticable effect on server performance. If it does, then it was done wrong. I'm not saying that the JS method is utterly terrible, just that it is not ideal and certainly not without flaw.
Sincerely,
Tom Anderson
CEO, Order amid Chaos, Inc.
Sincerely,
Tom Anderson
CEO, Order amid Chaos, Inc.
The file is not a simple text file it involves many very complicated calculations and different ones for each student. It is in slow when you are having 100s of student hits per minute.What is 'ideal' is what works well and this works well.Actually I think client side is the way to go whenever possible.
Carl
Carl
luciddream
Programmer
i also agree with doing things client side whenever possible, but, when your requirements are that you have to keep the answers, passwords, whatever, away from prying eyes, then its time to look towards server-side code adam@aauser.com
re:
i also agree with doing things client side whenever possible, but, when your requirements are that you have to keep the answers, passwords, whatever, away from prying eyes, then its time to look towards server-side code
agreed. jared@aauser.com
i also agree with doing things client side whenever possible, but, when your requirements are that you have to keep the answers, passwords, whatever, away from prying eyes, then its time to look towards server-side code
agreed. jared@aauser.com
Of course you should do calculations client side... its distributed computing! However, information should be kept server-side.
Also, unless you have a really, really slow server, then you should be able to take thousands of simultaneous processes without too much trouble. I use a Cobalt RaQ running Linux to run ecommerce applications on several individual sites, the combined load of which is pretty high, but there is still no noticable difference in speed. You're not using a Windows server, are you?
Sincerely,
Tom Anderson
CEO, Order amid Chaos, Inc.
Also, unless you have a really, really slow server, then you should be able to take thousands of simultaneous processes without too much trouble. I use a Cobalt RaQ running Linux to run ecommerce applications on several individual sites, the combined load of which is pretty high, but there is still no noticable difference in speed. You're not using a Windows server, are you?
Sincerely,
Tom Anderson
CEO, Order amid Chaos, Inc.
Wow, quite a busy thread!
What I can conclude from this is that code hiding is far from foolproof when the data that you're trying to hide is in the client's possession (i.e. on his/her computer), although there are ways you can make things inconvenient, effectively hiding the code from most users.
If you have information that must /absolutely/ be kept from prying eyes (credit cards numbers, a list of the real names of spies etc.), passing the data to the client and *hoping* that the client won't figure out how to get it off his/her own computer is definitely not a viable option.
Russ
bobbitts@hotmail.com
What I can conclude from this is that code hiding is far from foolproof when the data that you're trying to hide is in the client's possession (i.e. on his/her computer), although there are ways you can make things inconvenient, effectively hiding the code from most users.
If you have information that must /absolutely/ be kept from prying eyes (credit cards numbers, a list of the real names of spies etc.), passing the data to the client and *hoping* that the client won't figure out how to get it off his/her own computer is definitely not a viable option.
Russ
bobbitts@hotmail.com
I don't disagree much with anything recently said but I will make two points. Yes credit cards numbers and the such should not be stored client side. In physics the calculations are the answer and that was what I am protecting. If I knew C++ they probably could be done server side but not with PERL and the like. Besides the thread was how to hide JavaScript and I do it pretty well, whether wise or not.Carl
- Thread starter
- #32
So.... I come back and I see that you guys say it's impossible to make it an absolute lockout without at least running through CGI. I have still seen better then that. It took two of my best hackers to break one line of html... I know not what that code was.. that wasn't the point.
Listen up gentlemen, there is a way to lock down both "View Sources" a way to keep the right click from working properly, (which I already have" and a way Are you telling me now that some of the best programmers on the net cannot even imagine how to acomplish such a feet?
This is not in offense, and no, the code isn't as sacred.. I was just in a rush.. the deals done and the job was for a person with a slight case of paranoia... Nothing more.
But if this small question... got a rise out of this many people... this tells me only one thing, there is a way and you guys are definitly going about 120mph in your head about how to do it.
But alas, I am a mere techie, not a programmer. Take it easy guys... thanks for the insight on the programmer's line of thought.
~CaNiX~
Listen up gentlemen, there is a way to lock down both "View Sources" a way to keep the right click from working properly, (which I already have" and a way Are you telling me now that some of the best programmers on the net cannot even imagine how to acomplish such a feet?
This is not in offense, and no, the code isn't as sacred.. I was just in a rush.. the deals done and the job was for a person with a slight case of paranoia... Nothing more.
But if this small question... got a rise out of this many people... this tells me only one thing, there is a way and you guys are definitly going about 120mph in your head about how to do it.
But alas, I am a mere techie, not a programmer. Take it easy guys... thanks for the insight on the programmer's line of thought.
~CaNiX~
canix -
You say there is a way to keep someone from using "View Source" or from right clicking on the document. If you do this without Java, then you must use Javascript, which is the easiest thing to get around. I have a little Unix utility called "wget" that can retrieve any web page without browser interaction, and save it as a text file on my system (that's only one method out of many). Simply put, no Javascript or HTML method will protect client-side code. Of course one time-honored method is obfuscation: write code that is so incoherently laid out and unorganized looking that it's not worth someone's trouble to figure it out.
The only way to truly protect client-side code is with a browser that supports some level of code encryption, which can be done with IE 5+, using the Windows Script Encoder, which you can cownload for free at Of course you are then limited in browser choice, but it might be a useful thing for some sort of intranet application. I believe there have also been attempts to create a Java application that compiles Javascript into Java code for Netscape/mozilla. I haven't yet played with that one so I don't know how successful it's been.
I see a lot of argument going on about whether it's right or wrong to protect code. I try to take a utilitarian view of such things: I think its a great thing that we have such an open resource as the web, and the incredible amount of open-source software out there, and I am happy to contribute in any way I can. However, if I so choose to protect certain code, so what? Why is it anyone else's business to 'make' me share it? You feel outraged that I might want to protect something? Too bad. On the other hand, when I put web pages up to be visible to all, then if someone manages to dissect what I have done and make use of it, there is no point in my being upset, since I have made that page freely available. I believe this is the only balanced perspective to take on all this.
Yes I have used certain schemes now and then to protect client-side code, even including the Windows Script Encoder, but I know that nothing is 100% protectable once someone has the data on their system, so I don't worry about it. Server-side data, now that is another matter, and one which I do take sacredly, since that is not something I have made freely available.
(gets off soap box...)
You say there is a way to keep someone from using "View Source" or from right clicking on the document. If you do this without Java, then you must use Javascript, which is the easiest thing to get around. I have a little Unix utility called "wget" that can retrieve any web page without browser interaction, and save it as a text file on my system (that's only one method out of many). Simply put, no Javascript or HTML method will protect client-side code. Of course one time-honored method is obfuscation: write code that is so incoherently laid out and unorganized looking that it's not worth someone's trouble to figure it out
.The only way to truly protect client-side code is with a browser that supports some level of code encryption, which can be done with IE 5+, using the Windows Script Encoder, which you can cownload for free at Of course you are then limited in browser choice, but it might be a useful thing for some sort of intranet application. I believe there have also been attempts to create a Java application that compiles Javascript into Java code for Netscape/mozilla. I haven't yet played with that one so I don't know how successful it's been.
I see a lot of argument going on about whether it's right or wrong to protect code. I try to take a utilitarian view of such things: I think its a great thing that we have such an open resource as the web, and the incredible amount of open-source software out there, and I am happy to contribute in any way I can. However, if I so choose to protect certain code, so what? Why is it anyone else's business to 'make' me share it? You feel outraged that I might want to protect something? Too bad. On the other hand, when I put web pages up to be visible to all, then if someone manages to dissect what I have done and make use of it, there is no point in my being upset, since I have made that page freely available. I believe this is the only balanced perspective to take on all this.
Yes I have used certain schemes now and then to protect client-side code, even including the Windows Script Encoder, but I know that nothing is 100% protectable once someone has the data on their system, so I don't worry about it. Server-side data, now that is another matter, and one which I do take sacredly, since that is not something I have made freely available.
(gets off soap box...)
Canix,
It is quite simple really... HTML and JavaScript are interpreted languages, which means that plain text code gets sent to the browser which then interprets it and renders your pages.
Unless you find a way to compile your code, such as suggested above, then it will be freely available to whoever hits your web page. And even if you compile it into Java, it is still pretty easy to reverse engineer it through a decompiler. And if you use a proprietary method such as the MS method above, then you exclude much of your audience. Also, I'm sure the source of the un-encoder is fairly simple to get if they make it available as a "standard" which other browsers can support, in which case you'll find code decompilers all over the web. So, the answer is quite simply NO, you cannot "lock away" your code. As rycamor said, you can make it hard to read, and you can try to put up obstacles, but anyone with a little knowledge and determination could get to it.
All you'd have to do is telnet to your webserver on port 80 and spoof a browser. If you know HTML and JavaScript, you can follow any amount of code hiding through external files, etc.
Sincerely,
Tom Anderson
CEO, Order amid Chaos, Inc.
It is quite simple really... HTML and JavaScript are interpreted languages, which means that plain text code gets sent to the browser which then interprets it and renders your pages.
Unless you find a way to compile your code, such as suggested above, then it will be freely available to whoever hits your web page. And even if you compile it into Java, it is still pretty easy to reverse engineer it through a decompiler. And if you use a proprietary method such as the MS method above, then you exclude much of your audience. Also, I'm sure the source of the un-encoder is fairly simple to get if they make it available as a "standard" which other browsers can support, in which case you'll find code decompilers all over the web. So, the answer is quite simply NO, you cannot "lock away" your code. As rycamor said, you can make it hard to read, and you can try to put up obstacles, but anyone with a little knowledge and determination could get to it.
All you'd have to do is telnet to your webserver on port 80 and spoof a browser. If you know HTML and JavaScript, you can follow any amount of code hiding through external files, etc.
Sincerely,
Tom Anderson
CEO, Order amid Chaos, Inc.
- Thread starter
- #37
OK... I get the message.. And in truth.. there is no lock that can't be picked and no key that can't be taken... I am surprised at the turnout for this little venture... And thanks for the "wget" for unix.. didn't know that one.. learnin' something new every day.
I guess I will stick to networking and stay outta web design until we can plug it into our head.. At least then you could beat the information out of them eh? Something a little more interesting to come.
Take it easy.. and thanx 4 da info.. this 17 y.o. is signing out... Muahahahahahaha...
~CaNiX~
I guess I will stick to networking and stay outta web design until we can plug it into our head.. At least then you could beat the information out of them eh? Something a little more interesting to come.
Take it easy.. and thanx 4 da info.. this 17 y.o. is signing out... Muahahahahahaha...
~CaNiX~
- Status
Similar threads
- Locked
- Question
