Désolé pour l’ancien post, mais pourquoi ne pas configurer votre thème comme un dépôt sur GitHub ? Donnez à votre équipe de conception et d’UX les permissions nécessaires pour accéder et mettre à jour le thème sur GitHub.
Dans Discourse, vous pouvez maintenant configurer les thèmes pour qu’ils se mettent à jour automatiquement lors d’une reconstruction.
Vos administrateurs n’auront plus besoin que de reconstruire pour intégrer les modifications apportées par l’équipe de conception et d’UX, et cette dernière n’aura plus besoin d’accès administrateur du tout.
Lorsqu’il s’agit de codifier les contrôles d’accès, en général, ces vérifications RBAC doivent être effectuées côté serveur.
Le code RBAC dans le Javascript côté client peut être manipulé par le client.
Cela signifie que lors de la définition des permissions RBAC de base pour le personnel, les administrateurs et les modérateurs, cela doit être fait (en termes généraux) dans Rails, et non dans Javascript.
Au fait, c’est aussi ainsi que Discourse gère désormais le RBAC, en utilisant ce que Discourse appelle un « guardian », une classe Ruby nommée class Guardian, ici :
Si un développeur envisage d’ajouter des vérifications RBAC dans le code Javascript en appelant l’API Discourse, gardez à l’esprit que ce code peut être compromis, car le code exécuté dans le navigateur peut être manipulé.
Ma recommandation est de s’assurer que tout le code RBAC de base est exécuté côté serveur et de ne pas essayer de contourner cela dans le Javascript côté client.
J’ai un cas d’usage similaire : je gère une petite communauté à but non lucratif où l’un de nos utilisateurs s’occupe de la maintenance des thèmes et du design.
Je ne souhaite donner l’accès aux données privées des utilisateurs (adresses e-mail, etc.) qu’à moi-même et à mon co-gérant, mais j’ai quatre modérateurs.
Pour permettre au designer de travailler, j’ai dû créer un site miroir sans contenu où il est administrateur, puis copier manuellement les thèmes et les composants. Cependant, cette solution n’est pas idéale car certaines modifications nécessitent du contenu pour être validées.
Laissez donc le développeur travailler sur le site de staging et pousser les thèmes vers GitHub. Cependant, vous devrez toujours procéder vous-même à la mise à jour. Vous pourriez trouver un moyen d’effectuer la mise à jour via l’API et de permettre au développeur de la déclencher d’une manière ou d’une autre.
Je travaille sur un outil qui pourrait être en mesure de vous aider dans ce domaine.
Si vous n’avez pas confiance dans le designer pour voir vos données, quelle solution imagineriez-vous ?
Pourriez-vous lui donner une clé API qui lui permettrait d’utiliser le discourse_cli pour y pousser le thème, puis la désactiver une fois qu’il aurait terminé, peut-être ?
Il n’y a absolument aucune raison pour qu’un designer ait accès à 100 000 utilisateurs lol. De plus, ce serait contraire aux règles du RGPD. Est-il possible de donner une clé CLI uniquement pour les mises à jour de thème ?
Veuillez m’excuser ! Je pense que vous avez raison.
Maintenant, contrairement à la création de ce sujet (qui était apparemment dans ma tête quand j’ai écrit ma réponse), nous avons des clés API granulaires. Il ne devrait pas être trop difficile d’ajouter une nouvelle portée juste pour la gestion des thèmes.
Cela pourrait valoir la peine de créer un nouveau sujet dans Feature pour demander une portée de clé API pour les développeurs de thèmes. Cela semble être une excellente idée.
Il serait bon que @AV_C puisse poster une référence à cette exigence. Bien que je puisse fortement apprécier pourquoi un client voudrait restreindre l’accès à la base d’utilisateurs et même aux catégories privées pour diverses raisons. L’administrateur complet peut accéder aux e-mails d’inscription des membres et les catégories privées peuvent contenir d’autres contenus sensibles en fonction du cas d’utilisation du client.
Je pense que @pfaffman a une bonne idée pour garantir que ce type de lacune puisse être couvert par une API d’administration restreinte. Une fois le travail de conception terminé, la clé peut être révoquée jusqu’à ce qu’elle soit nécessaire.
Cela correspondrait également à l’idée de Jay de ne pas afficher un utilisateur comme administrateur sur la page À propos.