Due our business model we had to set for every record in the model: an
attribute ownerID and a groupID. As always, people from the same team can see their mates records but not those from the other communities.
I have the user's groupID in a session variable for each call coming from the front-end given all possible requests have to be authenticated.
I've been thinking about that but I cannot find a nice place to set a piece of code to make Sails just return user's community records for every model.
An option is overriding all default methods for all controllers, but I think it's not necessary to override all find, findOne, etc methods to adding this simple restriction given it should be applied for ALL models. For sure there's a more elegant way of reaching this using hooks or any policy but I dont give with that.
My goal is if I get /houses just return the houses from the community of the authenticated user even if are all together in the database and apply this restriction for ALL models.
I hope you can understand...
Thanks in advance!
Related
I'm having a bunch of apis which return several types of data.
All users can query all data by using a GET rest api.
A few users can also change data. What is a common approach when designing REST API, to query only the data that can be changed by the current user but still allow the api to return all data (for display mode).
To explain it further:
The software manages projects. All projects are accessible for all users (also anonymous) via an api (let's call it GET api/projects).
A user has the ability to see a list of all projects he is involved in and which he can edit.
The api should return exactly the same data but limited to the projects he is involed in.
Should I create an additonal parameter, or maybe pass an http header, or what else?
There's no one-size-fits-all answer to this, so I will give you one recommendation that works for some people.
I don't really like creating resources that have 'complex access control'. Instead, I would prefer to create distinct resources for different access levels.
If you want to return limit results for people that have partial access, it might be better to create new resources that reflect this.
I think this might also help a bit thinking about the abstract role of a person who is not allowed to do everything. The abstraction probably doesn't exist per-property, but it exists somewhere as a business rule.
I am using eloquent as part of a slim 3 project with slim-jwt-auth (https://github.com/tuupola/slim-jwt-auth), outside of Laravel. There are many situations where I want to control the items returned based on the user who is making the request.
From what I understand though, there is no way to add extra parameters such as user_id for use in eloquent global scope.
I found one blog post that initially looked helpful,
as it does exactly what I am trying to achieve (http://www.sdavara.com/Eloquent-Global-Scopes-A-cool-and-easy-way-to-fetch-loggedin-user-data/), but it relies on Laravel Auth.
The fact that my solution needs to work globally is important, as I have many nested relationships that should also be filtered by user id when queried.
Could anyone suggest what might be the best approach for achieving this?
I am creating a web service using Meteor.
I am designing the model, and I have stumbled across a difficult problem: Mongo is not designed to work with joins. However, I must logically associate a user with a subscription (which is an object that has many properties in it).
Therefore, my question is this:
Should I embed the subscription model into the Meteor.users collection, or should I create a new collection called "Subscriptions" and fight my way through manual joins? The reason why I am hesitant to use the first solution is that Meteor.users is a collection that is being handled by Meteor's Accounts and Password frameworks. Sure, you can embed a "profile" object upon creation, but how is this method going to scale up afterwards?
I would appreciate any insights on this..
I use the Meteor.users collection to store custom data all the time, there's nothing to prevent you from modifying it by adding additional fields, just keep in mind the following:
There are certain fields Meteor treats specially, be careful not to break them.
By default a user is only allowed to see their own profile, username and id, you'll need to write your own publication if you want the user to be able to see other fields, such as a custom 'subscriptions' collection.
Several of the Meteor used fields are security sensitive, when writing logic to allow a user to update subscriptions you need to take care that you don't allow a user to edit those fields.
http://docs.meteor.com/#meteor_users
Update:
I'm not entirely sure about the performance implications of adding subscriptions to a user record, since I don't know exactly what you're going to store in the subscription, or how you want to use that data. We tend to use user specific subscriptions a lot in our apps, eg:
Meteor.publish({
'userSubscriptions': function () {
return Subscriptions.find({userId: this.userId});
}
})
I'm bulding a small web application using mongodb and just thought if it's a good practice to show mongoIds publicly, in urls for example.
Now I'm using the following url structure for user profiles: http://example.com/user/MONGOID
Does this have any security flaws or is it discouraged in some other way?
The answer depends on many of things...
Using an ID in a URL is generally a bad idea. According to OWASP, it ranks #4 in the top 10 web security vulnerabitiy list. But using it will not ruin your project.
To prevent the security vulnerability, you must either :
Use it only on data that is public (like StackOverflow profiles)
Have some code intercept the request and validate that the user has the rights to see the resource (a profile, a page, a document, etc.)
Using _id It also ties your public URL to the back-end. You will need some conversion if you change database technology. Or maybe you will need to run some changes that will result in the object being destroyed and created again, but with a different _id, like merging databases or something. You don't want your URL to change because of that.
Another thing is that _id does not have a good spatial distribution. It does not make a good sharding key. Being derived from a time stamp, all _id are close together, linear if you will. They will tend to go in the same shard (Mongo will spread them later, but you want a key that has high cardinality).
So I prefer to pay now, and use a id field that is private to the application from the start. You can store it in the _id field if you want, but consider adding another key to your document, index it, and use that in your URLs.
No it does not have security implications.
All the person would be able to do is to guess the Id of some user or to try to go through all Ids to get all users of the system.
Take stackoverflow as an example. They have the same pattern as you: http://stackoverflow.com/users/352959 this is 352959 is you and there is nothing bad with it. The only thing that whenever you will enter this in your browser you will be redirected to http://stackoverflow.com/users/352959/king-julien.
I can try to iterate through these numbers and the next guy is http://stackoverflow.com/users/352960 but all I can found is that this is some john. And surely http://stackoverflow.com/users/1 is the creator of the resource.
I have a client-side interface that allows the user to perform multiple edits against a tree-like outline. I consider the aggregate of the records making up that outline, in totality, a single resource (/outlines/39) even though its parts could be accessed as separate resources via different URLs.
The problem is the user can edit existing nodes in the outline as well as add new nodes to the outline. Normally, when you edit something you PUT its changes and when you add something new you POST it; however, in some cases you'll want to wrap all the changes--including both adds and edits--in a single transaction. What are some practical ways people have handled this?
Even though the outline already exists and a PUT seems appropriate, the embedded adds violate the idempotence of the PUT. I'm not sure that POST seems appropriate either. For design purposes, I have decided not to save each discrete update the user makes though I guess this offers one solution. Still, there must be others who have dealt with my issue or have ideas about it.
Is there any way you could make the add idempotent? E.g. if nodes had a natural key, then when the client tried to add a node a second time you could do nothing.
How about: make a new resource: /outlines/39/transactions, and POST your transaction to that resource, e.g.
POST "addNode=node1, addNode=node2, editNode=node3,newName=foobar" to /outlines/39/transactions