I want to Obfuscate + Minify my Angular JS code in order to not make it public and if someone tries to decode it, then make it a hurdle. Code is running up on the server.
Note: In future we are planning to shift http to https.
I have seen a lot of options like Gulp, Google Closure Compiler, UglifyJS etc and many tool which a user can download and obfuscate the code like jsob, javascript obfuscate etc.
I need a suggestion and have few questions.
What is the more better approach apart from encryption?
If I shift to https shall I still require obfuscations?
What are the better and easy approaches with pros and cons?
If I use a tool like JavaScript obfuscate, then what will be its pros and cons? Am I able to get It back, I mean decode?
Or If someone is able to look into gulp file will it be easy to get my code?
1 - It really depends on what you are trying to achieve. If you really want to protect your code to hide your business logic, you should go for a resilient solution, instead of relying on a minification or obfuscation tool per se which is far too easy to defeat.
2 - Https simply means that the communication between your browser and website is encrypted. Https can also be decrypted, so it would make sense to apply other protection mechanisms
4 - JavaScript Obfuscator and several other tools do not protect the code, they are simple obfuscators and so they can be easily reversed in minutes and that's why some people think it's not worth protecting code on the client-side. In fact, you can get most of the original code using a simple JS optimizer. ClosureCompiler and UglifyJS have precisely this different approach, they reduce the size of the code and optimize it, they do not offer code protection.
3, 5 - I found this blog post from js13kGames competition creator quite useful for my case. He suggests a solution that seems to be more appropriate - Jscrambler. IMO you should give it a try as it combines code transformations with anti-debugging and anti-tampering features. You can also lock your code to a predefined list of domains or set an expiry date to deliver expirable demos, for example. Maybe it could be a fit for your case too as it supports Angular.
I've found a nice solution using gulp-uglify.
If you use implicit anotation, first use gulp-ng-annotate for not losing service names on uglify process.
Related
Nowadays, we always think like "send your data to a server, it computes it for you, then send you back the response".
But imagine something else : i want my client to compute the data itself.
The question is : is there something like a universal protocol to send actions rather than data through http ? So that the server can send the action to the client, whatever system it uses. If it does not exist, what are the technical difficulties you can face creating this kind of system ?
I'm talking about "static" actions, like mathematical functions for example.
You're unfortunately going to run into a problem pretty quick because, technically speaking, a universal language is impossible. Systems are going to have different architecture, different languages available, and different storage means. I believe what you intend (correct me if I'm wrong) is a "widespread" protocol. One way or another, you're going to have to drill down based on your personal use-case.
For a widespread example, you could keep a set of JavaScript files with functions server-side, and refer a web client to the one they need to run it by loading a javascript file during some event. Pass the location of the file and the function name, load it using the link above, then call the JavaScript function by name to run it. I could see this being an admitedly somewhat roundabout solution. This also may work in Java due to its built in JavaScript engine, although I haven't tested it.
Beyond that, I am unaware of anything particularly widespread. Most applications limit what they accept as instructions quite strictly to prevent security breaches (Imagine a SQL Injection that can run free on a client's machine). In fact, JavaScript limits itself quite severely, perhaps most notably in regards to local file reading.
Hopefully this helps with your ideas. Let me know in a comment if you have any questions/issues about what I've said.
For my rails application I use data-attributes rather extensively, as it was easy and the site was never expected to be finished or published, simply something I did for personal fun. A short example of the raw HTML would be
<span class="player-name" data-id="4" >Example Player</span>
I then could access the 'id' in coffeescript in the following way:
id = $('.player-name').data('id')
I was wondering if this utilization of data-attributes could potentially make the site susceptible to attacks through people editing the data-attribute in their developer console. Also if there is a better approach to accessing data in jQuery I would greatly appreciate it if someone could point me in the right direction. Thanks!
Yes, you're right. People can modify this. But this is hardly unique to data- attributes; people can modify anything and send any request with any parameters to your server.
You should always validate data coming from clients. Always, always, always. Too often have I seen applications where I have an url such as http://example.com/orders/42 where modifying the 42 to 666 resulted in me viewing a stranger's order. Oops! With AJAX requests it takes a bit more effort to fake data, but not much. People can (and will!) modify anything on your client-side: URLs, HTML, JavaScript, CSS, etc. so it's always wrong to rely on that for security.
In practice, this means that after getting an object from the database in your Rails app you should always check if the currently logged in user is allowed to view this object. For example, in a controller you might do something along the lines of:
def show
# Fetch it from the DB
some_object = SomeObject.find params[:id]
# Make sure the current user is authorized!
raise if some_object.player_id != logged_in_player.id
# ..your controller code..
end
I don't necessarily recommend you do this "manually" like in the above example. For Ruby on Rails there are two well-known gems to help with this:
Pundit; this is what I would recommend. It's simple, elegant, and flexible.
CanCan; also used a lot. It's more complicated than Pundit and I've found it doesn't actually provide more features. Your mileage may vary, though.
I'm wrapping a C++ library in PHP using SWIG and there have been some occasions where I want to modify the generated code (both generated C++ and PHP):
Fix code-generation errors
Add code that makes sense in PHP, but not in C++ (e.g. type checking)
Add documentation tags (e.g. phpDoc)
I'm currently automating these modifications with patch. This approach works, but it seems high-maintenance and fragile. Is there a better way of doing this?
The best bet is to have your code generator generate correct code for your needs. Hand-tweaking generated output is unsustainable. You'll have to tweak it again any time the input changes.
If a tool is producing flatly erroneous output, it's ideal to repair it and submit patches back to the maintainer. If the output is correct for some circumstances but wrong for yours, I'd suggest to add an option that changes the behavior to what you need.
Sometimes, you can use a short program that automatically does an intelligent job of patching your generated code, so that you don't need a manual process to make patches.
Alternatively, you could write your own code generator, but I suspect that's much more work than you want. It also depends on what you're doing. Sometimes code-generation is really just macro-expansion, and there are plenty of good tools for that in the wild.
Good luck!
You may end up having a maintenance nightmare later on. Instead of SWIG you might consider using another generative approach that:
Let you add your custom code directly on the model (so that you won't need to add it post-generation)
Let you define your own generator. This feature alone could take out the need to add custom code all along.
The problem of using third-party generators is that they never really generate what you want. The problem of writing your own code generators is that it's much more work. You choose.
But correcting an automation with another automation...
Code generation is quite a wide topic and there are definitely many other approaches, which might be more interresting to you as mentioned above.
But if you do not want to use other tool, depending on what code is generated and on the PHP OO capabilities, you might use the Generation Gap pattern.
I'm starting to use Dojo; this is (essentially) my introduction to AJAX. We have a Java backend (torque / turbine / velocity) and are using the jabsorb JSON-RPC library to bridge Java and Javascript.
What do I need to know? What is the big picture of Dojo and JSON, and what are the nasty little details that will catch me up? What did you spend a couple of days tracking down, when you started with Dojo, that you now take for granted? Thanks for any and all tips.
The first thing to do is get familiar with the Dojo Object Model. JavaScript does not have a class system so the Dojo toolkit has created a sort of "by convention" object model that works rather well but is very different to how it works in Java for example.
The reason I suggest getting familiar with it is so you can dig into the code base whenever you start experiencing issues. The documentation available has improved significantly over the past year, but every now and then I find myself having to work out a bug in my code by learning exactly how the Dojo code involved works.
Another tip is to make use of the custom build feature which will significantly improve performance once your application is ready.
As a general tip on DHTML programming, use firebug (a plug-in for Firefox). It allows JavaScript debugging, DOM inspection, HTML editing in real-time and a whole lot more. I've become totally reliant on it now when I'm working in DHTML!
Good luck!
I too just dove head first into Dojo, they have a good API documentation at http://api.dojotoolkit.org/. Even Dojo Campus has some good examples of the plug ins.
If you ask me O'Reilly's Dojo: The Definitive Guide is the best Dojo book on the market.
I also would like any tips and pointers from the Dojo masters.
Cheers
Make sure documentation you read pertains to as recent a release as possible, since a lot has changed very quickly in the Dojo architecture.
Also a great way to see how some Dojo or Dijit widget is used is to look at the source code for the tests - for example, the DataGrid has poor documentation but the tests show a lot of use cases and configurations.
Sitepen is a good resource for Dojo articles.
Also, read up on Deferred (andDeferredList), as well as hitch() - two extremely flexible and powerful features of Dojo. SitePen has a great article on demystifying Deferreds.
Check out plugd, a collection of Dojo extensions that make some things more convenient or adds some clever functionalities to the language. It's made by one of the core Dojo authors so it's rather reliable. It even brings some jQuery niceties into the framework.
Some more things: look into data stores, they're very useful and a much cleaner way to handle Ajax. DojoX has a lot of nice ones too, just remember that DojoX ranges in how well documented or how experimental the components are. Learn the differences between dojo.byId and dijit.byId, as well as the HTML attributes id versus jsId (again, Sitepen has an article).
A couple of things that caught me when I started writing widgets where:
[Understand what dojoAttachPoint, dojoAttachEvent, containerNode and widgitsInTemplate do][1]
have a firm grasp of closures,
Get your head around deferreds
understand ItemFileReadStore, ItemFileWriteStore and stores in general
You can look at stores like a ResultSet (sort of) as well you can data bind them to widgets.
With these major concepts you can start to put together some compelling applications.
Generally what I do is I build a JavaScript facade around my service calls and then I will scrub the response into a store by attaching the first callback in the facade, that call back converts the results into a store and then returns it. This allows me to not hard bind my services to Dojo constructs (so I can support mobile, etc.) while also retuning the data from the facade in a format that data aware widgets expect.
As well if you are doing Java service development you my want to look into JAX-RS. I started out using JSON-RPC which became JABS-ORB but after working with JAX-RS I prefer it, as it integrates well with JPA-EJB and JAXB.
First read how to configure Dojo in your application. Try to understand basic structure of Dojo like if we are writing dijit.form.Button or dijit/form/Button it means Button.js resides in dijit/form folder. Try to understand require, define, declare modules of Dojo. This is enough to start Dojo Toolkit.
Very important fact, indulge with your own sample project using Dojo.
We have a website that uses #include file command to roll info into some web pages. The authors can access the text files to update things like the occasional class or contact information for the department.
My question is this, I don't see anyone using this method and wonder if it is a good idea to keep using it. If not, what method should I transition to instead?
I don't think there is anything wrong with it, and I've done some similar things with PHP. If the people that make the changes are comfortable with how they do it and they can do what they need to, I think you should stick with it. There could be some retraining involved and/or a fair amount of work involved for changing the system.
If you are using ASP.NET then you could bundle that code into a nice little UserControl that will display all of the important information.
Other platforms should allow you to bundle the logic into a class object, and display it using that.
It really depends on the platform that you are using to deploy the application in. The include file could be your best solution if you are deploying in a more limited platform.