Re: HATEOAS on demand

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


On Wed, Jan 15, 2025 at 8:36 AM Graham Cox <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> 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
>>
>>
>> On Wed, Jan 15, 2025 at 1:52 AM Asbjørn Ulsberg <asbjorn@ulsberg.no>
>> wrote:
>>
>>> On 15 Jan 2025, at 03:20, Owen Rubel <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
>>> «He's a loathsome offensive brute, yet I can't look away»
>>
>>