That’s not completely true Rob. It’s a problem with single page app that don’t do incremental loading.
If you go on gmail landing page and are not logged in, you wont see anything from the actual app (in this case it’s a simple redirect).
True, if you haven’t loaded any javascript it’s not visible, but I stand by my statement: “javascript in the browser is completely visible”: if you have an app with loaded javascript on your browser, that javascript is visible.
For those that don’t understand what security problem could be at stake.
- Let’s say i’m a startup having a product with innovative features in beta. Only people who have signed an nda are authorized to login and see what’s the app is about. Do you see the problem ?
- Let’s say i have developed an entreprise app for my employees with different rights based on their level in the organization. Employees with higher level can see whole parts of the app that other can’t see. But i don’t want those with limited rights to know this. How do i do if everyone can see the code ? How do i do if everyone can see my admin panel where there is a checkbox that allow me to give or not give the rights ?
- Let’s say i have developed an app for a biological examination laboratory. I want to give to the clients of the laboratory an url “fooCorp.com” so that they can look after their results without other knowing that this url they are visiting with their credentials is about biological tests. How do i do that ?
2 Likes
Yes, but that was indeed the question, how do you prevent the server from sending code to the unauthorized user.
With javascript you perfectly can, but not with meteor.
Ah, OK, I see what you’re saying.
I would look at solving this from a data perspective. Let’s say I want to present the user with a list of things s/he can do. Do I do this by having all list options available on the client and concealing “secret” ones, or do I send the specific list of options from the server and let the client render only what it’s given?
The code for both is available to view in the client, but there is no way to find out what else can be done without access to the server.
Yes i suppose you could do that, have all your options names in data, only do logic through remote procedures (methods), only use generic names “doCalculation”, “checkInput”, but it would probably be a PITA to code, and it would bring us back to the “terminal app” style, and less “wep app”.
1 Like
I was thinking precisely of this, but for login, not for signup.
@vjau
Thanks for explaining way better than me my concerns 
1 Like
[quote=“vjau, post:23, topic:30457, full:true”]
For those that don’t understand what security problem could be at stake.
- Let’s say i’m a startup having a product with innovative features in beta. Only people who have signed an nda are authorized to login and see what’s the app is about. Do you see the problem ?[/quote]
Then you hide the whole app behind a password screen through htpasswd. Done.
And the problem of this is exactly what? So they can see a button: “Fire this employee!”
And?
That’s called “security through obscurity” which is always a bad idea. The URI is publicly visible whatever you do so I’m not really seeing the point. Unless you’re tweaking a local DNS server to respond to requests from certain IPs or something.
Listen, guys, I’m seeing a lot of hypothetical gnashing of teeth here but not a lot of concrete stuff to go on. I mean, take the 2nd example in the list I quoted: “Different rights for different levels”.
Can you give me even one concrete example of where someone knowing something about the structure of a webapp can somehow do harm?
And don’t give me “MilSec”, “CIA stuff” or something like that. Because in that case you’re doing it wrong already.
This community was very friendly at the start. But with days and days (and the early adopters disapearing), it becomes less so.
I’m merely disagreeing with your premises and am asking you to provide some more arguments for your case.
If that counts as being “unfriendly” then I can’t really help you.
I think I can be consider an early adopter and I’m not going anywhere 
. [/offtopic]
2 Likes
I think it’s a healthy debate and don’t see where it gets unfriendly. I’m actually unclear if the concern is unique to Meteor or a trait of all SPA frameworks (Angular, Ember, etc.).
1 Like
I think it’s actually a trait of all single-app JS frameworks. Even with code splitting, you still to know which files to load, and that would probably be stored in the main codebase. So a curious person could still easily extract all sources from the server even if they are not included in the main code.
I think I understand you, but I’m sure @rhywden comments weren’t disrespectful. A bit aggresive maybe 
Knowing the structure of a webapp could be harmless as you say. That doesn’t mean I’m willing to make it public.
If you are asked to build an Extranet with Meteor and say to your client “the whole app will be served on the login page”, do you think he will like that? How could you convince him there is no risk?
So I’ll ask to you the original question I made: should I publish all my app in the login page? Is this potentially harmful? Imagine I’m that client I described. Don’t answer how to solve the problem, there are plenty of solutions. Convince me that there is no risk.
Maybe JS-SPA should have a way to render different SPA depending on roles or authentication, instead of having to implement non JS-SPA solutions (although it may not be a big deal). I’m thinking of a wrapper that makes use of meteor build system and serves the compiled app depending on the route requested. Meteor compiling meteor. What do you guys think about that? You think it can be done? Or, did someone implemented this yet?
BTW, right now I will be using nginx auth_request and work with meteor’s login token and two meteor apps: one for logging in and the other to serve the actual app.
We already explained that to you: It’s the data and the access methods to the data you need to secure.
If you do that then your app is secure no matter what kind of structure you’re publishing on the client.
If you don’t do that you’re screwed regardless of whether you publish the structure completely or partially.
If I’d be the client, I wouldn’t be satisfied
“But I don’t want people looking at the app if they haven’t logged in!, I don’t want them to know I have a Private area that lists pron!”
Nah, it’s ok. As I said, it’s mainly a matter of opinion. I consider a user that is not logged in an app should see nothing. You say it’s ok 
And what kind of business would that be exactly which would need to hide a porn area?
one with a really pervert CEO xD
But that’s not the subject hahah.
In a world of possibilities, I think exposing intimacies can derive in a security issue like, dunno, being blackmailed. But that’s just an opinion.
1 Like
That’s still a vague generality. I’m still waiting for a concrete and real-world example.
I i knew how, I wouldnt be asking this. I would be trying to solve it. If you want to make your private layouts, schemas anf subscriptions public, go ahead and do it. But you won’t be doing it, I know.