È la pratica standard accettata installare software usando VBScript? [chiuso]

La soluzione standard che hai sicuramente visto da altri fornitori di software è

• consente all'utente di scaricare e installare il software, magari con o senza la registrazione, ma lascia che il software stesso conduca l'utente attraverso il processo di registrazione in seguito.

Attraverso questo processo, dopo che l'utente è stato autenticato, il token viene scaricato sotto forma di un file di licenza. Se si desidera consentire all'utente di installare il software su una seconda macchina senza una nuova autenticazione, consentire che il file di licenza venga copiato sull'altra macchina. Hai scritto "non si dovrebbe chiedere all'utente di inserire il token" - ma in realtà, dov'è la differenza per l'utente se deve copiare un file VBS su una seconda macchina, o se deve copiare un file di licenza?

Nota che questo non impedisce al tuo utente di distribuire il software insieme al file di licenza a un'altra persona, ma dal momento che il tuo approccio non lo impedisce, suppongo che tu non cerchi una soluzione per quel problema.

Un approccio diverso non è usare VBS, ma generare un downloader personalizzato sotto forma di un file exe (non è troppo difficile fornire un codice sorgente C o C ++ che è personalizzato modificando solo un piccolo file di codice e quindi compilato al volo dal tuo server web). Almeno questo proibisce le modifiche da parte dell'utente medio con un semplice editor di testo come Blocco note, che sarebbe possibile per un downloader VBS. E non devi insegnare ai tuoi utenti come eseguire uno script VB.

E se vuoi davvero fornire pacchetti di installazione personalizzati, c'è una terza opzione. È possibile generare o rigenerare i pacchetti MSI al volo, in modo da poter sostituire il file token personale all'interno di un pacchetto MSI per ogni singolo download. Questo post SO contiene alcune informazioni su questo e qui viene mostrato come un singolo file può essere sostituito all'interno di un MSI compresso. Questa potrebbe essere la soluzione più semplice per il tuo caso.

Gli script scaricabili da eseguire - VBScript o Javascript - mi sembrano sempre molto interessanti, soprattutto perché ci sono troppe pecore nere che abusano di queste cose per installare malware. Non vuoi formare nessuno che usi il tuo programma per fidarti, scaricare e utilizzare tali script.

Purtroppo non riesco a pensare a nessun fuoco sicuro & dimentica la soluzione a ciò che non includerà possibili vulnerabilità della sicurezza (come qualcuno che passa involontariamente il token a un collega come parte del pacchetto di installazione).

In teoria è possibile installare un plug-in del browser per fungere da ponte di autenticazione / comunicazione tra l'applicazione Web e il programma nativo (simile a ciò che EA fa con il loro plugin Battlelog per i nuovi giochi Battlefield), ma anche questo non è qualcosa perfetto.

Come tale, ti consiglio comunque vivamente di andare (un pochino) in modo più intrusivo e chiedere all'utente i dettagli di accesso una volta installato il programma. Tieni presente che potresti voler in qualche modo revocare i token (anche se è solo a causa di un dispositivo rubato).

Potresti, anche se non sono sicuro che lo raccomandi, incorporare il token dell'utente nel nome file del programma di installazione e inserire il codice nel programma di installazione per recuperarlo.

Per dimostrare che non l'ho inventato, l'antivirus di Sophos fa questo. Piuttosto prevedibilmente, il numero uno nella loro lista di Problemi di installazione più comuni è "Rinominare l'installer nome del file". Ma suppongo che il vantaggio sia che, poiché non modificano affatto il contenuto del programma di installazione, il server che lo distribuisce non ha bisogno di accedere alle chiavi private che lo firmano.

In ogni caso il principio generale è che per un software serio probabilmente si desidera distribuire un eseguibile firmato generato nella posizione più sicura che si possiede, insieme a un token non firmato generato al volo da un server web pubblico. Se non desideri che l'utente scarichi due file, copia-incolla il token o qualcosa del genere, il nome del file riguarda solo i bit che hai lasciato per comunicare.

Mettere il token in un codice non firmato destinato ad essere eseguito con i privilegi di utente completi sul computer dell'utente, anche solo uno script, vanifica piuttosto lo scopo della firma del programma di installazione. Se si vuole seguire questa strada, allora quasi potrebbe anche distribuire un programma di installazione non firmato con il token dell'utente collegato in esso. Per una piccolissima percentuale di utenti geek, non è necessario firmare un VBScript molto semplice poiché può essere verificato a occhio nudo. Ma non ce ne sono molti, quindi "quasi" è "quasi quasi".

Ci sono due aspetti coinvolti in questa domanda.

1. Packaging della tua applicazione
2. Distribuzione di token utente

Per il punto 1, raccomando il ClickOnce modello di implementazione. Ho ipotizzato di aver creato un'applicazione framework Microsoft .NET. Anche se diversamente, potresti implementare qualcosa di simile alla distribuzione ClickOnce nella tua piattaforma tecnologica. Intendo evidenziare di più il modello di implementazione piuttosto che la particolare tecnologia.

Per il punto 2, potrebbe essere risolto in due modi diversi:

1. Considera la possibilità di creare una piccola applicazione (qualcosa di simile al tuo attuale codice VBScript). Tuttavia questa applicazione sarebbe un eseguibile come .exe. Questa applicazione sarà imballata insieme al programma che intendi distribuire. Chiamiamolo come Product Activator. Il suo unico scopo sarebbe quello di connettersi a un servizio di generazione di token e ottenere un token per l'utente corrente. Supponendo che tu abbia i campi dell'interfaccia utente per raccogliere l'ID utente dall'utente. Questo attivatore di prodotto potrebbe far parte del tuo più ampio portafoglio di applicazioni che distribuisci attraverso il web.
2. Come parte dell'applicazione potrebbe esserci un modulo / codice di avvio una tantum che svolge la stessa attività dell'attivatore del prodotto sopra descritto.

Consentitemi di concentrarmi sul servizio di generazione di token. Questo elemento è presente in entrambe le opzioni della soluzione. Il servizio è il pezzo di codice che hai oggi per generare token per gli utenti. Dovresti considerare di ospitarli come un servizio Web con accesso e scoperta limitati per evitare di esporre la tua logica di generazione del token.

In entrambi gli approcci, all'utente non viene richiesto un token. Tuttavia, l'ID utente potrebbe essere un input dell'utente previsto dall'utente. In entrambi gli approcci, come sottolineato da @ Mario, si evita il rischio di educare l'utente a eseguire uno script VBScript. Inoltre, il processo di installazione dell'applicazione è ora un'attività di registrazione dei file binari dell'applicazione sul computer client. La logica di registrazione dell'utente è una prospettiva diversa e non è aperta all'utente per modificarla come sarebbe se l'utente avesse aperto il file VBScript.