Possibility to restrict dynamic imports based on authentication


#1

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.

Thanks for any help.


#2

For example, with react

async renderSpecialContent() {
  if (Meteor.userId()) {
    const SomeComponent = await import('/some_path_to_component.js');
    return <SomeComponent />;
  }
  return null;
}
render() {
  return (
    <div>
      {this.renderSpecialContent()}
      something here
    </div>
  );
}

#3

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.


#4

Yes, of course they can easy view some source of that file, but without data and important thing in methods files.


#5

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.


#6

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).


#7

AFAIK nobody has done this yet

I’d start with a fork of the dynamic-imports package and see if you can add in checks from there


#8

Thanks for the feedback! Will look into the dynamic imports package. Although not really sure I want to be messing around there. We’ll see.


#9

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.