Programming Language Interoperation for Website

Quello che stai cercando di ottenere è descritto come SOA (Service Oriented Architecture) che definisce un'applicazione come insieme di servizi molto indipendenti, a grana fine, dispiegabili in modo indipendente interfacciati con protocolli agnostici di tecnologia leggera. Questo tipo di architettura pone l'accento sulla modularità, sul testing, sul refactoring continuo dei singoli moduli (detti anche microservizi). È un concetto molto giovane e un consenso generale in merito alle migliori pratiche deve ancora emergere, quindi, è difficile rispondere direttamente alla tua domanda. Quello su cui la gente di solito è d'accordo è:

• ogni servizio dovrebbe rappresentare una filosofia di "fare una cosa e farla bene"
• ogni servizio dovrebbe utilizzare la lingua migliore per l'attività specificata
• i protocolli selezionati non dovrebbero essere dipendenti dalla lingua
• non tutto dovrebbe essere un servizio

Quest'ultima pallottola è un esempio delle solite critiche nei confronti del concetto di SOA che sembra essere incentrato sulla tendenza a creare "nanoservizi" (cioè servizi troppo fini per giustificare il sovraccarico delle chiamate tra servizi).

Dal momento che non esiste una "buona pratica" standard o comunemente concordata in relazione a tali servizi, ho visto diverse applicazioni negli anni in cui letteralmente ogni servizio utilizzava stack diversi. Anche se hanno comunicato l'uno con l'altro in modo piuttosto semplice ed efficiente, personalmente lo consiglierei a causa dell'elevata soglia di accesso per i nuovi sviluppatori.

Sopra detto, la soluzione più comune che ho visto era il daemon C / C ++ in ascolto su un socket Unix. È abbastanza scalabile in quanto possono essere comunicati localmente o in rete, inoltre il linguaggio C / C ++ è ampiamente utilizzato e c'è la possibilità che qualcuno di nuovo nel progetto lo sappia o sia in grado di trovare rapidamente aiuto su Internet. Un po 'meno popolare stava usando uno script di shell + socket Unix. Il resto dei servizi SOA ho spesso finito per rimpiazzarmi con un pezzo di JavaScript che ho tenuto nella memoria condivisa e incluso solo dove necessario (è un gioco da ragazzi nelle tipiche applicazioni in stile PHP e JavaScript SPA).

Suggerisco un approccio al servizio web.

Crea un servizio di assistenza json formattato in qualsiasi lingua (c, nodejs, qualunque sia).

Il servizio utilizza la parola d'ordine e restituisce la struttura di JSON con i risultati dell'analisi.

Questo servizio è quindi un modulo che può essere facilmente utilizzato da entrambi i siti Web esistenti, ad esempio tramite semplici riccioli.

La sicurezza di questo servizio può essere raggiunta in molti modi, ma un semplice esempio è che il servizio può essere configurato per ascoltare solo su una porta localhost privata, quindi è sicuro per i server web esistenti come sarebbe stata una chiamata di subroutine.

Nota questo è intrinsecamente molto simile all'approccio exec che hai delineato, ma poiché il servizio è sempre in esecuzione questo approccio è più efficiente: stesse comunicazioni tra processi, ma non è necessario avviare il processo e inizializzarlo per ogni richiesta.

Un misuratore della forza della password è un software altamente sensibile alla sicurezza. La password dovrebbe idealmente non essere mai trasmessa al server.

Questo risolve anche il tuo dilemma: implementa il misuratore della forza della password come widget lato client in puro JavaScript. È quindi possibile riutilizzare facilmente questo widget su entrambi i siti Web.

Quando hai sentito che i processi figlio in esecuzione dovrebbero essere evitati per lo più giusto. L'avvio di un processo richiede molto tempo, relativamente parlando, il che limita notevolmente le richieste al secondo che è possibile gestire. Ancor di più quando il processo figlio è un interprete. La gestione degli errori dei processi figli può essere non banale.

Ci sono anche alcuni potenziali problemi di sicurezza: i parametri della riga di comando non sono privati. I segreti dovrebbero essere comunicati attraverso un tubo. Può essere difficile garantire che si stia eseguendo il processo desiderato a causa di funzionalità come la variabile PATH e i collegamenti simbolici del filesystem. Se dovessi eseguire accidentalmente il processo sbagliato, le password potrebbero essere compromesse. Sebbene nessuno di questi problemi di sicurezza debba essere applicato se si utilizza un server privato, è importante considerarli.

Una nota sull'uso di C: è un linguaggio perfettamente raffinato, ma scrivere software sicuro con esso può essere difficile, a meno che tu non sia un programmatore C esperto. È facile introdurre involontariamente buffer overflow ed è facile dimenticare la corretta gestione degli errori. Il principio dell'Uomo Ragno "con grande potere viene una grande responsabilità" si applica.

L'esecuzione di un programma persistente di misuratore della forza della password e la comunicazione con esso tramite socket o un'API potrebbero essere interpretati come una sorta di microservizio. Ciò consentirebbe di riutilizzare lo stesso servizio su più siti Web in quanto il linguaggio di programmazione del microservizio è indipendente dal resto del tuo sito web. Ma come discusso sopra, qui è molto preferibile un'implementazione lato client.