Convenzioni URL interne aziendali

sviluppatore qui ... Mi piacerebbe la tua prospettiva IT su questo ...

Sto creando una nuova app Web interna per la mia azienda e sto iniziando a pensare a come verrà distribuita. Molte delle app Web esistenti qui sono collegate all'uso diretto dei nomi dei loro server, in questo modo:

http://webserver123/someInternalApp/

Questo mi mette a disagio per una serie di motivi. I nomi dei server cambiano, i server non funzionano e gli utenti non dovrebbero conoscere i nomi dei server per trovare la loro applicazione web. L'uso dei nomi dei server ci impedisce di scambiare server o aggiungere bilanciatori di carico. Se riesci a pensare ad altri motivi per cui questo è negativo, fammi sapere in modo da poter fare un caso migliore per cambiare questa pratica.

In futuro, vorrei avere alcuni nomi di dominio migliori impostati nel nostro DNS interno che rimandano al server Web e all'app appropriati. Nel mio ultimo lavoro, abbiamo seguito una convenzione simile a questa:

• Per la produzione: http://someInternalApp.myCompany.com/
• Per il test: http://test.someInternalApp.myCompany.com/
• Per lo sviluppo: http://dev.someInternalApp.myCompany.com/

Mi piace di più , poiché il nome dell'applicazione è una parte fondamentale del nome di dominio e la designazione dell'ambiente dev / test / prod è semplice. Tuttavia, ho alcune riserve:

• Inserire il nome dell'app nel sottodominio alla fine creerà molti sottodomini lunghi e unici. Mi piace avere domini diversi per ogni app, ma sento anche che potrebbe essere difficile da gestire.
• A parte il nome dell'app, non c'è nulla che indichi che questo URL è solo interno. Ho letto di altre organizzazioni che utilizzano un sottodominio come "corp.myCompany.com" o "int.myCompany.com" che potrebbe essere buono. Non voglio che gli utenti abbiano l'impressione che possano accedervi da casa.

Ecco alcune opzioni su ciò a cui mi sto appoggiando per i nomi di dominio interni:

Nome dell'app nel sottodominio interno: (diventano un po 'lunghi, ma tutto è ben confezionato insieme, penso)

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

Nome app come sottodirectory: (nome di dominio più breve, ma implica che tutte le app fanno parte di un sito unificato, che potrebbero non essere, e disconnette la designazione dell'ambiente dall'app)

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

Quindi, discutiamo ... Cosa ne pensi di queste opzioni? C'è qualcosa di meglio o di più comune che potrei aver perso? Ho l'opportunità di impostare la mia azienda su un percorso migliore in questo senso, quindi mi piacerebbe trovare una buona convenzione da consigliare.

Grazie!

Non fare mai affidamento sul fatto se l'app sarà interna o esterna. Sviluppa sempre come se il pubblico dell'app fosse al di fuori del tuo controllo (perché lo è).

Vai con ENV.APPNAME.DOMAIN.TLD

Con www. come alias per "produzione".

Se stai implementando solo interni, hai una grande libertà nella selezione. Tuttavia, con i domini di primo livello che si stanno aprendo come hanno fatto recentemente, ti consigliamo di fare attenzione a non entrare in conflitto con un nuovo nome esterno in arrivo.

ad esempio, potresti distribuire come http://contact.app/ ma se il TLD .app viene registrato, potresti trovarti in conflitto.

Quindi probabilmente stai meglio usando qualcosa come http: //contact.local/ o http: //contact.lan/

Per motivi di Apple e della loro compatibilità con il servizio Bonjour, è meglio evitare .local, quindi magari con .lan

In alternativa, solo http: //contact.ourcompany/ funzionerebbe abbastanza bene se è improbabile che il nome della tua azienda diventi mai un TLD.

Eviterei il nome dell'app come sottodirectory perché non è necessario e lo rende solo più lungo. L'hosting virtuale è la strada da percorrere con un URL univoco per app.

E hai ragione ad evitare i nomi dei server, questo è un no-no definito perché i server vanno e vengono.

Modifica 1 : vedi RFC2606 e scegli tra i TLD per uso interno disponibili qui indicati.

Proprio come una nota ai commenti - .local e .lan come raccomando non sono registrabili come sopra RFC. Puoi usare .priv e .test anche per gli stessi motivi.

Questa opinione da qualche parte si basa sul fatto che quando distribuisci la tua applicazione solo internamente hai il pieno controllo e non importa davvero cosa fai ...

La maggior parte degli utenti aggiungerà ai segnalibri quali applicazioni Web interne devono utilizzare comunque, quindi non preoccuparti troppo dei loro URL.

Come amministratore di sistema mi piacerebbe più applicazioni che mi dessero la possibilità di implementare in una sottodirectory configurabile o la radice su un sottodominio, consentendo la scelta di utilizzare sottodomini o meno.

Ci vuole uno sviluppatore più premuroso per non seguire il percorso "facile" e includere semplicemente un riferimento "relativo" codificato " href=/images/bullet.png" su una pagina casuale e invece di creare un riferimento da una serie di impostazioni di distribuzione / configurazione " href={HTTP-PROTO}://{IMG-HOST}/{IMG-BASEDIR}/bullet.png"

Effettuare le scelte di distribuzione come nomi host, numeri di porta, scelte nelle impostazioni di configurazione HTTP / HTTPS e non codificarle.

Sono stato spesso sul lato ricevente "la gestione vuole tutte le app interne http://intranet/apps/perché appname.intranetè così confusa. E il contrario dai nostri fornitori; abbiamo bisogno appname.intranetper il nostro dispositivo / applicazione poiché abbiamo il controllo integrato contro iframe, incorporando man-in-the -middle-attacchi e reverse proxy ...

Ho scoperto che molte applicazioni Web commerciali prevedono di essere distribuite nella radice del server Web e non funzionano in modo troppo affidabile quando vengono distribuite in una sottodirectory casuale. Ad esempio, includono, ad esempio, percorsi più o meno codificati verso le /css/main.csssottodirectory, rendendo difficile l'hosting di più applicazioni sullo stesso host. Ma questi lotti non sembrano troppo preoccupati per la portabilità del loro codice.