Force-post in restricted category

support
#1

Hello,

I’m using Discourse through the API as a community backend. There are certain categories that should be restricted for regular users so that they can’t create topics or edit topic titles. However, they should be able to see the threads and reply to them. All this should be done via the API (using an admin token) on behalf of those users. Is there a way I can implement that through proper security and API calls? E.g. it’s enough if I can force-create a post in a restricted category on behalf of a regular user (using an admin key/user), but I can’t find that case in API documentation.
Many thanks!

#2

The API really isn’t going to be documented for your use case as it’s totally unsupported (I do have at least one client who’s doing something similar, though). How to reverse engineer the Discourse API is probably the best you can get and also discourse/routes.rb at master · discourse/discourse · GitHub.

If you’re using an admin API key, then all restrictions are removed, so you should be able to create the topic. Or perhaps create the topic as the user then move it to the category that you don’t want them to be able to post in?

1 Like
#3

Thanks. I know about the reverse engineering, but there is no similar use case from the Discourse front-end to intercept. I mean that, while I’m logged in as admin, there is no way to create a topic as a different user.

The workaround I’ve implemented for now is to let the specific category have see/comment permissions for everyone and see/comment/create for admins. Then topics are created by “system” only (so there is no way for users to tamper with the titles) along with a template original post. Then I can use the API key to comment as different users in those created topics.

#4

I think that the other group I was helping had users logging in to Discourse (through SSO, maybe?) so that they acted on their own behalf. That way you get all of the user protections afforded by Rails. Doing everything with a single admin API key seems like a recipe for disaster.

But I guess what you’d do to do what your current problem is would be to create the topic as adin and then change its ownership. That should be reasonably straightforward. (And then hope that nothing goes wrong between the start and end of the entire transaction.)

I guess another possiblity would be to create a custom plugin that added a create-as-user route (I haven’t looked at the routes I linked earlier to see if that’s already there somehow.)

But the more I think about it (knowing nothing about what you’re really doing, mind you), the more I think that you want your front end to log in as the users so that it can interact with the API as the user.