I am implementing something like Facebook posts, but I only want to limit it for users Alice and Bob to see, but John can't see it. May I know what is the proper way to implement this ? I tried googling but all I found is user based authorization, for IIS.
What I had in mind is to implement another table to add allow list, so if the allow list is empty I assume all users' friends are allow to see, but if there are users in the allowed list then only allowed users can see. However I think this might heavily increase the load of my db?
Related
In a handful of circumstances, I'd like to allow the Current User to be able view a list of records filtered by Owners of each record that are Direct Reports that they manage or even by the Manager they report to via our global directory.
I'm comfortable making a new Datasource for CurrentUser in a Directory model. However, I'm tripping over myself trying to find the best way to match an Ownership (email) field from a record, with an array of the direct reports associated with the current user.
A specific example would be on the Travel Approval template. The table on the Dashboard page has a filter for "My Requests | All" and I'd love to add a third option for "Direct Report Requests".
My assumption is that I would adjust the onClick event to filter results accordingly:
widget.datasource.query.pageIndex = 1;
widget.datasource.query.filters.Owner._equals = app.user.email;
widget.datasource.query.filters.Owner._in = null;
widget.datasource.load();
updateUrlForDashboard();
That's one small example, but more importantly, I'd like to get a better understanding of how best to reference/store those additional relationships about the Current User.
Ideally, a current user is able to have greater ability to manage (approve/deny/comment on) resources tied to their Direct Reports and generate records that provide a similar level of control to the Users that Manage them.
I'm not sure if that's best handle by some use of Roles or another approach. Any advice on how best to plan out that kind of setup would be much appreciated.
funny thing ... I had the same question a couple of months ago. I think you will find Pavel's solution on this very interesting. You can find it here.
I have a collection called Vouchers. A user can, if they know the unique number ID of a Voucher, "claim" that voucher, which will give it a user_id attribute, tying it to them.
I'm at a point where I need to check a user's ID query against the existing database, but I'm wondering if I can do so on the client instead of the server (the client would be much more convenient because I'm using utility functions to tie the query form to the database operation.... it's a long story). If I do so on the client, I'll have to publish the entire Vouchers collection with correct user_id fields, and although I won't be showing those ids through any templates, they would be available through the console.
Is there an inherent risk in publishing all of the IDs like this? Can they be used maliciously even if I don't leave any specific holes for them to be used in?
First, in general it sounds like a bad idea to publish all user_ids to the client. What would happen if you have 1 million users? That would be a lot of data.
Second, in specific, we cannot know if there is inherent risk in publishing your user_ids, because we do not know what could be done with it in your system. If you use a typical design of user_ids chosen by the user themselves (for instance email), then you MUST design your system to be safe even if an attacker has guessed the user_id.
Short Version: not so good idea.
I have a similar setup up: user can sign-up, if she knows the voucher code. You can only publish those vouchers where the user_id is identical to the logged in user. All other checks like "does the user input correspond to a valid voucher?" must be handled on the server.
Remember: client code is not trusted.
My requirement is :
I need to store all the details about a person manually by (for example)Admin.
Which Collection usage is best for above requirement means using Predefined Collection Accounts or User Defined Collection?
My Doubt is : If using Accounts package must be used password but my requirement doesn't contains password only person details.So what i can do for this problem using Accounts?
In case using User Defined Collection then how to provide security for this?
I didn't get any idea about this problem.So please suggest me what to do?
Create a collection, called something like "people", "customers", "students", etc (whatever makes sense for your particular use case). There are several important things you need to do to make it secure:
Use the built in accounts-password package to have your user log in to maintain the list.
Remove the insecure and autopublish packages.
Conditionally publish the relevant fields of the people collection, only to your authorized user.
Set allow and deny rules for inserting/updating/removing people documents. Your rules should check that the user is authorized.
Do not store sensitive information like passwords, credit card numbers, social security numbers, etc in clear text in your database.
Use SSL.
Read and watch these two links, where Emily Stark discusses security (specifically content security policies) in Meteor:
https://www.meteor.com/blog/2013/10/27/defense-in-depth-securing-meteor-apps-with-content-security-policy
https://www.meteor.com/blog/2013/08/02/meteor-devshop-6-devshop-live-security-meteor-ui
Remember that no matter what framework/system you use, there is no such thing as absolute, 100% security. You must use defense in depth to achieve the best possible security that you can.
I keep running into cases were I want to limit access to data rather than methods.
As an example, I have a users table. An individual user's record should be visible only to themselves, the helpdesk, and the user's manager. However, only the manager can edit the user.
I can restricted view and edit methods by the above roles using the authorization attributes, but then I still need to check and see if the current user has the ability to touch the data he is requesting. This is where the authorization attribute falls short.
I'm currently considering adding an "IsAuthorized" method to all of my models to check and see check if the current user is allowed to perform the current action, but this seems tedious in general, so I wanted to see if anyone else had a centralized way of doing this.
Thanks again!!
(Currently coding everything in ASP.NET C# MVC 4.5.)
There are several services which allow change of usernames frequently like Twitter, LinkedIn etc. Some other have very limited options (example: Facebook for two times). And rest does not allow changing usernames.
The major reasons I can understand is, records are kept against usernames and the URL are cached by search engines against the username. But to solve the first problem, which is much vital, applications can use userid instead of username.
Is there any other important issues/reasons for which I should consider disallow changing usernames?
the main issue is social engineering. people associate a reputation with a name (both the user with the name, and the people who interact with them). if you allow names to change then there is less social pressure to preserve a good reputation and more "bad behaviour".
it's all about coercing users to invest social status in a persistent identity. technically they could implement a system that supports name changes (for example, you could use an arbitrary, unique, auto-generated ID to represent the user in the database/cache/file system and display some (user modifiable) string from the database when showing the name in a web page).
There are technical reasons behind some sites disallowing namechanges, such as if the users have the ability to store files, changing the username may break it if the file paths are based on the usernames. However, a good implementation uses user IDs instead, and avoids such things. For the most part, its a social matter of keeping a permanent link between a user's name and an account. Giving the user the ability to switch names gives other users the ability to impersonate them, or steal their name, and makes it difficult to find people sometimes.
I'd also like to note that there is a difference between login usernames, and nicknames. What you are calling 'username' is moreso a nickname if it can be changed, and usually sites that let you 'change your username' are only letting you change your display name - your login remains the same. Steam is a good example of this, it allows you to change a nickname, but your login name can never change.
I have recently came across this dilemma whether to allow user to change username.
I have entered it on my blog: http://www.dizkover.com/post/423/programming-why-not-to-allow-users-to-change-username-in-social-web-application-design