Re: HATEOAS on demand

This topic seems irrelevant to the subject matter of the list, which is 
the registration of IETF media types (aka mime types).

Please take it elsewhere.

Harald

On 1/15/25 19:37, Owen Rubel wrote:
> Keep in mind I am also talking about securing the endpoints based on 
> ROLE... which you cant do if you hardcode them.
> 
> We have to take into consideration security and we don't want to just be 
> showing endpoints that cannot be accessed and even SHOULD NOT be accessed.
> 
> This create security risk, added traffic, etc.
> 
> So the give and take here is : securing HATEOAS requires making it dynamic.
> 
> Owen Rubel
> orubel@gmail.com <mailto:orubel@gmail.com>
> 
> 
> On Wed, Jan 15, 2025 at 8:36 AM Graham Cox <graham@grahamcox.co.uk 
> <mailto:graham@grahamcox.co.uk>> wrote:
> 
>      > And if being done dynamically, you may as well have it on demand.
> 
>     As a counterpoint to this. Remember that any code you write is code
>     you've got to maintain. It's not free.
> 
>     Yes, there are cases where you're generating hypermedia links
>     dynamically. But not all the time. Often the links will be
>     relatively static. (Self links or pagination links, for example)
> 
>     And even if you are doing it dynamically, adding extra code in to
>     check an extra condition to determine if you're going to generate
>     them or not is extra code to write, test, maintain, etc.
> 
>     Conversely though, the additional payload size from these
>     hypermedia links probably isn't huge, probably does compress well
>     under gzip if needed, and clients that choose not to use them can
>     easily just ignore them in the responses. And always generating them
>     just reduces the complexity of your server a bit.
> 
>     There's also the fact that, if you're going to write the code to
>     generate these links, you likely want clients to make use of them.
>     Putting them behind an extra gate just makes it more likely that
>     clients won't bother using them, which leads to even more code that
>     you're maintaining that isn't getting used.
> 
>     Just my 2p :)
> 
>     Cheers
> 
>     On Wed, 15 Jan 2025 at 15:46, Owen Rubel <orubel@gmail.com
>     <mailto:orubel@gmail.com>> wrote:
> 
>         Well thats the issue.
> 
>         A link can be accessed by different ROLES; an ADMIN ROLE can
>         access the same endpoint as a USER ROLE but require sending and
>         receiving entirely different data (see RBAC/ABAC)
> 
>         Thus hardcoding is NOT a solution for secure endpoints. They
>         have to be created dynamically to take this into consideration.
> 
>         And if being done dynamically, you may as well have it on demand.
> 
>         Owen Rubel
>         orubel@gmail.com <mailto:orubel@gmail.com>
> 
> 
>         On Wed, Jan 15, 2025 at 1:52 AM Asbjørn Ulsberg
>         <asbjorn@ulsberg.no <mailto:asbjorn@ulsberg.no>> wrote:
> 
>             On 15 Jan 2025, at 03:20, Owen Rubel <orubel@gmail.com
>             <mailto:orubel@gmail.com>> wrote:
> 
>              > so basically what I am saying is that since you hardcode
>             the links for HATEOAS, they violate security like RBAC which
>             defines what ROLES can access which endpoints.
> 
>             If you consider the existence and visibility of a particular
>             link in a response message a security risk (although that
>             sounds a bit like security by obscurity to me), or
>             performance overhead, then just exclude the link from the
>             response.
> 
>             The response can be tailored to each authorised client based
>             on RBAC, ABAC and any other configuration the origin server
>             may consider applicable to the given request.
> 
>             -- 
>             Asbjørn Ulsberg.         -=|=- asbjorn@ulsberg.no
>             <mailto:asbjorn@ulsberg.no>
>             «He's a loathsome offensive brute, yet I can't look away»
>

Received on Monday, 20 January 2025 21:31:27 UTC