Access control with git-gateway for user comments

I want to add a simple community feature to my project. I would like to use git-gateway (or maybe the github graphql feature) so that comments and posts from users are repo commits that kick off a build and deploy (regular ol’ JAMstack workflow). Everything makes sense and I have a working prototype, however, I don’t understand how role based access control works in this model. For example: an authenticated user (I’m using Netlify identity) should be able to post a comment to a thread, however, they should not be able to create or merge any other kinds of commits.

If someone can point me in the right direction for either documentation or an example on how to handle RBAC with git-gateway, that would be extremely helpful. I know the Smashing case study included a comments feature, but I haven’t found any technical details on how that was accomplished, other than the general fact that user comments are committed to the repo.

Thanks!

Hmm, that is a possibility and it’s not impossible, but it’s not the workflow I’d use. There are services like disqus or our open source gotell service (GitHub - netlify/gotell: Netlify Comments is an API and build tool for handling large amounts of comments for JAMstack products) that handle commenting in a less-deploy-heavy way. As you may or may not be aware, we are charging for build minutes beyond a fixed number included at each price point (Netlify Pricing and Plans), and rebuilding your site with each comment could end up costing you some serious money if you had a popular enough topic.

git_gateway will allow the full permission set that your code enables (so for instance, our CMS implements commits, merges, deletions, creations) - but only on the branches that the CMS controls. So if your project were handling its own git access, you’d want to gate/specify the operations that your code could create to just adding and committing rather than merging or deleting. You can do some of that permission control at your git provider - allowing pushes but not merges, for instance - but the permissions available for a user vary by service so you’d have to be very sure about what you configure there AND what your code allows. Your code would specifically have to “filter” which operations are allowed; but your users can ONLY do what your code says, since you are not giving them “direct” access to your repo - they can’t say login to github or do any direct committing; it only happens through our service.

It’s not a usual workflow, but it should be possible. This is the best walkthrough we have for identity is here so this is a good starting point on “how to gate access”: Getting Started with JWT and Identity . Take a look and let me know if you have any more specific questions and I’ll be happy to help.

Thanks for the reply! This makes sense. I’ll check out the doc you linked and let you know if I have any questions. My concerns with using a hosted service like disqus are user tracking, the ownership of content, and revenue model. Also, ideally, I wouldn’t have to host anything myself (which is why I was thinking the git commit option) vs self-hosting something like gotell.