Sending your app into production


#1

So I’ve wrapped up an app for my company and I’m planning on sending it into production in the near feature. Right now it’s deployed in development mode (just hosted on a public server) so access to a lot of the client-side source code is available. My entire client and lib (basically all client-side code) is exposed to the browser. Of particular concern is my router config (along with my subscriptions) is publicly accessible. I’d like to mitigate this if possible. In addition, I’m looking for basic security features that would be nice to implement.

Long story short, any resources/links/tutorials on how to send your app into production without exposing so much information.

Thanks guys


#2

I’m not sure what exactly you are asking for. Anything that you send to the client, any JS that you make available and run on the client, is going to be readable (minified or not). That means if your router config must not be seen by your users, then you’d have to use server routing exclusively… but that would defeat a lot of the purpose of using something like Meteor to build a modern web app.

Put anything sensitive on the server-side only. Let the client interact with those parts of the app through Meteor methods that check for login status / user rights/roles etc.
Set allow/deny rules for collections, allowing only specifically what it is you expressly want the client to be able to do directly.
Deploy the app as a production build, thereby making it at least a bit harder to get at the source.
Limit the fields you send in publications using the fields option to find() (docs). Always use that option if you have sensitive information in a collection.
Publish only those records that you absolutely need, and no more.
Make sure your publish logic has checks and selectors in it that publish records only to those users who are entitled to see them.
Put routes that would reveal sensitive information about your app on the server and make them server-side routes. But most of your routes shouldn’t require that, otherwise it would show that there must be design flaws in the app, or the app really being unsuitable for implementation as a JS-based, rich-client web app.

Hope that helps.