Petite question, y a-t-il un moyen d’utiliser Discourse en interne, uniquement sur mon réseau, pas sur Internet ?
Disons que mon domaine à la maison s’appelle testlabs.local, je veux que tous les utilisateurs de ce domaine puissent accéder à Discourse. Je peux y accéder via le port 80 mais lorsque j’enregistre mon compte, je définis un nom d’utilisateur et un mot de passe, puis lorsque je continue, j’obtiens un message nginx 404, la page est vide. Curieusement, même si cela génère une erreur, je reçois toujours l’e-mail mais lorsque je clique sur le lien, j’obtiens à nouveau une erreur 404.
Alors, cela peut-il être utilisé en interne comme je le souhaite ?
Ou doit-il être utilisé uniquement en externe ?
Si oui, y a-t-il des guides pour configurer cela en interne car je ne vois que le guide cloud ?
Dans le fichier yaml, j’ai configuré mes paramètres smtp, je peux les recevoir. Je ne suis pas clair sur le champ nom d’utilisateur et mot de passe smtp. Je les commente simplement, est-ce que cela doit être configuré ? Si oui, pourquoi est-ce que je reçois toujours des e-mails sans cette configuration ?
Je ne veux tout simplement pas mettre un mot de passe d’e-mail en texte brut.
L’une de ces options vous permettra d’utiliser Discourse via http://localhost:4200/ Ces options utilisent toutes MailHog pour tester le SMTP sans envoyer réellement d’e-mails.
Mise à jour : J’ai relu la question et je vois que vous voulez permettre à d’autres personnes de l’utiliser. Je ne sais pas si cette réponse aide réellement.
Discourse ne fonctionnera généralement pas sans https, ce qui est difficile à configurer sur un réseau local. Vous pourriez rejoindre consulter des guides impliquant un proxy inverse comme guide, mais ce n’est pas une configuration prise en charge.
Merci pour votre réponse, oui, je veux aussi que d’autres personnes l’utilisent. Je veux juste clarifier que ces autres personnes font partie de mon réseau local, tout sera accessible à la maison, aucun accès public à cela.
Est-ce que cela fonctionnerait d’activer invite only et login required pour mettre Discourse sur Internet, mais restreindre qui peut le voir ? Ou peut-être utiliser must approve users (peut-être avec auto approve email domains) pour n’autoriser que les utilisateurs de votre organisation à rejoindre ?
Je suppose que la question est de savoir quel problème vous résolvez ?
Merci pour ta réponse. Je l’ai actuellement configuré sur une distribution Red Hat en interne dans mon domaine, uniquement pour un usage interne. J’essaierai de jouer avec. Que veux-tu dire exactement quand tu dis que ça ne fonctionnera pas sans https ? Donc, il est uniquement conçu pour fonctionner en externe, pour être accessible via Internet public uniquement ?
Peux-tu s’il te plaît élaborer davantage sur le guide du proxy inverse ? Je ne comprends pas ce que tu veux dire par “join at guides”.
Actuellement, nous mettons le produit en veilleuse, nous voulons l’utiliser comme forum interne pour notre entreprise.
Pour que les développeurs et l’informatique puissent publier et interagir les uns avec les autres. Nous voulons que ce soit uniquement interne, sans accès public.
C’est la solution sur laquelle ils sont fixés. Je ne peux pas contrôler cela.
Je pense que le paramètre doit approuver les utilisateurs répond efficacement à cette exigence. De nombreux outils « internes » (Slack, Google Suite, Microsoft Office 360, GitHub Enterprise, etc.) sont hébergés sur Internet, mais sont limités aux seuls utilisateurs approuvés par l’administrateur du client.
Si le placer sur un réseau interne est une exigence informatique, ils devraient également être en mesure d’aider à la configuration du réseau pour Discourse.
Je comprends, je demande quel est le processus pour qu’il fonctionne uniquement pour un accès interne ? Il n’y a pas de guide d’installation pour cela, et les utilisateurs disent que cela ne fonctionne pas bien sans https.
Je viens en fait d’installer un réseau local dans mon laboratoire et je vais le tester, mais d’après des tests précédents, cela n’a pas fonctionné en interne. J’essaierai à nouveau.
Je veux dire qu’une grande partie du code front-end suppose que vous utilisez https. Je veux dire que l’installation standard suppose que votre site peut obtenir un certificat de let’s encrypt.
En voici un. Pour que cela fonctionne, vous devrez configurer Apache avec un certificat valide, puis le faire agir comme proxy inverse pour Discourse.
Ce n’est pas une configuration prise en charge. Si être derrière un pare-feu/NAT est une exigence, alors avoir quelqu’un qui sait comment configurer un proxy inverse interne avec un certificat valide et qui peut suivre l’un des guides comme celui lié ci-dessus est le coût de cette exigence.
C’est une façon plus gentille de dire ce que j’ai dit.
Vous avez des informaticiens sur place. Ils peuvent créer des certificats car ils utilisent de toute façon des serveurs Web sur votre intranet. Le seul problème est d’obtenir un certificat approuvé par les navigateurs.
