…is an example URL and we’d want to “gate” based on the /product/ portion of that - which won’t work since that is all interpreted client side (after the “#”), so our redirects engine never even sees it.

I’ve asked the CMS developers to take a look and let me know if they have any different ideas!

The situation right this minute is not even a separate instance of the CMS will work since the accept_roles item in the config.yml now does NOTHING!!!, somebody decided to make that completely irrelevant and now the replacement for that is to enter specific roles into the git-gateway as a whole as in all roles entered there are authorized in the same exact way.

That seems to actually undo any sort of way at all to deal with role based access to collections or even distinct instances of netlify CMS. Maybe they should put the accept_roles item back in the netlify cms config. Seems far more useful there any way you slice it.

@rwboyer the issue with accept_roles that lead to its removal from the codebase (though it was unfortunately left in the docs) was that it doesn’t actually enforce anything in a secure way. Because the accept_roles setting only affected the client-side CMS, any user could work around it by simply authenticating manually and using the auth token it to authenticate any request they wanted, even requests to collections which weren’t configured to be accessible by that role.

Technically, this can still be worked around by using two git-gateway instances with different roles allowed and different CMS configs, but this still doesn’t provide any actual security because any user with a git-gateway token (which you receive when you log into the CMS) can use that token to edit any content in the repo, even if it’s not included in the config.yml. The only current way to actually enforce roles would be to have the two git-gateway instances pointing to different repos on GitHub. True role based access control is currently out of scope for Netlify CMS, and would need to be implemented in git-gateway because the CMS, being a client-side app, can’t possibly enforce roles in a secure way.

understood, but having a reasonable way to do it only in the front end is still better from a user POV than all you can eat the way it is now.

As for two git-gateway instances with two different configs, not picturing exactly how to set that up off the top of my head as I don’t recall a way to point to a specific git-gateway instance in the config?