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.
Related
I am new to laravel and creating a REST API. The client of the API will be mobile app only. There is no front end view to be shown in browser. I have created the routes and the controllers to handle API requests. Furthermore I deleted the Users table (created by laravel) because I do not need an Web interface etc.
I just want simple token based authentication at this stage ( I am aware there is passport authentication) but I can not even understand that at this stage.
There is only one table in the project.
Candidates
(id (PK), name, phone, details)
mobile app users are candidates also, should I create a token column in this table ? and manually create token at the time of register API and return it back as response ?
Please any simple guide or directions will help, I have search quite a bit online and there seems to be quite a lot many topics that show up such as guards, providers, passport which I am struggling to get.
Thanks,
Elliot.
First of all, you didn’t need to delete the users table. You can use it for api auth too. You just need to create a seperate token table.
However, if you want to implementit manually you need to do a lot of things manually.
This is a huge thing to impelement manually and it's not possible to describe it in a single answer. I will try my best to explain it as simply as I can.
You have to create a authentication system yourself that is for login. Define a middleware to check the authorization of the token sent from client to check the validity of every request (this is the guard part).
Also keep track of the token expiry time. Refreshing the token after each expiry needs to be done too (this is the provider part).
Now there are a lot things inside. Like keeping track of the device the request is coming from, providing different tokens for differenet devices for a single user etc.
If you are into learning how everything works then you can try to build one yourself. But if you plan on deploying it to a professional website, I would suggest try to get accustomed with passport. Reinventing the wheel is really not necessary. I hope it gives you a basic idea. If you have any more questions feel free to comment.
I am a relatively inexperienced programmer.
I have managed to build a web api which uses basic authentication as per the following:
https://weblog.west-wind.com/posts/2013/Apr/18/A-WebAPI-Basic-Authentication-Authorization-Filter which is working very nicely (forced over ssl obviously). Inside the OnAuthorizeUser i check the un/pw against an mssql database, via a call to an internal class called "DB" where all my database interaction occurs.
So all Controller methods are filtered by the Basic Authentication ("decorated" at the Controller level) however, access to certain Controller Methods also needs to be limited depending on the user - so there is a need to understand the user permissions. Based on my limited former ASP.NET experience I think I would have stored the relevant user details in a Session (or possibly cache) however I have so far steered clear of this based on wanting to stick to the concept of having a RESTful application etc
Rightly or wrongly, in playing around I realised I could use a private static (instance?) of my User class inside my internal DB class and populate it at the time of initial authorisation. I also added a public method (public User getThisUser()) to return the private User. From within my Controller methods I create an instance of DB and am able to check the values etc.
I was very worried that I would have issues with the "scope" of this "static" User, so to test, I created a Controller method to simply return the User information from DB.getThisUser(). In doing so I have found that I can log in as multiple different users (using different browsers concurrently for example) and each one consistently returns the correct user information (as logged in).
I'm still not entirely convinced this is "safe" however reading through the details of implementing something like ASP.NET Identity as a possible alternative makes my head spin and really seems like massive overkill in this case - I'm not using Entity Framework and after much searching I could not find a single example of NOT using an ORM (I need a solution to work with an existing DB).
Is this destined to fail? Do I go back to considering session or cache? Something else? I would really appreciate any feedback / advice on this from all of you who are more experienced than me. Thanks in advance for any help.
i think you're getting a bit confused.
an API is supposed to be stateless, meaning no session. Yes, you have a controller which translates into an endpoint.
You can hit an endpoint with all the information required to satisfy the request and this is it. Don't think of an API as an actual application where all requests are linked somehow. Instead, think of it at an application where each request is separate and can come from anywhere and any user.
How does the application know which user sent a request? Well, it doesn't unless you pass that information in.
You don't fire a request saying GetMeUserDetails. The api has no idea what you want. Instead you would say GetMeUserDetails for userId 12345. Now, since your request contains all the information required to satisfy the request, the API can now give you what you expect.
If some calls require authentication, you might use some sort of tokens to identify the user, but again, the information is passed in via the token.
You probably realize what static means and how it works. you are not going to see problems until you try to send two or more requests at the same time and then you'll realize that the first call now contains the details of the second request because well, static ...
I'm designing an app that counts on accessing multiple API's that need the certain users credentials which are provided when a user allows access via OAuth. I'm new to designing programs like this and I'm trying to wrap my head around the easiest way to do this. Here is what I was thinking:
During the Oauth process I specify the callback url (lets call it A)
Create a POST route for url A that points to a function in the user controller
That function then parses the JSON data with the API Key+Secret, hashes the data, and stores it in a column of the user table.
Would this be the best way to go about this?
One thing I'll say is don't tie these directly to your users. Sometimes users may want to authorize multiple accounts, and sometimes multiple users may authorize the same account. Since you can only have one active refresh token per oauth account, these creds should be kept in a separate table and then linked with a many-to-many for flexibility
I was going through the Anypic tutorial and the data model part specifically because I want to build a similar app. My question is why can't I remove the permission restrictions and let the image class hold the likes (int) and the comments (array of strings) and don't allow the users of the app to edit other users images. What can be the drawbacks of this approach?
Thank you
The permission restrictions are in place for security.
By separating the likes from the Photo class, it prevents other users from modifying someone else's photos. The way Parse ACLs (Access Control Lists) work is by restricting read/write access.
Let's consider the scenario that likes are contained within the Photo class. If one user wants to like someone else's photo, they will have to modify the user's photo directly, which requires write permissions in the ACL.
No big deal, right? Wrong. Someone with malicious intent could structure their own REST API calls to your app and perform whatever actions they want on other people's photos. I could remotely modify or delete your photos, spoof additional likes, and tons of other exploits depending on the rest of your app.
If you still wanted to keep likes within the Photo class, but not have public write access, then whenever someone tries to like a photo, you would have to perform the write in cloud code using the master key. You would also need to do extra validation beforehand so someone else couldn't spoof this request.
Parse ACLs are great because they are incredibly simple and quickly allow you to compartmentalize read/write access as needed within your app.
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.