Sous-domaines vs dossiers, pour applications multi-comptes / utilisateurs
Donc, pour une application Web multi-utilisateurs, quoi de mieux:
http://username.domain.com
Ou
http://domain.com/username
Je voudrais obtenir des commentaires sur la sécurité, l’évolutivité et la maintenance en particulier, l’application est basée sur php, elle est donc basée sur .htaccess pour la réécriture d’URL.
Comme pour toute question de haut niveau telle que celle-ci, la réponse dépendra largement de vos besoins.
La première question que je devrais poser cependant (car cela n’a pas été précisé dans votre question) est de savoir pourquoi vous préoccupez-vous d’un sous-domaine ou d’un sous-dossier? S'agira-t-il d'URL "vanity"? Si ce n'est pas le cas et que vous ne diffusez que du contenu basé sur la connexion d'un utilisateur, vous n'aurez alors besoin que de votre URL de base (aucun dossier ni sous-domaine n'est nécessaire). Une fois que vous aurez authentifié un utilisateur, vous saurez qui il est et ce à quoi il devrait avoir accès. Vous pourrez ainsi diffuser du contenu en fonction de son identifiant.
Si vous souhaitez utiliser ceci pour des URL personnalisées, voici quelques avantages/inconvénients pour chacun:
Sous-dossiers
- Meilleure option pour le référencement. Les moteurs de recherche verront chaque sous-domaine comme un site Web distinct et ne donneront pas autant de poids au domaine racine. L'utilisation de sous-dossiers aidera à améliorer les classements SEO.
- Une sorte de réécriture sera probablement impliquée dans votre code si vous envisagez de ne disposer que d'une seule base de code.
- Il faudra quand même prendre en compte ce qu'un utilisateur est autorisé à voir en fonction de son identifiant.
- Comme JamesRyan l'a mentionné, si les utilisateurs génèrent du code, les cookies pourraient être un problème, car ils appartiennent tous au même domaine.
- Si vous envisagez d'utiliser SSL (ce qui devrait être le cas si vous avez des utilisateurs fournissant des mots de passe ou d'autres données privées), vous n'avez besoin que d'un seul certificat. Vous pouvez utiliser un seul certificat générique pour les sous-domaines, mais ceux-ci ont tendance à être beaucoup plus coûteux.
sous-domaines
- Meilleure option si vous souhaitez créer des sites Web distincts (c.-à-d. Racine Web différente, instance Apache différente, certificat SSL différent pour chaque site, etc.)
- N'auriez pas nécessairement de réécriture à prendre en compte (même si vous le pouviez encore). Votre code pourrait être écrit pour vérifier l’en-tête de l’hôte afin de déterminer le contenu à diffuser.
- Nécessite un enregistrement DNS générique ou vous devrez créer manuellement des enregistrements DNS pour chaque sous-domaine que vous créez. En fonction du nombre de sous-domaines créés, cela peut nécessiter beaucoup d’efforts. Des enregistrements DNS génériques seraient à coup sûr la solution.
- Comme pour l'option de sous-dossier, si vous utilisez la même base de code pour desservir chaque site, vous devez toujours authentifier les utilisateurs et vérifier ce qu'ils sont autorisés à voir.
Au bout du compte, tout dépend de vos besoins. J'ai seulement énuméré quelques points à garder à l'esprit avec l'une ou l'autre option. Si vous souhaitez préciser votre question de manière plus précise, je pense que vous obtiendrez probablement quelques réponses plus précises.
L'utilisation de dossiers est définitivement, certainement, nettement plus facile à gérer et beaucoup plus évolutive.
Pour les sous-domaines, vous devez créer une nouvelle instance de serveur pour chacun. Avec les dossiers, vous créez simplement un nouveau dossier.
Les sous-domaines gagnent en sécurité, mais si le contenu du profil est géré, vous devriez utiliser des dossiers.
S'il s'agit d'un domaine sur lequel les utilisateurs ont un contrôle total, utilisez des sous-domaines.
Les cookies s'appliquent aux domaines et seront donc partagés si vous utilisiez des dossiers mais avec des sous-domaines susceptibles de s'appliquer à l'ensemble du domaine ou à des sous-domaines individuels.
Si vous hébergez du contenu généré par l'utilisateur, vous devez éviter les attaques XSS.