The guy has his point. Imagine you have an app that just does stuff like chatting, bla bla. But behind the scenes that app is monitoring users, it has lists and charts with the user data. You may not want to expose that.
You don’t necessarily get the data. But you know what the app can do. And for example if you have a super succesful app, it’s enough for someone to dig into the code, and “expose” what your succesful app does.
This is why a MICROSERVICE architecture is suitable in this case. @0nizuka looking at you.
And also you can add an nginx password as well, to ensure aditional security
The thing is, if we find a way of delivering js modules by methods (or something), then I believe the problem is solved. Once the user logs in, you do a meteor call, you get a big string, you “eval” it client-side. Voila.
Right. Because by hiding user tracking software, it has never been exposed anywhere at any time.
Here’s a thought: If it’s something shady you need to hide from your users because it might upset them … then maybe doing said shady stuff isn’t such a great idea in the first place.
I have yet to see a single valid security concern raised in this thread about the public nature of the structure. But, assuming there is one, I present the following notes:
At no point do you actually provide HTML to the client. What is loaded up is spacebars compiled (or react compiled). This is equivalent structurally to a Java or C# application which has all the display logic in it (even if some would never be used in that install instance). This means that the user who wants to reverse engineer it has to do more than just “oh look, here’s their html that they plug data into.” They have to constantly clean everything up.
In desktop applications, if this kind of obfuscation was required (for whatever legitimate or not reasons) then separate applications would be constructed (possibly out of the same code base). You can use meteor package system or imports to selectively import different portions of the code you intend to use depending on which version of the app you are working on / deploying.
At far more “risk” is your data which a skilled developer can find a way to get at if you are storing it anywhere on the client. Any kind of client side security should be pursued only after server side security is implemented.
The answer in meteor is microservices. You have different applications (on different paths) which provide access to different pieces. You can implement some kind of html only cookie that can be read on the destination server as part of the initial load and can be used to allow the initial load or throw a 403 or even a redirect back to the other microservice. For more information on request level security and redirects I would start here.
I agree with @0nizuka concerns in general. The request is very simple - share only necessary amount of code at a certain point. Possible solutions that I see is to divide application to sub-applications (for example extract admin completely out of the app) or any kind of incremental loading (which I have not found though)… maybe someone suggests any?
I’m trying to split my code in local packages and build multiple apps. I my particular case, an application for the login page, and an application for the rest, but I haven’t tried it yet. The goal is to obtain meteor’s session cookie from the login-app and redirect to main-app.
