Let us say I have multiple users. They all have items linked to their account. They can CRUD those items.
What is the best way to prevent users from manipulating items from each other.
At first I thought the antiforgerytoken would help. But it does not because when the users look at their control panel they get a valid token. So they could just open firebug and do some post requests to delete items.
While writing this I think I know what I should do. I guess I should just check on the server if the user is deleting his items.
Did I forget anything which would still make it possible to adjust each other's items?
The only way to be sure is to check on the server that the current user has permission to "do action"
You can use the "Roles" mechanizm (this feature ships with asp.net) to check whether a user can delete other accounts.
Related
I am building an API where users and admins can interact with the same data, but with different needs.
A user can also have access to the admin panel, if he has the "admin" role.
Let's see for example we have a resource like Badges. A Badge is simply a reward when you achieve some actions into the app.
GET http://localhost/api/v1/badges
An authenticated user can call this endpoint and it returns the list of all badges, if they have it or not, with progress details.
GET http://localhost/api/v1/badges?user_id=2
with user_id parameter, we can see these details of another user (if he allows it).
But from the admin scope, I just need to see the list of all badges, without achievement details (CRUD operations).
So I have 2 options in mind:
Create "admin" endpoints: GET http://localhost/api/v1/admin/badges.
Adding custom header "X-App-Scope" to identify if I am in admin or user.
I don't like the second one because I think I will have so many if statements and behavior in the same endpoint, depending of the scope.
Because I have lots of use cases like this, I want to make sure my API architecture is good to handle user/admin needs.
Do you guys have any idea/example to manage stuff like this?
Thanks!
My personal preference is to separate admin API routes from user ones. i.e. having two routes
/api/v1/badges
/api/admin/v1/badges
You will have two unique documentation, one for each route, which makes it easier to maintain and understand
It will be easier to tell the difference between the user and the admin versions
There is no need extra code to check for request headers or url params.
It makes your middleware less complicated, especially if authentication and permissions are handled there.
It is more scalable for teams as there is only one kind of request and response format per API.
TL;DR: REST is designed in the expectation that you would use two different resources here.
The core problem is this: how would a general purpose component, like a browser, know that your special resource needs to have this custom header added?
In particular, consider the case where I send to you a copy of the URL for this resource, and nothing else. How are you to know to add the customer header to the request?
On the other hand, if you use different resources to share this information with each audience, everything just works.
The only way I found to stay as simple/clear as possible is to make multiple endpoints, for each use case:
GET http://localhost/api/v1/badges to get all badges in raw data
GET http://localhost/api/v1/users/badges to get all badges with user stats (progression, achievement...) in a transformed format
GET http://localhost/api/v1/users/{uuid}/badges to get all badges with user stats (progression, achievement...) in a transformed format for the specified user, if his profile is public
Now I have a lot of /users/XYZ endpoints, but my code seems easier to read & maintain, and I don't really need to see the code to guess what data will be returned, the conditions, etc...
I keep wondering how the other APIs are written when you have an admin section, because having /users everywhere isn't really "pretty", and I don't see that anywhere else.
We are having trouble with the Google Consent Screen (oauth2) where the scopes we are requesting aren't ticked automatically.
This is leading to users telling us that they have given permission, but they actually haven't as they weren't aware they needed to tick the boxes in order to give permission.
Is there a way to have these checkboxes pre-ticked? Or perhaps not allow users to tick/untick them? Just give users the option to accept or not?
Thank you!
We are having the same issue here. As a temporary solution we reduced the amount of the scopes (checkboxes) to only one https://www.googleapis.com/auth/drive, which is enough to view/create files in drive (didn't test deletion/update though).
I have a laravel webapp and I check if the user can perform certain actions or access certain information at every step of the way not just during the login. For example when they wish to view their assets I check for their UAC, after they click on them I check again, even if the edit, delete buttons are not visible, there is still a check in place in the code. And this pattern continues throughout the whole webapp. Is this overkill, will it make my webapp too cluttered with checks all over the place?
Yes, it is. Every time you don't check for access before performing a privileged action, you take the risk that an intruder might find a way to bypass your earlier checks and somehow trigger that action without actually having proper access to it. A few extra checks are a small price to pay for robustness and peace of mind.
In particular, you should always re-check privileges on the server for each new request made by the client, since you should never trust user input, and since everything the client sends to the server is potentially under the user's control. For example, even if you disable the "edit" or "delete" buttons in the client interface, what's to stop a malicious (or even just inquisitive) user from re-enabling them e.g. through their browser's developer tools, or even from simply spoofing the actual edit/delete request that the button would trigger?
If you're lucky, all a missing server-side privileges check will do is let some user see a bunch of deleted garbage. If you're not so lucky, it might give them full admin access on your site.
It is indeed a good practice and middleware can help you achieve this goal more easily.
Check the Laravel documentation for more information
I have implemented many multi site implementations in the past, so I get how to set up the environment. What I haven't done, is set up multiple websites that can share the same cart session.
So if you are on site1.com and add something to your cart or are logged on, when you go to site2.com you are logged in and have the same items in your cart.
From what I read around the forums, well there isn't much about the best way to share session. But I do know that using the configuration to enable SID on the frontend will pass the session id if you transfer between sites. I figured this is all you need to have, but I see where people are saying that only stores can share checkout sessions and that stores can have their own domain.
I am thinking the best way to do this is to setup multiple websites not one website multiple stores and then just make sure when linking to the other site, I use proper magento url methods to build out the link and it will pass over the SID and the users session will be transferred over.
Is this the preferred way to do this? Is there anything I need to know in terms of configuration? Is there any negatives doing it this? Is there a better way?,
Well if you want to have such possibility only for logged customers then i propose to you to use sales_flat_quote table which is represented by Mage::getModel('sales/quote').
With this model you can manage cart and focus only in passing customer identifier which would bring us to security subject... How would you pass customer identifier in secure way as SID isn't very secure.
Plus SEO doesn't like SID in URL from what i've heard.
On a website I am building I need to allow users to edit their orders. Easy enough. But how do I ensure that a user cannot edit other users' orders? Do I perform checks in the model or in the controller to verify that the order belongs to the authenticated user?
Put checks in the view (yes, the view) for rapid response to user errors.
Put checks in the controller to ensure data integrity.
For example, in a web based app, you might have browser javascript to check all fields, including username, so the user gets rapid response to fix erroneous transactions. However, back at your server, you can not rely on the browser to really validate the data, since the browser is outside your control -- it might be corrupted, either intentionally or accidentally, and not doing validation as you intend. Thus you need to revalidate everything on your server to ensure integrity.
Well hopefully your site doesn't have any way for a user to even attempt to edit someone else's orders. But if it's still possible to try, you could put that logic in either the model or controller. It's a matter of opinion. Some people will say that the controller should do things like access checks, and the model only knows how to modify itself. Others will say "fat model, skinny controller" and say that the security checks need to be reusable across controllers and so they should go in the model. It's your call.