Conventions d'URL internes à l'entreprise


8

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!


Les astuces DNS, la réécriture d'URL et l'hébergement virtuel sont vos amis ici. Sera-ce sur une pile Microsoft ou Linux?
ewwhite

Applications Web Microsoft ... .Net fonctionnant sur IIS dans Windows
Ben Brandt

nommer les choses est un problème difficile en informatique. Attendez-vous à ce que tout schéma (en particulier avec les nombres auto-incrémentés) échoue à un moment donné. Les redirections et DNS sont la voie à suivre pour ambiguïter des noms spécifiques.
tedder42

Réponses:


7

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".


Approche simple et solide, j'aime ça. D'autant plus pertinent de nos jours avec des navigateurs comme Chrome qui synchronisent vos favoris et votre historique. Si je crée un signet pour une application de travail interne dans Chrome, ce signet est synchronisé avec mon ordinateur personnel et mon appareil Android. Une fois le signet arrivé, il vaut mieux ne pas pointer vers autre chose sur Internet.
Ben Brandt du

3

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.


5
Le seul espace de noms DNS dont vous pouvez pratiquement avoir le contrôle sur Internet, ce sont les sous-domaines d'un domaine de deuxième niveau que vous possédez. Tout idiot avec de l'argent peut faire créer un TLD aujourd'hui, donc utiliser n'importe quel type de TLD personnalisé à l'intérieur d'un réseau me semble une mauvaise idée. J'irais avec des sous-domaines du nom de ma propre entreprise et vivrais avec le fait que les URL seront plus longues.
Evan Anderson

@EvanAnderson Je propose un KickStarter pour collecter 185k $ pour les frais de candidature pour enregistrer le .localgTLD et établir une leçon permanente sur la façon de configurer correctement vos environnements.
Sammitch

Il n'est plus recommandé d'utiliser un TLD que vous ne possédez pas, ou d'utiliser des espaces de recherche DNS. Voir les informations sur la collision de noms de l'ICANN .
Michael Hampton,

1

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.


L'installation de plusieurs applications qui ont toutes une exigence d'installation root sur le même serveur est résolue de manière triviale via un hébergement virtuel avec un nom DNS distinct pour chaque application.
Ian Macintosh,

Pour le profane (mon ancien directeur et directeur technique), cela fait toujours plusieurs serveurs (bien que ce ne soient pas des boîtes réelles) dans le sens où ils n'apparaissent pas comme intranet / applications / inventaire et intranet / applications / facturation.
HBruijn
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.