The discussion revolves around managing roles and permissions for moderators and administrators in Discourse. Bitweb_Core asks how to grant access to certain functions (like theme settings) while restricting access to sensitive areas such as API keys for social logins. ondrej clarifies that Discourse does not offer granular permissions for moderators and explains that users are either staff (admin or moderator), category moderators, or leaders. RGJ warns that anyone with theme access can hijack user sessions, emphasizing that if someone isn’t trusted with such power, they shouldn’t be given admin privileges. Bitweb_Core elaborates that the concern is not malicious intent but accidental exposure or loss of keys, which could disrupt API access. The discussion also touches on potential future solutions, such as password-protected pages, to mitigate such risks Bitweb_Core.
As exampe if neen give acces to administrator or moderator to themes function but as example dissable acces to see api secrects from socials logins.
and separate moderators as example give moderator role to some people in community branch at forum to trusted people from community with restrictions…
Hi 
If I understand correctly you are asking whether Discourse offers permissions for moderators.
If this is the case this is not possible. You are either Staff (Admin or Moderator), category moderator or TL4 Leader
Have a read of this topic
I think category moderators or Leaders would work well here.
Anyone with write access to the themes can completely hijack a users session. If you don’t trust someone doing that, you should not trust them at all. And if you do trust them, you can just make them admin.
That was how example , more clear i don’t want give access where api keys’ but give to other to other settings sections. For prevent that admin from copy that keys and use some where at 3rd place at future as example for testing some thing
not necessarily even for evil intentions, yet this is quite an alarming section in the case of, for example, a github key. The administrator may not be related to the repository at all, but administer the forum if necessary. But I didn’t want him to accidentally compromise the keys, simply by “copy them and then they be stolen from him.”
or mistake remove them.
because of laziness to get your own, and in the case of tweeter and google, everything is rather contradictory there, since those keys are not now distributed to the all who write “i want acess”, and even an accidental compromise of keys can lead to disabling access to the api.
how solution pages like that can be protected with extra password at next releases if need
I think it’s better think about all possible vulnerabilities and prevent even if it’s unlikely