This has been asked in similar forms here and here but it seems pretty important, and the framework is under rapid development, so I'm going to raise it again: Assuming your login page needs to face the public internet, how do you prevent Meteor from sending all of the authenticated user templates to a non-authenticated client? Example use case: You have some really unique analytics / performance indicators that you want to keep secret. You've built templates to visualize each one. Simply by visiting the login page, Meteor will send any rando the templates which, even unpopulated, disclose a ton of proprietary information. I've seen two suggestions: Break admin into a separate app. This doesn't address the issue assuming admin login faces the public internet, unless I'm missing something. Put the templates in the public folder or equivalent and load them dynamically. This doesn't help either, since the file names will be visible from other templates which will be sent to the client. The only thing I can think of is to store the template strings in the server folder and have the client call a Meteor.method after login to retrieve and render them. And if you want them to behave like normal client templates, you'd have to muck around with the internal API (e.g., Meteor._def_template ). Is there any more elegant way to do this?

Reputation: 222

Meteor.js - Template Permissions

This has been asked in similar forms here and here but it seems pretty important, and the framework is under rapid development, so I'm going to raise it again:

Assuming your login page needs to face the public internet, how do you prevent Meteor from sending all of the authenticated user templates to a non-authenticated client?

Example use case: You have some really unique analytics / performance indicators that you want to keep secret. You've built templates to visualize each one. Simply by visiting the login page, Meteor will send any rando the templates which, even unpopulated, disclose a ton of proprietary information.

I've seen two suggestions:

Break admin into a separate app. This doesn't address the issue assuming admin login faces the public internet, unless I'm missing something.
Put the templates in the public folder or equivalent and load them dynamically. This doesn't help either, since the file names will be visible from other templates which will be sent to the client.

The only thing I can think of is to store the template strings in the server folder and have the client call a Meteor.method after login to retrieve and render them. And if you want them to behave like normal client templates, you'd have to muck around with the internal API (e.g., Meteor._def_template).

Is there any more elegant way to do this?

Upvotes: 2

Answers (2)

dani

Reputation: 321

These 2 packages try to address this issue:
https://atmospherejs.com/numtel/publicsources
https://atmospherejs.com/numtel/privatesources

It uses an iron-router plug-in to load your specific files on every route.

The main drawback I see here is that you must change your app structure, as the protected files need to be stored in /public or /private folder.
Also you are supposed to use iron-router.

Upvotes: 0

zeroasterisk

Reputation: 2209

Seems to be a common concern, and I certainly think it's something that should be addressed sometime.

Until then, I'm planning on making a smaller "public" app and sharing the DB with an admin app (possibly in Meteor, possibly in something else, depending on size/data for my admin)

Upvotes: 0

Meteor.js - Template Permissions

Answers (2)

Related Questions