web-dev-qa-db-fra.com

Comment faire en sorte qu'un site Web de production charge des éléments à partir d'un serveur Web local?

En général, je configure un environnement local avec le site Web en cours d'exécution sur ma machine lorsque je vais développer de nouvelles fonctionnalités avec JavaScript. Il en va de même pour la mise à jour des feuilles de style.

Quand il n’est pas facile d’exécuter le site de production localement, je préfère quand même éditer les fichiers localement et les "prévisualiser" sur le site actif. Quelque chose comme ça:

  • Un serveur Web local qui sert les actifs (css et js)
  • Un moyen de faire en sorte que le site Web actif charge des ressources à partir du serveur Web mon local. (Greasemonkey, proxy)
  • Livereload qui surveille mes fichiers locaux et actualise le site en direct en cas de changement.

J'ai besoin de commentaires sur l'étape des secondes. Greasemonkey est uniquement pour Firefox, ce qui rend difficile le test des fonctionnalités du navigateur. Un proxy, c'est beaucoup de travail ... :)

Quelqu'un at-il essayé quelque chose de similaire, peut-être y at-il un outil intelligent pour cela?

web-developmentproxy
6
Sven

Pour rediriger les demandes d'actifs sur votre ordinateur local uniquement

Pour que votre ordinateur local utilise des fichiers locaux pour certains actifs JavaScript ou CSS demandés à un serveur distant, vous pouvez utiliser un outil d'interception/proxy HTTP tel que Charles . (Mac, Windows et Linux. Démo de 30 jours, puis 50 $ d'achat.)

Pour configurer Charles afin qu'il écoute les demandes distantes et serve les fichiers locaux à la place, procédez comme suit:

  1. Télécharger Charles .

  2. Lancez Charles et, lorsque vous y êtes invité, laissez-le modifier vos paramètres de proxy.

  3. Visitez le site Web que vous testez dans votre navigateur. J'utilise Chrome pour visiter Google dans cet exemple.

  4. Recherchez le site Web dans la fenêtre "Structure" de Charles dans le volet de gauche, puis explorez les dossiers jusqu'à l'actif demandé que vous souhaitez modifier. J'utilise le logo de Google dans cet exemple.

    find the site in Charles' structure window

  5. Cliquez deux fois sur l’actif et choisissez "mapper en local" dans les options suivantes:

    mapping to a local file

  6. Choisissez le fichier que vous voulez charger à partir de votre système de fichiers local au lieu de l'actif distant:

    map a remote file to a local one

  7. Répétez l'opération pour autant d'actifs que vous souhaitez remapper.

  8. Force à actualiser votre navigateur. Vous devriez trouver les actifs sont chargés à partir de votre ordinateur local au lieu de celui distant.

Pour "démapper" les fichiers locaux afin que les fichiers distants soient à nouveau chargés, procédez comme suit:

  1. Choisissez Outils> Carte locale dans le menu de Charles:

    enter image description here

  2. Cliquez sur la règle [s] que vous souhaitez supprimer de la liste, puis cliquez sur le bouton "Supprimer":

    enter image description here

Il existe des applications gratuites disponibles qui vous permettront de faire la même chose, telles que WebScarab et Burp suite , mais ni l'une ni l'autre ne sont aussi simples et belles à utiliser que Charles, à mon avis .

Le reste de cette réponse concerne les étapes à suivre si vous souhaitez qu'un serveur Web distant charge les fichiers de votre ordinateur pour tous les utilisateurs qui visitent le site distant. (Exemple d'utilisation possible: affichage du travail aux clients/collègues lorsque vous ne pouvez pas reproduire le site de production localement ou mettre en scène un serveur de développement.)

Pour rediriger les demandes d'actifs sur toutes les machines

Pour servir certains actifs à partir de votre ordinateur local pour tous les ordinateurs accédant à un autre serveur Web distant, vous pouvez configurer votre serveur local pour qu'il soit accessible depuis le Web. Quelques options:

Services de tunnel localhost

Ces services vous aident à partager localhost sur le Web pour rendre disponibles des actifs ou des sites entiers via une adresse Web:

Showoff.io et Tunnlr sont des services payants à 5 $/mois. Localtunnel est actuellement gratuit.

DNS dynamique

Une alternative gratuite consiste à utiliser un hébergement DNS dynamique à partir d'un service tel que fear.org pour pointer une adresse Web sur le serveur Web exécuté sur votre ordinateur local. Voici comment ça fonctionne:

  1. Inscrivez-vous à fear.org .

  2. Cliquez sur le lien dans l'email envoyé pour activer votre compte et vous connecter automatiquement.

  3. Configurez un nouveau sous-domaine , que vous utiliserez pour accéder à votre hôte local à partir du Web. Vous pouvez choisir l'un de leurs domaines gratuits (comme "mooo.com"); il n'est pas nécessaire d'enregistrer le vôtre.

  4. Téléchargez l’un des nombreux applications DNS dynamiques pour votre système d’exploitation.

  5. Exécutez l'application, qui publie votre adresse IP sur les serveurs fear.org.

  6. Configurez un serveur pour qu'il s'exécute sur le port 80 de votre ordinateur local et autorisez le trafic via le port 80 sur tous les pare-feu exécutés. Cela dépend de votre système d’exploitation et de votre matériel. (Si vous utilisez Mac OS X, par exemple, il vous suffit d'activer le "Partage Web" dans le volet Préférences Système> Partage.)

  7. Visitez le sous-domaine que vous avez créé à l'étape 3 dans votre navigateur Web. (par exemple, votrenom.mooo.com). Le nom sera résolu en adresse IP de votre ordinateur et, si vous avez configuré votre serveur et votre pare-feu correctement, vous devriez voir le fichier d’index de votre ordinateur local.

Vous pouvez ensuite accéder aux ressources du dossier public de votre ordinateur local via le Web en utilisant le chemin d'accès complet à ces ressources avec le sous-domaine fear.org que vous avez créé. Par exemple: yourname.mooo.com/~yourMacUsername/images/hurrah.jpg Naturellement, vous pouvez référencer cette URL à partir d'un autre serveur pour lui permettre de charger des fichiers à partir de votre ordinateur local.

[Sur le Mac, le dossier public est le dossier "Sites" de votre répertoire utilisateur. Pour y accéder, utilisez votre adresse IP ou votre nom d'hôte suivi d'un tilde (~) et de votre nom d'utilisateur Mac. Les autres serveurs et systèmes d'exploitation fonctionnent légèrement différemment.]

7
Nick

Redirection externe

Si vous êtes en mesure de modifier le fichier de production .htaccess, vous pouvez simplement rediriger les demandes des ressources statiques nécessaires sur votre serveur Web local. La redirection serait conditionnelle à l'adresse IP accédant au site (c'est-à-dire votre adresse IP externe).

Par exemple, pour rediriger un actif spécifique vers le même chemin d’URL sur le serveur local:

RewriteEngine On

RewriteCond %{REMOTE_ADDR} ^203\.0\.113\.111$
RewriteRule ^assets/main\.css$ http://local-web-server.com%{REQUEST_URI} [R,L]

Tous les fichiers CSS:

RewriteRule ^assets/.+\.css$ http://local-web-server.com%{REQUEST_URI} [R,L]

Tous les atouts:

RewriteRule ^assets/.+ http://local-web-server.com%{REQUEST_URI} [R,L]

Vous n'avez pas besoin d'utiliser un nom d'hôte résolvable (par exemple, local-web-server.com), vous pouvez simplement utiliser l'adresse IP locale de votre site Web local. serveur directement (par exemple 192.168.1.20). Cependant, en utilisant un nom d’hôte, votre serveur de développement local peut utiliser des hôtes virtuels pour desservir plusieurs sites Web sans avoir à modifier quoi que ce soit entre les projets.

Les éléments ci-dessus sont des redirections temporaires (302). Vous pouvez les changer en permanent (301) en modifiant R en R=301. Cela diminuera les demandes du serveur car le navigateur redirigera du cache. Toutefois, vous devrez effacer le cache du navigateur local une fois que vous avez terminé, afin d'effacer la redirection mise en cache.

Inconvénients:

  • Vous devez avoir accès au fichier de production .htaccess et le modifier.
  • C'est une redirection externe. Vous ne feriez jamais cela pour diffuser du contenu en direct, mais cela convient parfaitement aux tests locaux.

Avantages:

  • Votre serveur de développement local n'a pas besoin d'être public.
  • Fonctionne pour tous les navigateurs sur votre machine de développement.
  • Si le DNS est public pour local-web-server.com (qui pointe sur l'adresse IP locale de votre serveur Web), quiconque (ou tout périphérique) sur votre réseau local peut également voir ces ressources locales.

Nom d'hôte séparé pour les actifs statiques

Si le site de production utilise un nom d’hôte distinct pour tous les actifs statiques, par exemple. static.example.com vous pouvez simplement le remplacer dans votre DNS local (fichier HOSTS) pour qu'il pointe vers votre serveur de développement local.

Inconvénients:

  • À moins que vous n'ayez un serveur DNS centralisé pour votre réseau local, les autres appareils de votre réseau local ne pourront pas voir les actifs locaux à moins qu'ils ne modifient leur propre fichier HOSTS (ce qui n'est pas toujours possible sur les appareils mobiles).

Avantages:

  • Aucune modification côté serveur requise sur le serveur de production.

Proxy inverse

Pour rendre cela transparent (c'est-à-dire sans redirection), vous pouvez configurer un proxy inverse sur le serveur de production. Vous auriez toujours des directives similaires dans .htaccess pour approximer les actifs nécessaires.

Inconvénients:

  • Besoin d'un accès au serveur de production afin de configurer un proxy inverse.
  • Besoin d'un accès au serveur de production pour pouvoir envoyer les requêtes par proxy (éventuellement dans .htaccess).
  • Votre serveur de développement local doit être "public".

Avantages:

  • Vous pouvez activer les utilisateurs distants pour afficher l'intégralité du site "développement".

Livereload qui surveille mes fichiers locaux et actualise le site en direct en cas de changement.

C'est vraiment une question distincte. De nombreux éditeurs de code ont de nos jours des fonctionnalités/plug-ins "de prévisualisation en direct" qui activent cette fonctionnalité.

2
MrWhite