Meilleur emplacement pour un site Web CMS
Dans le cadre de mon travail, j'ai récemment commencé à créer de nombreux systèmes de gestion de contenu pour des sites Web. Tellement, que ma prochaine étape a évidemment été de mettre en place un "modèle" pour les sites Web afin de pouvoir supprimer ou ajouter rapidement des éléments répondant aux besoins des clients.
Fondamentalement, j'ai choisi Code Igniter et je suis maintenant prêt à le brancher à une extrémité avant.
Dans le passé, j’ai placé les sites Web des CMS dans un sous-répertoire de ce site, par exemple mysite.com/cms. Cela utilisait 'spaghetti' PHP cependant.
En utilisant un framework tel que CI ou n’importe quelle structure MVC, est-il préférable de l’héberger dans un sous-domaine, de conserver le front-end et le back-end dans la même application ou de les scinder en plusieurs domaines? Ou est-ce vraiment pas grave?
Ou est-ce vraiment pas grave?
Ce. À la fin de la journée, vous obtiendrez à peu près la même performance du système de gestion de contenu, où que vous soyez. La fonctionnalité est la chose importante.
Je dirais que cela dépend des besoins de votre entreprise.
Un domaine distinct pourrait vous permettre de normaliser une approche, de séparer le CMS de l'application Web et éventuellement de centraliser la gestion de votre site à un seul emplacement.
Si vous envisagez de fournir Content Managent en tant que service et de structurer votre entreprise en proposant des options standard, mais flexibles, un hébergement séparé serait un bon choix.
Si le client/client souhaite posséder ou contrôler le CMS, l’approche par sous-domaine peut être plus appropriée.
La combinaison du CMS avec le site Web fonctionne si les sites impliquent peu les clients. S'ils effectuent rarement eux-mêmes des mises à jour, le client ne risque pas de supprimer, de déplacer ou de "casser" le CMS.
Les besoins et les fonctionnalités de création sont certes importants, mais l'approche doit également correspondre à votre modèle d'entreprise.
Du point de vue de l'utilisateur final, peu importe l'adresse que vous publiez, tant que tout fonctionne comme prévu et que l'utilisateur y accède sans problème.
Du point de vue des développeurs (et j'en ai écrit et publié beaucoup), il est légèrement plus pratique de le publier au même emplacement physique que votre serveur frontal et de conserver l'URL au même niveau au premier plan. -end qu'il 'gère le contenu de' . De cette manière, vous pouvez utiliser les mêmes fichiers de configuration pour les applications de génération frontale ainsi que votre CMS (ou au moins en conserver de grandes parties identiques, s’ils doivent être des fichiers séparés), tout en évitant les problèmes liés à la sécurité. chemins relatifs pointant vers des racines différentes. Ce n'est pas la fin du monde qui le fait différemment, mais impliquerait un peu plus de travail dans la plupart des cas.
Du point de vue de la sécurité si, les choses deviennent un peu difficiles. L'utilisation de chemins d'URL facilement reconnaissables vers votre CMS signifie que vous devrez potentiellement faire face à beaucoup plus d'attaques directes, sans avoir le temps de réagir, en bloquant les scanners d'URL avant même qu'ils ne frappent votre CMS avec des requêtes malveillantes. C'est bien, si vous avez confiance dans les protocoles de sécurité de vos applications Web, et dans certains cas, cela est même souhaitable (lorsque l'application Web est également le pot de miel). Si ce n'est pas le cas et que vous dépendez de pots de miel gérés de manière externe (mods de serveur de sécurité, analyseurs de journaux, ...), vous voudrez peut-être choisir une URL non évidente pour votre CMS, afin que votre pot de miel ait le temps de réagir. to 'script kiddie' saisissez des requêtes et bloquez-les. Dans ce dernier cas, il est également judicieux de 'anonymiser' toutes les demandes externes, telles que les utilisateurs du CMS ouvrant des URL externes via ce dernier, où le référent de la demande (votre emplacement CMS) peut apparaître dans les journaux du serveur Web tiers. Écrire un script 'anonymizer' par lequel vous pouvez déléguer des demandes externes est assez simple et il suffit d'un simple appel de fonction JS dans votre modèle principal de CMS pour activer le support pour cela.
Signification ...
Dans cet esprit, je vous suggérerais d’héberger votre CMS dans une URL non évidente, au même niveau que celui relatif (parallèle) à la racine frontale, mais physiquement au même emplacement pour la commodité des développeurs/concepteurs et le débogage. objectifs, ainsi que certains 'sécurité par l'obscurité' , au moins suffisamment pour capturer le plus évident 'brut' avec une relative facilité avant qu'ils ne réussissent à faire du mal. Bien sûr, vous ne devriez jamais dépendre uniquement de 'sécurité par l'obscurité' et vous devez toujours avoir d'autres protocoles en place lorsque les premiers échouent (ce qu'ils feront sûrement ).
À votre santé!
Je suggérerai au mieux de les garder sur un domaine distinct .. ou si vous souhaitez placer le CMS sur le même domaine, conservez-les sur des domaines forts tels que Blogger.com ou worpdress.