Discussion on:
View:
Show:
First, let me say that I am NOT a web developer, though I have fiddled around the area and did once manage to write enough PHP to search an XML database (if you can call it a database), and I am a firm believer in asking stupid questions. Anyway, if there is that much concern about source code being available to anyone that views the website, would it be better to use a server based technology like PHP or ASP?
... but mainstream Web development belief is that certain things are better to do on the client side, to provide a better experience and reduce traffic between the server. For other reasons, it is best to duplicate that on the server whenever possible (to handle scenarios where the user may have JavaScript disabled), but so many sites do so much with JavaScript now, it would be impossible to make the site work right without it anyways.
J.Ja
J.Ja
Yes and no - generally you will use javascript to enhance the client experience or validate data before posting and this isn't possible on the server side (you _can_ validate data server side, but the submit will have to happen and to some it may look messier). With the increasing use of AJAX (and you can create some cool effects with it) you _have_ to expose your code to the outside world so client and server side scripting are 2 sides to a coin. I can't see any of these techniques working well enough to be worth the hassle, personally - I've seen techniques like these used and I can still see the code - ultimately the browser has to have access to the scripts, and as they aren't compilable you can see them one way or another: seeing another thread linked on this page
http://techrepublic.com.com/5208-6230-0.html?forumID=102&threadID=227585&start=0&tag=btxcsim
I reckon a decent debugger should be able to expose all the code, and any decent programmer can shift through the trash put into it by these techniques.
http://techrepublic.com.com/5208-6230-0.html?forumID=102&threadID=227585&start=0&tag=btxcsim
I reckon a decent debugger should be able to expose all the code, and any decent programmer can shift through the trash put into it by these techniques.
servlets on the server side.
we do authentication, and based on user rights and other data passed to the servlet by XML, we format and show things with XSLT, etc.
The user should get no more than they need to, and see even less when they look in the source viewer.
we do authentication, and based on user rights and other data passed to the servlet by XML, we format and show things with XSLT, etc.
The user should get no more than they need to, and see even less when they look in the source viewer.
unobfuscating, would simply reverse engineer it, as that would be easier.
Total waste of time, in my opinion. If was that valuable, someone could 'steal' it anyway, and you would have a hope in hell of showing they did. Debugging on deployed systems is a nightmare as well.
As`far as I'm concerned it's a tool for people who have a reason to feel someone might rip their work, usually because they ripped a load of it themselves.
Total waste of time, in my opinion. If was that valuable, someone could 'steal' it anyway, and you would have a hope in hell of showing they did. Debugging on deployed systems is a nightmare as well.
As`far as I'm concerned it's a tool for people who have a reason to feel someone might rip their work, usually because they ripped a load of it themselves.
or minimally dishonest. Calling this a waste of time is like calling deadbolt locks on a house, a waste of time. A really dedicated burgler can just pick a deadbolt, no problem. It will keep most casual burglars out, like obfuscation will keep most casual code thieves out.
I think the casual ones are more of a risk. They have less thought to what they do, so they are likely to cause more damage.
I think the philosophy here is a fairly sound one, if it doesn't come at the expense of performance.
I agree with sidekick, that I'm moving towards server-side, and only delegating what I absolutely must to the client side.
I think the casual ones are more of a risk. They have less thought to what they do, so they are likely to cause more damage.
I think the philosophy here is a fairly sound one, if it doesn't come at the expense of performance.
I agree with sidekick, that I'm moving towards server-side, and only delegating what I absolutely must to the client side.
My beleif is that anyone with the smarts and the time to reverse engineer something of any substance could probably re-write it too. Sure, cracking the license key system on Photoshop, for example, has dividends, but so few people are doing something so insanely creative and unique with JavaScript that it is worth reverse engineering.
J.Ja
J.Ja
if box.value = ""
alert "Enter a name"
Hmm syntax error may be I should steal it....
Or perhaps just read a book....
Most casual theft from devlopers, is can't be arsed to look it up.
alert "Enter a name"
Hmm syntax error may be I should steal it....
Or perhaps just read a book....
Most casual theft from devlopers, is can't be arsed to look it up.
I'd be a bit more worried about someone taking my markup than my javascript code.
Then again, my goal is a well-behaved page. If casual theft keeps my browser from acting up on their site, and I need their site, then copy away! After all, the early days of web development was one of sharing technique, not locking it up.
That said, I'd rather people don't scrape my site for the data no it. It'd be nice if they did the research themselves, like I'm doing. LOL
Then again, my goal is a well-behaved page. If casual theft keeps my browser from acting up on their site, and I need their site, then copy away! After all, the early days of web development was one of sharing technique, not locking it up.
That said, I'd rather people don't scrape my site for the data no it. It'd be nice if they did the research themselves, like I'm doing. LOL
And if they don't get it from your site, it'll be someone else's with the same/similar methods who didn't bother trying to obfuscate.
would it be just as easy to put your code in a .js file and do an include in your html code if you don't want anyone to view your scripts?
You could obfuscate it though, if it makes you feel better. 
It's a nice technique for organising/re-using code, but most client side scripts are so tightly coupled to the page they are designed for they have extremely limited utility elsewhere.
Which is one of the reasons I see little reason to obfuscate javascript. In 99.999999% of cases, it does naff all but make buttons glow and display menus.
So unless you are planning on ripping off the lot wholesale, it merely saves you some typing. More to the point if you were going to do that, obfuscation becomes a bonus, as few can see you are a thief.
It's a nice technique for organising/re-using code, but most client side scripts are so tightly coupled to the page they are designed for they have extremely limited utility elsewhere.
Which is one of the reasons I see little reason to obfuscate javascript. In 99.999999% of cases, it does naff all but make buttons glow and display menus.
So unless you are planning on ripping off the lot wholesale, it merely saves you some typing. More to the point if you were going to do that, obfuscation becomes a bonus, as few can see you are a thief.
The thing about javascript is that it runs
in the browser (well, mostly, but we'll
ignore the rest). So the browser has to
have access to the javascript somehow to
run it.
Separate files that you include all over
the place are a Good Thing if it's
duplicated code on many pages... But won't
stop anyone from getting at the javascript
code...
People who can't copy the address of
the .js into the browser or whatever to
access the file (in other words, people who
have to have it included in the same html
page) are unlikely to know enough about
(x)html/javascript to get the code working
on anything except a clone of the site (in
which case they'll probably use a
downloader capable of following links,
which means separate files make no
difference anyway)
in the browser (well, mostly, but we'll
ignore the rest). So the browser has to
have access to the javascript somehow to
run it.
Separate files that you include all over
the place are a Good Thing if it's
duplicated code on many pages... But won't
stop anyone from getting at the javascript
code...
People who can't copy the address of
the .js into the browser or whatever to
access the file (in other words, people who
have to have it included in the same html
page) are unlikely to know enough about
(x)html/javascript to get the code working
on anything except a clone of the site (in
which case they'll probably use a
downloader capable of following links,
which means separate files make no
difference anyway)
once included, the code is sent to the browser where you can simply "view source" and see the javascript.
PHP is not sent, therefore no one can "steal" it. Of course if they hack the web server they could get it.
PHP is not sent, therefore no one can "steal" it. Of course if they hack the web server they could get it.
Just use Dean Edwards 'Packer'
(http://dean.edwards.name/packer/) which is used
mainly for speed optimisation, but when you view the
code after it has been run through 'Packer' it is an
absolute mess anyway and would take ages for someone
to sift through (add on top of that they don't know
how you structured your code so it's doubly
confusing). I just use Packer for speed optimisation
as I don't care if someone sees my code, this is an
open web. share information and help the progress of
all developers.
(http://dean.edwards.name/packer/) which is used
mainly for speed optimisation, but when you view the
code after it has been run through 'Packer' it is an
absolute mess anyway and would take ages for someone
to sift through (add on top of that they don't know
how you structured your code so it's doubly
confusing). I just use Packer for speed optimisation
as I don't care if someone sees my code, this is an
open web. share information and help the progress of
all developers.
Surely it helps the wider community if we accept that public facing code is going to be scrutinized and will not deter the ones who really can reverse your work, no matter how hard you try. Otherwise use .NET and C#.
Check this new service, it is still in beta but it seems very promissing: www.jscrambler.com
- Keyboard Shortcuts:
- Prev
- Next
- Toggle









































