Afficher le contenu d'un serveur principal sur un autre hôte dans un sous-répertoire Wordpress sans modifier l'URL
Nous avons actuellement un tas d'applications ASP.NET qui sont toutes accessibles via un seul domaine. Donc, www.example.com se connecte au site Web principal. www.example.com/documents est une application distincte qui permet aux clients d’accéder à leurs documents.
Ceci est hébergé dans IIS, la branche de documents étant une application ASP.NET. Les clients ont des courriels qui renvoient à leurs documents, tels que: www.example.com/documents/document?id=12345
Nous cherchons à mettre à jour le site Web principal et à le séparer de tout le reste - en le déplaçant vers un hôte séparé - probablement une configuration Apache/WordPress.
En gardant cela à l'esprit, le nom de domaine d'origine serait associé au site Web principal, puis un domaine secondaire serait créé, lequel continuerait de contenir l'application de documents sous Windows/IIS. www.backenddomain.example/documents
Dans ce scénario, est-il possible pour Apache/WordPress de rediriger uniquement le sous-dossier/la page de documents vers le nouveau domaine sans modifier l'URL dans le navigateur? Donc, www.example.com/documents va à www.backenddomain.example/documents mais les clients voient www.example.com/documents
Je sais que je peux configurer une redirection 301, mais cela modifie l'URL du client et, idéalement, je la préférerais si nous pouvions la conserver. Transférer efficacement le contenu.
Dommage que vous n’ayez pas utilisé documents.example.com car vous pourriez alors obtenir l’effet souhaité, mais vous devrez quand même changer l’URL.
Même avec le masquage, vous ne pouvez pas pointer vers une autre URL sans rediriger l'utilisateur vers l'URL. Pensez aux risques de sécurité impliqués ici. Le potentiel d'abus est si élevé que cela n'est même pas autorisé et pour une bonne raison. Si vous pointez quelqu'un vers un nouveau domaine, vous devez exposer ce domaine. (Il existe des moyens de contourner cela, mais cela est considéré comme blackhat/greyhat et je mets en garde en utilisant ces méthodes)
Une approche alternative consisterait à créer le sous-domaine: documents.example.com et à le diriger vers l’ancien serveur.
Ensuite, sur le nouveau serveur, vous pouvez utiliser une certaine logique regex pour rediriger les URL de document héritées vers la nouvelle URL de sous-domaine (qui pointe vers l'ancien serveur).
RewriteRule ^/?documents/(.*) http://documents.example.com/$0 [R,L]
Cela permettra à toutes les URL existantes d'être redirigées vers le nouveau sous-domaine. Quel est toujours l'effet que vous recherchez? Bien que cela utilise un sous-domaine.
Sur l'ancien serveur, vous pouvez gérer les demandes visant à forcer la restriction de ce domaine dans le dossier documents. Bien que je vous suggère de configurer l'hôte pour qu'il soit le répertoire de documents au lieu de ce hack.
RewriteCond %{HTTP_Host} documents.example.com
RewriteCond %{REQUEST_URI} !^/?documents/
RewriteRule .* documents/$0
En utilisant cette approche, vous devriez pouvoir avoir l'apparence que vous souhaitez. Je suggérerais quand même que vous mettiez à jour l'application pour qu'elle utilise la nouvelle URL, mais ce n'est pas nécessaire, car la redirection se chargera de cela.
Bien que cela ne vous permette pas d'avoir la fonctionnalité souhaitée sans changer l'URL, cela permet de gérer le changement d'URL VIA redirections et configuration de l'hôte au lieu de devoir modifier les paramètres. code de l'application. Cela aura un impact minimal et constitue une solution très rapide au problème à résoudre. Cette configuration vous permettra de rediriger les URL héritées vers le nouveau sous-domaine qui pointe vers le répertoire de documents. J'encourage l'utilisation de cookies/jetons pour garantir que les utilisateurs accèdent à ces documents sont autorisés, mais cela sort du cadre de cette question.