Please enable JavaScript.
Coggle requires JavaScript to display documents.
Figure Out How to Restrict Dynamic Data Requests CONTENT-3532 (What…
Figure Out How to Restrict Dynamic Data Requests CONTENT-3532
Why is this important?
if we don't add restrictions to dynamic data calls, then we are allowing Hippo users to make any POST, GET, and PUT call they so please. This is dangerous because they have the ability to configure a NON-content retrieval resource.
About whitelist/blacklist on the content broker
What should we allow by default?
Any GET resource
What's better to filter resources: whitelist or blacklist?
If whitelist, you can by default allow the normal calls:
Any GET calls (with or without a request body)
If a non-GET call wants to be used, then the client has to specify that they want that call to pass through. Such as:
product-catalog:POST:/products (the POST /products URI from product-catalog)
product-catalog:/products (any product-catalog URI starting
TODO: talk with team to figure out, if we go this route, what's the best way to do this?
What solutions are there?
Enabling a whitelist or blacklist on the Content Broker
pros
Since it's the content broker that will be responsible for making the dynamic data calls, adding restriction here will ensure that every proxyable request will be verified prior to proxyable call
Is configured via properties file
Similar to how reverse-proxy library figures out which URIs should be reverse proxied
Can add a public method that determines if a request can be processed or not
cons
It's a backend solution, which means that the frontend has to know how to interpret a restricted error message from the content-broker
Enable restriction in Hippo
pros
We can add validation in the Hippo UI and the CRUD REST calls, which allows us to catch the error early
cons
Engineers can still pull in the content broker library into their codebase and create their own proxyable calls without restriction
Enable restriction in landing-site (or wherever the pages controller will live)
pros
You can add validation similar to Hippo's pro
cons
Similar to Hippo's con
What if we don't have this enabled?
Then we will allow our clients to make any POST, PUT and GET call via Dynamic Data
What's the worst case scenario?
A client will configure a POST and/or PUT call that will update/create a resource, which is NOT what we want
What's the best case scenario?
Our clients will be good stewards and not update/create resources
How to Incorporate CMS Bot into monitoring?
Incorporate a schedule job that looks at all the Dynamic Data configurations and returns useful data
It can store data in a cache so that you can be able to search for them without having to ping CMS each time
Is there a way to get all Content Models from CMS? Maybe Hippo?
By default CMS bot can notify a slack channel about useful info, like if there's been any new Dynamic Data configurations added