-1

I understand Web API. I understand websites, how they call a web API and all the good stuff. My question is, how do you control the user view in the website consuming the API, based on the API permissions. The goal would be to not have the view in the website if the user is not authorized to preform such action. Not just do a trick and hide it the HTML (Tech-savey user can see html code for actions/data forms they shouldn't).

Simplified Scenario: User has access to API to create other users, but not delete. They can technically send the delete verb to the URI, but they would get access denied. The goal would be for the HTML website to not show the delete option in the first place, as they cannot preform the action anyway. As well as no way of knowing via the website HTML/JS to see where the delte option is/how it works (Of course the delete view shows to users with that permission set)

Idea's: Have API support sending the HTML code for views on the site based off permissions. -Not a big fan of this as I feel it sorta breaks the idea of the API. What if I need to do something similar on a mobile app?

Use server side code as intermediary to call the API and build the view. -Im not sure about this because I feel it will require a redundant amount of work, but may be the best option.

I am using c# .net for this, if that matters. Preferably strictly HTML JS for the website, but don't believe thats possible unless sending HTML from the API.

  • Just a thought: for a client to know which UI parts to show or hide the API must expose the allowed actions in the first place. Not all API's do this, does yours? – Kwebble Aug 10 '17 at 19:23
0

The goal would be to not have the view in the website if the user is not authorized to preform such action. Not just do a trick and hide it the HTML (Tech-savey user can see html code for actions/data forms they shouldn't).

I agree with you. That would be the ideal case to me too. However, I consider this to be implementation details. There's nothing wrong in hidding the HTML code, as soon as the API implements authorization and authentication.

A tech-savey doesn't need to look into the code. For example, he/she can track the browser connections and try for each URI of the API, different HTTP methods. Basically, he/she can bypass the client and attack the API from any other application (curl, Postman, java client, etc...)

how do you control the user view in the website consuming the API, based on the API permissions

Anyways, if the API stick with REST, there should be possible for us to achieve what we want. What we need first is to know what actions are we allowed to perform. This should be possible with the method OPTIONS. 1

Authorized

OPTIONS /rest/api/product HTTP/1.1
Host: example.net
Authentication: ...

HTTP/1.1 200 OK 
Allow: HEAD,GET,DELETE,OPTIONS

Unauthorized

OPTIONS /rest/api/product HTTP/1.1
Host: example.net    

HTTP/1.1 401 Unauthorized

This is easier to say than done. It might result in many more calls to the API than the initially expected.

A way to solve the previous problem with OPTIONS could be implementing HATEOAS. In other words, we could make the API more descriptive.

Implementing HATEOAS the API response doesn't only provides resource representations. It also provides links to more resources. Links can be as descriptive as we deem it appropriated. For example, look at the PayPal API model.

The view would populate its controls according with the links. No link, no control (button, form, etc.)

Regarding your ideas, I agreed too. I would not mix API and views. Every client has its own concerns and these concerns -IMO- should be addressed independently. The more agnostic is the API to these problems, the better.

As well as no way of knowing via the website HTML/JS to see where the delte option is/how it works (Of course the delete view shows to users with that permission set)

I will assume that we already solved the problem with the HTML block. According with your conocerns, the user still could look at the JS code. Yes, and we can obfuscate the code too.

On the other hand, if we don't want users bulding their own clients, we can (should) provide them one. For example, like Google does.


1: According with the Allowed methods, we decide what to do. Just remember that Javascript can hide DOM elements by altering styles, but it can also add/remove elements dynamically too.

|improve this answer|||||
0

Why do you care if the HTML / JS has the delete functionality in it hidden? I can tell you that assuming you have a REST-style API, any person who will look at your hidden button and understand the why / how / when of it becoming visible will just be able to guess that the DELETE HTTP method against the resource will be the way to delete the thing. I want to understand the threat model that you have where you think that hiding the button and checking perms server-side aren't good enough. So my answer would be: don't. The extra complexity isn't worth it.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.