I have a question about how server-side JavaScript works.
Context
- My website has multiple user authorization levels. These auth levels determine which pages a user can see on the client and which methods a user can call on the server.
- Each user object (er… document?) in the database has an auth field that stores a number representing that user’s access level.
- On server startup I create two auth objects that will store user auth booleans for pages, methods, etc. One object is for the client and one object is for the server.
- The values in the auth objects are set when a user logs in or navigates to the site.
Question
My intention was that each user would have a client auth object and a server auth object that stores that user’s credentials. I think that this will work fine with the client auth object because a unique object will be created for each browser connection (right?). However, I’m starting to think that because I only ever create a single server object, every user will always have the same server/method permissions (whatever’s currently set in the server-side auth object). Is this correct?
If so, I can fix it pretty easily by creating a unique server-side auth object for each user upon login. I just want to make sure my intuition about server-side objects being shared is correct before first.
Any insights would be appreciated. Thanks!
You are correct in that objects on the client are technically unique to that client and objects on the server which are in the global scope are shared.
However, I wonder if you’re overthinking the solution? In Meteor, methods and publications are user-aware, which means that it’s possible to perform operations and return data which is specific to a user. That means that data which is shared (such as that held within the Mongo database) can be made available only to the user who owns it.
Basically, the userId in a document gives the ability to manage access to that document.
Ah, thanks for confirming!
I’m not concerned with returning data so much as preventing method calls that make use of external services. The server authorization object determines whether the client is authorized to call maybe two dozen different method calls. The method access levels aren’t exactly straightforward (for example, only users with access levels 1 and 2 might be authorized to call methods in category, A while only users with access levels 1 and 3 might be authorized to call methods in category B, while only users with access levels 2 and 3 might be authorized to call methods in category C). I didn’t want to have arbitrary conditionals strewn all over the place so I opted to centralize authorization management with an object that sets user access levels on the server during login. Methods check the corresponding property in the object to determine whether a user is authorized to call that method. More conditions are going to be added as the product grows, and conditions may change if we change the user packages offered, so I figured centralizing permissions in an object was more maintainable and less likely to cause error than having complex arbitrary-looking conditionals all over the place.
However, if you still think there’s a more appropriate solution then I’d love to hear about it. Thanks for the help.