Hey guys. The title provides the gist of it. Is there a reasonably straightforward way of making Meteor’s dynamic-imports dependant on authentication so that certain client-side modules would only be served to logged in users, or even more narrowly, only to users that have certain roles (i.e. tokens in their user document) assigned to them? The documentation on the dynamic-import package does not make any mention of this and I am assuming that there is no easy way of achieving this. It seems that whenever a client asks for a dynamic module, the server will just send it to the client no questions asked. Is this correct or am I missing something?
I am asking since I would like to make certain parts of my app accessible only to users that have administrator rights. I am of course already restricting access to relevant data, but in certain cases the view layer templates themselves already provide some insight into what is or is not monitored by the admins and ideally I would like to avoid that.
I think the problem is that this is easy to circumvent by calling import('/some_path_to_component.js').then.... in console, and peeking at the result.
For me, I don’t really worry about people looking at the admin code without the data. Sure, they might see something, but not much of any value to anyone. Depends on the use case though. I haven’t seen an easy way to restrict it.
Right… And seeing the source is what we are trying to avoid.
Ideally we’d have something like import("./some_module", { staffOnly: true }) which placed the import in some restricted area at compile time and checked the logged in user’s isStaff flag when it was requested. It probably brings along a whole host of other issues though, such as not being able to serve it using nginx anymore.
haven’t looked at it but if I was going to try to figure this out I’d probably look at monkeypatching the import HTTP handler and add a whitelist which only allows certain modules to be imported anonymously (if that’s necessary).
Do yourself a favour: Do not bother. Unless you restrict access to files on the web server itself you will not be able to restrict files from being downloaded.
You only add a possible breaking point for no real gain.
And by “restricting” I mean: Pulling the file completely out of the bundling process and putting it behind a webserver which uses .htaccess or .htpasswd or similar.