We are considering node.js for our next server side application. But we don't want our client to be able to look into our application's code. Can we deploy application written in node.js in compiled form? If yes, then how?
Maybe you could obfuscate all your code... I know this is not like compiling, but at least, it will avoid the 99% of the clients of looking at the code :D
Here is another topic: How can I obfuscate (protect) JavaScript?
good luck
But we don't want our client to be able to look into our application's code.
If you are shipping code to your client, they will be able to "look into your application's code". Technically, the process of "running your code" is "looking into your application's code".
Having a fully compiled version of your code can definitely feel "more safe", but they still have a copy of the code in some usable form. They can still reverse engineer pieces or do other things. This stuff really comes down to the license.
Here's a related answer. His quote is:
Write a license and get a lawyer to go after violators
Otherwise, you should host the stuff yourself and allow for public access.
Any form of obfuscation, minification, compilation is just going to be a speed bump on the way to "stealing your code". It's probably much better to simply have legal recourse.
I don't believe this is possible. I mean, technically I guess you could write everything as native C++ extensions, but that would defeat the purpose of using node.
As mentioned before, there is no true compilation in Node.js because the nod executable basically compiles javascript code on the fly.
A lot of developers use Google's Closure Compiler which really just "minify" -- removes comments, whitespaces, etc. -- and "optimize" -- converts javascript code to more efficient javascript. However, the resultant code is generally still parsable javascript code (albeit rather hard to read!). Check out this related stream for more info: Getting closure-compiler and Node.js to play nice
A couple of options that might be helpful:
Develop a custom module for "proprietary" business logic and host it on your secure servers
Wrap "proprietary" business logic into a java class or executable that is called as an external process in Node.js
Code "proprietary" business logic as compiled web services available on a separate application server that is called by Node.js.
It's up to you to define what part of your application should be considered "proprietary", but as a general rule I would not classify HTML and related javascript -- sent to the we browser -- as "proprietary". My advice is to be judicious here.
Lastly, I found the following stream with an interesting approach that might be helpful, but it is rather advanced and likely to be rather buggy: Secure distribution of NodeJS applications
Hope that helps...
Related
I wanted to know if anyone has been using AirBnB Rendr and is it stable and ok to use in commercial projects or is it still changing a lot?
I'm developing a website which can run both client and server based, this mean I need to be able to render pages and widgets server and client based.
The server is running Node.js, dust.js and has custom server based code to render the pages and widgets on the server side. I need to pick how to handle it on the client side.
Naturally I want to try and not repeat code, but obviously the client is different I can:
Keep my current page based server rendering and develop custom
client side code.
Use backbone.js on client side and keep my server based code the
same.
Use AirBnB rendr that is based on Node.js and backbone to use the
same code on client and o server. AirBnB Rendr Library
I like the 3rd idea very much, but I'm looking for some input from you guys.
Has anyone used it? any experience with it in terms of stability and/or how often their api changes etc?
I've just started playing around with Rendr. If I ignore the learning curve and oboarding friction, I like it a lot and I plan to write my next large production app using Rendr.
Unfortunately, as bababa listed above, the documentation needs a lot of work. There is an explanation of how Rendr works in its README and the example app's README but beyond that you'll need to source dive in order to figure out how the gears are turning. Currently, there is no forum for questions (other than stack overflow :D) and I've had a hard time figuring out its idioms on my own.
Despite all the struggles, I finally see the light and I'm starting to understand why Rendr is so powerful.
tl;dr - If you're willing to source dive and figure out your own workflow, I would suggest using Rendr. Otherwise, I would recommend going old school by writing a traditional client app with a more mature library. (is it too early to say that? =X)
Well given AirBnb is a successful commercial enterprise, there's some validation that the library works well enough for them. This question is probably best answered by watching their github commit log for breaking changes. Given backbone is 1.0 and essentially stable at this point, rendr will probably quickly stabilize, but honestly your fear of instability is probably unjustified. I think rendr looks compelling and although my current project is using a very similar home-grown solution, I would consider using rendr in a future project or even porting our code to rendr. "Stability" per say is much less important to the web development community compared to other situations like packaged or embedded software.
I used (tried to use) and Rendr on a project and gave up. There are just to many limitations (currently) and the lack of documentation doesn't help. I ended up need to rewrite the source code to accomplish some things I would consider trivial with other frameworks, such as passing multiple collections to a view. It just wasn't possible (at the time I used it) and that was a deal breaker. Not being able to pass a collection of categories and results to a page was to much of a limitation.
I have no doubt it will eventually be ready for production use, but right now I would say unless you are an engineer at AirBnb and know how to hack the source then no, it's not ready.
If you really want to know if it will work for your needs, take a look at the issue list on github. That will give you a good idea where the projects at.
UPDATE 1: I made a lot of progress on this one. I pretty much gave up (at least for now, but maybe long term) on the idea of allowing user-uploaded modules. However, I am developing a structure so that several modules can be defined and loaded. A module will be initialised, set its own routes, and have a 'public" directory for Javascript to be served. The more I see it, the more I realise that I can (should) also move the calls that are now system-wide in a module called "system".
UPDATE 2: I have made HUGE progress on this. I am about to commit tons of code on GitHub which will allow people to do really, really good modular programming (with modules exposing both client and server side code) using Node and Express. Please stay tuned.
UPDATE 3: I rewrote this thing as a system to register modules and enable them to communicate via a event/hooks system. It's coming along extremely nicely. I have tons of code already good to go -- I am just porting it to the new system. Feel free to have a look at the project on GitHub: https://github.com/mercmobily/hotplate )
UPDATE 4: This is good. It turns out that my idea about a module being client AND server is really working.
UPDATE 5: The module is getting closer to something usable. I implemented a new loader which will take into account what an init() function will invokeAll() -- and will make sure that modules providing that hook will be loaded first. This opens up hotplate to a whole new level.
UPDATE 6: Hotplate is now close to 12000 lines of code. By the time it's finished, sometime in February, I imagine it will be close to 20000 lines of code. It does a lot of stuff, and it all started here on StackOverflow! I need it to develop my own SaaS, so I really need to get it finished by February (so that I can sprint to July and finish the first version of BookingDojo). Thanks everybody!
I am writing something that will probably turn into a pretty big piece of software. The short story is that it's nodejs + Express + Mongodb/Mongoose + Dojo (client side).
NOTE: Questions in this text are marked as [Q1], [Q2], etc.
Coming from a Drupal background (and knowing how coooomplex it has evolved, something I would like to avoid), I am a bit of a module freak. At the moment, I've done the application's boilerplate (hotplate: https://github.com/mercmobily/hotplate ). It does all of the boring stuff (users, workspaces, password reminder, etc.) and it's missing quite a few pieces.
I would like to come up with a design that will allow modules in a similar fashion as Drupal (but possibly better). That is:
Modules can define new routes, and handle them
Modules are installed system-wide, and then each workspace can enable a set list of them
The initial architecture could be something along those lines:
A "modules" directory, where there is one directory per module
Each module has a directory for "public" files for the Javascript side of things
Each module would have public/startup.js which would be included in the app's javascript
Each module would have server/node.js which would be included on the fly by the server if/when needed
There would be one route defined, something like /app/:workspaceid/modules/MODULE_NAME/.* with a middleware that checks if that workspace has MODULE_NAME enabled -- and if it does, calls a module's function with the passed parameter
[Q1]: Does this some vaguely sane?
Issues:
I want to make this dynamic. I would like modules to be required when needed on the spot. This should be easy enough to do, by requiring things on the fly.
server/node.js would have a function called, but that function feels/looks an awful lot like a router itself
[Q2] Do you have any specific hints about this one?
These don't seem to be too much of a concern. However, the real question comes when you talk about security.
Privacy. This is a nasty one. At the moment, all the calls will make the right queries to mongoDb filtering by workspaceId. I would like to enforce some way so that there is no clear access to the database by the modules, so that each module doesn't have access to data that belongs to other workspaces
User-defined modules. I would love to give users the ability to upload their own modules (and maybe make them available to other users). But, this effectively means allowing people to upload code that will be executed by node itself! How would you go about this?
[Q3] How would you go about these privacy/security issues? Is there any way for example to run the user-uploaded code in a sort of node sandbox? What about access to file system etc.?
Thanks!
In the end, I answered this myself -- the hard way.
The answer: hotplate, https://github.com/mercmobily/hotplate
It does most of what I describe above. More importantly, with hotPlate (using hotPage and hotClientPages, available by default), you can write a module which
Defines some routes
Defines a "public" directory with the UI
Defines specific CSS and JS files that must be loaded when loading that module
Is able to add route-specific JSes if needed
Status:
I am accepting this answer as I am finished developing Hotplate's "core", which was the point of this answer. I still need to "do" things (for example, once I've written docs, I will make sure "hotplate" is the only directory in the module, without having an example server there). However, the foundation is there. In terms of "core", it's only really missing the "auth" side of the story (which will require a lot of thinking, since I want to make it so that it's db agnostic AND interfacing with passport). The Dojo widgets are a great bonus, although this framework can be used with anything (and in fact backbone-specific code would be sweeeeet).
What hotplate DOESN'T do:
What hotplate DOESn'T do, is give users the ability to upload modules which will then be loaded in the application. This is extremely tricky. The client side wouldn't be so bad (the user could define Javascript to upload, and there could be a module to do that, no worries). The server side, however, is tricky at best. There are just too many things that can go wrong (the client might upload a blocking piece of code, or they could start reading the file system, they would have access to the full database, and so on).
The solution to these issues are possible, but none of them are easy (you can cage the user's node environment and get it to run on a different port, for example, and so on) but some problems will stay. But, there is always hope.
My main question is whether it makes sense to begin with node.js as a complete server-side newb. Is JS/node.js a good choice to start server-side web-programming from scratch?
I do lots of frontend work, namely HTML, CSS and basic JS. I even wanted to start with Rails but always had the feeling that not knowing what is going on behind the curtains makes me completely uncertain about the framework - it was just too much "convention over configuration".
My hope is to learn JS in general and dive into node.js right after that. I don't know, however, if this is a good approach for a person without any server-side experience. When looking at existing node.js topics and discussions, the used terminology seems to require lots of knowledge about how servers work in general.
Have no fear. Programming is all about practice and you will do mistake while writing code. But, that is how we all have learnt. Whether it is Ruby, Javascript (via Node.js), or any other language: certain aspects of programming are common and you will get familiar with things specific to that particular language over time. Being not able to remember a syntax or convention is OK. Just have reference material on your side. In fact it is encouraged to tinker and experience "let's see what happens ?" moments. This is how you learn, IMHO.
Node.js is indeed a great choice to start learning server side web development. No doubt about that. You don't have to learn Javascript first and then start learning node. Here you can find all the resources you may want. Also, have a look at this How do I get started with Node.js
Here is what I would recommend as your learning path. This is not even node.js 101. But, it will be a great start.
Hello World on console. Dead simple and lot of fun
Math Addition. ( Nothing to do with server development, can skip, but good if you learn it ! )
Addition of hard coded inputs.
Addition where function add(a,b) is written in another .js file. Boy, now you are creating libraries !
Math addition where input is provided using command line. TIP: Use https://github.com/substack/node-optimist
Hello World on web page.
Hello World for web but without express.js to start with. Here is the code - http://nodejs.org/
Hello World for web with http://expressjs.com/.
Adding some dynamism to the response. e.g Saying what time of day it is.
Responding based on the URL paths and query string.
Serving static files such as images and css.
After completing this many tasks you will be good enough to decide what next you want to do.
I'm thinking in create a framework, a little project with my friends, just to loose some time trying to build something, but we don't know where and how to start, then we are needing to know two things:
Which languages is possible to do this?
Where we can found some resources to begin(tutorials, sources...)?
All types of help are very welcome. Thanks.
You can use any language (that provides a mechanism for creating libraries) to build a framework.
Learn the language and development platform of choice, first. Creating a framework is just creating a library that provides a useful foundation for people.
Just trying to "Set out to build a framework" is probably not going to be too successful, however. Typically, a successful project, especially one being done for fun, is one that fills some need... Think about what you are developing, or what you want to develop. Create a project that is exciting, fun, and useful for you.
If, in the process, your project gets large, you can always pull out the building blocks and turn it into a framework for other people to use, as well.
You can create a framework in just about any language in existence, with a few common sense exceptions (such as a web server in Javascript). The most important thing to remember is that in order to make code reusable, you have to first make it usable. Your framework really has to make something simpler than doing it the original way.
Just curious, what kind of framework are you thinking about making?
If you don't know where to start, what to do or how to do it, why not join an open source project of your liking? It'll be a great starting point. You'll have the chance to observe how to design frameworks, what are the challenges, practices for writing code, and answer a lot of other questions along the way.
Then, when you'll have a concrete idea about building something, you'll already have a lot of useful knowledge on how to make it successful.
Looking around the horizon of the web server side, I see that scripted languages like PHP are quite popular,
probably due to the speed of development and ease of programming.
However scripted languages are human readable so isn't code security would be an issue here.
I would like to know that if I am keen of security of my code on the server what server language/technology would be most suitable.
When you use any server side language, only people with access to the FTP protocol (or SSH), can see the files. When you are regularly browsing the web, you cannot see PHP, or any other scripting language.
In terms of the actual language security, little bugs can be found, but you will get that in every language.
The security of your script depends on how you design it.
For the most part, every language is secure, but not every programmer is.
scripted languages are human readable
so isn't code security would be an
issue here.
No, users on the web will never see the code of your serverside programms - unless you publish the source.
Some security problems in web applications stem from the type of language used on the server side: buffer overflow is a security problem typical of C. So a scripting language would actually be more secure in this regard.
Typical security problems in web apps today stem from the interaction of client, server, database and user-entered data:
SQL Injection
Cross Site Scripting
Cross Site Request Forgery
...
A modern Web Framework like Ruby on Rails (or many others) will help you avoid some of these problems. But you still will have to learn a lot about web security!
"Staying away from Javascript" is a bit like "staying away from cars" because they are dangerous. Javascript is an integral part of modern web applications.
All serious (ignoring Piet, Malbolge, etc) programming languages are human-readable. Whether or not an explicit compilation step is required has no effect whatsoever on application security.
If you want to be very careful about security, use a language which supports easy verification and/or proofs, such as Haskell or Ada. A typical web application probably would be OK with a modern dynamic language, such as Python or Ruby. Java and C# are also popular, for performance reasons. Any of these will make developing secure applications significantly easier than in legacy platforms such as PHP, Perl/CGI, or classic ASP.
Lastly, as a small pet peeve -- PHP, Python, Ruby, Perl, etc, are not scripting languages.
I would say that the only really safe way to protect your code is by using ISAPI or CGI, and developing the application with some hard compiled language like C, C++, VB 5 or higher but any .NET, Delphi 5 or higher and so on. Any bytecode or interpretated language can be decompied, no matter what you do. New obfuscation methods may hold the crackers for a while, but they will always find a way to get the source. The source is there, the decompilation routine is there, the source must be revealed to be used by the framework, so all the crackers have to do is to catch it on the way.
the language has a small part to do with it. however, a lot has to do with how you actually design and write the code.
ASP.NET get compiled into dll's, so the code is not human readable on the server. But even in PHP, the code gets executed on the server.
Just stay away from JavaScript as that is visible on the client, and human readable.
My main preference is .NET, however even with the scripting languages like PHP they are not seeing your raw code unless you're giving people access to read the raw code files. I've seen some very secure PHP sites. If you're concerned about what people can see and access, then you need to watch what you are putting into the client side scripting languages like Javascript.
For 'hiding' the code there are a few different languages that support this. .NET languages can be compiled, which generates DLLs without containing the original source code on the server. These, however, can be read with something like .NET Reflector, so to escape that you would run something like Dotfuscator on your code, making it more difficult to read.
For PHP, there are solutions such as ionCube that encode your script and they must be ran with an additional decoder on the server to execute them. Usually this is used when reselling scripts, so clients can't look at or modify the source.