Per occuparsi dello svantaggio # 2, lo script stesso può essere timbrato con una versione, controlla su un URL specifico che controlli quale è l'ultima versione che dovrebbe essere usata e avverti che deve essere aggiornato, eventualmente con una grazia periodo, dopo di che semplicemente si rifiuta di lavorare. Ovviamente, ciò funzionerebbe solo dopo distribuendo ovunque una versione di script che include tale controllo di versione, quindi dovresti aggiungerlo al più presto.
È potrebbe essere possibile anche offrire un trigger per il download automatico e la distribuzione di aggiornamenti di script sui siti dei clienti dallo script stesso. I clienti dovrebbero essere disposti a utilizzare tale trigger, ma ciò può essere difficile in termini di supporto in quanto diversi clienti potrebbero avere requisiti di implementazione, processi e strategie diversi. Potrebbe essere degno per i clienti selezionati (ben paganti o "più amichevoli")
Per affrontare il problema al ribasso n. 1, lo script può controllare allo stesso modo un URL specifico che controlli la configurazione del livello di servizio (in base a qualche tipo di client o ID di licenza) e agire di conseguenza. Sul lato server è possibile utilizzare gli accessi a tale URL per monitorare l'utilizzo e fornire configurazioni personalizzate.
Puoi persino unire i controlli n. 1 e n. 2 a un unico URL ben fatto e ottenere sia il controllo dell'ID client che di versione in un unico scambio di richiesta / risposta (con un effetto collaterale che puoi persino consentire diversi script per client versioni disponibili, se necessario, che possono risultare utili a volte, senza necessità di aggiornare le nuove versioni a tutti i client per gli aggiornamenti rilevanti per pochi client).
Qui non presumo intenzioni malevole (ad esempio, i clienti che hanno hackerato la sceneggiatura per indurre in errore / evitare questi controlli), altrimenti sarebbe necessario un approccio di applicazione più solido / sicuro.