Give Me an API for Filtering Content
Content management systems should include an API for filtering a bucket of content, obtained through any means
Here’s something that should be a required feature of any CMS – You should be able to “wash” a list of content against the permissions model of the CMS. Meaning, if I get a list of content IDs, I should be able to “strain” them through some API call on the CMS, and get back a list of IDs the…
The document proposes the need for an API in any CMS that allows users to filter content against the permissions model. This would allow users to filter a list of content IDs based on their current user’s permissions, potentially improving user experience. The author acknowledges that this feature could potentially lead to system hacking, but questions whether this would deter CMS vendors from implementing it.
Generated by Azure AI on June 24, 2024Here’s something that should be a required feature of any CMS –
You should be able to “wash” a list of content against the permissions model of the CMS. Meaning, if I get a list of content IDs, I should be able to “strain” them through some API call on the CMS, and get back a list of IDs the current user is allowed to see.
This would make my life so much easier, though what that really means is that I’d be able to hack systems at a lower-level, which probably makes CMS vendors nervous so they have little impetus to actually implement this, but I can dream.
Here’s an example of where I’m going with this –
Sometimes, you just can’t get “at” the content you want through the exposed APIs. You try, but you need to do something really hairy and the API is just not playing ball with you. So, you do the unthinkable and go straight to SQL. The idea is that you query for content IDs, then use the API to retrieve that content by specific IDs.
This is bad, for the primary reason that you may get back content that the current user should not see, either because they don’t have sufficient permissions or the content isn’t published yet. Essentially, you’re going around the permissions and publishing model of the CMS, and untold horrors await you.
But, what if you could say –
Hey, CMS, I have this list of content IDs here… How did I get them? Yeah, well, that’s not that important right now…
Anyway, can you look at this and tell me which ones I can show Nathaniel Snerpis? Here, just take them all, and give me back the ones I can show him.
In this case, the CMS has filtered your list, and everyone is happy. In the end, it doesn’t much matter how you got the list of content, just so long as you filter it.
Although I mentioned directly querying SQL, that’s just an example. There’s a number of different ways you could obtain an arbitrary list of content, and that’s the beauty of this idea – it doesn’t matter how you got the list. A filter just let’s you “correct” any list of content, regardless of origin.
Another good example is using a search system external to your CMS –
We have three Ektron installs using the Google Mini search appliance. One of the problems with the Mini is that it’s not plugged into Ektron’s permissions model, so it has no idea which content it can show an anonymous user in search results and which it can’t. To get it to play ball, you have to go to complicated lengths to expose user groups in META tags, then filter against them, etc. A good content filtering API would remove this problem.
I wonder if CMS vendors would be disinclined to do this because to do so would open their systems up to being…extended, in ways that they weren’t planning on. In the end, is this a bad thing?