Conventions d'URL internes à l'entreprise

développeur ici ... J'aimerais votre point de vue informatique sur celui-ci ...

Je crée une nouvelle application Web interne pour mon entreprise et commence à réfléchir à la façon dont elle sera déployée. De nombreuses applications Web existantes ici sont liées à l'utilisation directe de leurs noms de serveur, comme ceci:

http://webserver123/someInternalApp/

Cela me met mal à l'aise pour diverses raisons. Les noms de serveur changent, les serveurs tombent en panne et les utilisateurs ne devraient pas avoir à connaître les noms de serveur pour trouver leur application Web. L'utilisation de noms de serveur nous empêche d'échanger des serveurs ou d'ajouter des équilibreurs de charge. Si vous pouvez penser à d'autres raisons, c'est mauvais, faites-le moi savoir afin que je puisse mieux plaider pour changer cette pratique.

À l'avenir, j'aimerais avoir de meilleurs noms de domaine configurés dans notre DNS interne qui pointeront vers le serveur Web et l'application appropriés. Dans mon dernier travail, nous avons suivi une convention comme celle-ci:

• Pour la production: http://someInternalApp.myCompany.com/
• Pour test: http://test.someInternalApp.myCompany.com/
• Pour le developpement: http://dev.someInternalApp.myCompany.com/

J'aime mieux cela , car le nom de l'application est un élément clé du nom de domaine et la désignation de l'environnement dev / test / prod est simple. Cependant, j'ai quelques réserves:

• Le fait de mettre le nom de l'application dans le sous-domaine créera éventuellement de nombreux sous-domaines longs et uniques. J'aime avoir différents domaines pour chaque application, mais je pense également que cela pourrait être difficile à gérer.
• À part le nom de l'application, rien ne permet de désigner que cette URL est uniquement interne. J'ai lu que d'autres organisations utilisent un sous-domaine comme "corp.myCompany.com" ou "int.myCompany.com", ce qui pourrait être une bonne chose. Je ne veux pas que les utilisateurs aient l'impression qu'ils peuvent y accéder depuis chez eux.

Voici quelques options sur lesquelles je penche pour les noms de domaine internes:

Nom de l'application dans le sous-domaine interne: (ils deviennent un peu longs, mais tout est bien emballé, je pense)

• http://someInternalApp.corp.myCompany.com/
• http://dev.someInternalApp.corp.myCompany.com/

Nom de l'application en tant que sous-répertoire: (nom de domaine plus court, mais cela implique que toutes les applications font partie d'un site unifié, ce qu'elles peuvent ne pas être, et il déconnecte la désignation d'environnement de l'application)

• http://corp.myCompany.com/someInternalApp
• http://dev.corp.myCompany.com/someInternalApp

Alors, discutons ... Que pensez-vous de ces options? Y a-t-il quelque chose de mieux ou de plus commun que j'ai pu manquer? J'ai la possibilité de mettre mon entreprise sur une meilleure voie à cet égard, je voudrais donc trouver une bonne convention à recommander.

Merci!

Ne comptez jamais sur le fait que votre application sera interne ou externe. Développez toujours comme si le public de l'application serait hors de votre contrôle (car c'est le cas).

Allez avec ENV.APPNAME.DOMAIN.TLD

Avec www. comme alias pour "production".

Si vous déployez uniquement en interne, vous avez une grande liberté de sélection. Cependant, avec l'ouverture des domaines de premier niveau comme ils l'ont récemment fait, vous devez prendre soin de ne pas entrer en conflit avec un nouveau nom externe à venir.

par exemple, vous pouvez déployer en tant que http://contact.app/ mais si le TLD .app est enregistré, vous pourriez vous retrouver en conflit.

Il vaut donc mieux utiliser quelque chose comme http: //contact.local/ ou http: //contact.lan/

Pour des raisons d'Apple et de leur compatibilité avec le service Bonjour, il vaut mieux éviter .local, alors optez peut-être pour .lan

Alternativement, simplement http: //contact.ourcompany/ fonctionnerait plutôt bien si le nom de votre entreprise est très peu susceptible de devenir un TLD.

J'éviterais le nom de l'application en tant que sous-répertoire, car il n'est pas nécessaire et le rend plus long. L'hébergement virtuel est le moyen d'y aller avec une URL unique par application.

Et vous avez tout à fait raison d'éviter les noms de serveur, c'est un non-non, car les serveurs vont et viennent.

Edit 1 : Voir RFC2606 et faites votre choix parmi les TLD à usage interne disponibles référencés ici.

Tout comme une note aux commentaires - .local et .lan que je recommande ne sont pas enregistrables selon le RFC ci-dessus. Vous pouvez également utiliser .priv et .test pour les mêmes raisons.

Cette opinion est basée sur le fait que lorsque vous déployez uniquement votre application en interne, vous avez un contrôle total et que peu importe ce que vous faites ...

La plupart des utilisateurs mettront en signet les applications Web internes dont ils ont besoin de toute façon, alors ne vous inquiétez pas trop de leurs URL.

En tant qu'administrateur système, j'aimerais davantage d'applications qui me donnent le choix de déployer soit dans un sous-répertoire configurable soit à la racine sur un sous-domaine, permettant le choix d'utiliser des sous-domaines ou non.

Il faut un développeur plus prévenant pour ne pas suivre la voie "facile" et simplement inclure une référence codée en dur " href=/images/bullet.png" sur une page aléatoire et au lieu de construire une référence à partir d'un certain nombre de paramètres de déploiement / configuration " href={HTTP-PROTO}://{IMG-HOST}/{IMG-BASEDIR}/bullet.png"

Veuillez faire vos choix de déploiement tels que les noms d'hôte, les numéros de port, les choix dans les paramètres de configuration HTTP / HTTPS et ne les codez pas en dur.

J'ai souvent été du côté de la réception. "La direction veut que toutes les applications internes soient sous http://intranet/apps/parce que appname.intranetc'est tellement déroutant. Et l'opposé de nos fournisseurs; nous avons besoin appname.intranetde notre appareil / application car nous avons une vérification intégrée des iframes, en intégrant l'homme dans la -attaques intermédiaires et proxy inverse ....

J'ai constaté que de nombreuses applications Web commerciales s'attendent à être déployées à la racine du serveur Web et ne fonctionnent pas de manière trop fiable lorsqu'elles sont déployées dans un sous-répertoire aléatoire. C'est-à-dire qu'ils incluent, par exemple, des chemins plus ou moins codés en dur vers des /css/main.csssous-répertoires, ce qui rend difficile d'héberger plusieurs applications sur le même hôte. Mais ces lots ne semblent pas trop inquiets pour la portabilité de leur code.