É prática padrão aceita instalar software usando o VBScript? [fechadas]

4

Considere os seguintes requisitos

  1. Software do Windows que se comunica com um aplicativo da Web usando a autenticação básica
  2. O software é um pacote MSI
  3. O software requer que um token seja colocado para se autenticar no aplicativo da web
  4. O token é exclusivo para todos os usuários, mas espera-se que o usuário instale o software com o mesmo token em várias máquinas

A questão é :

Qual é a melhor estratégia para distribuir o software a partir do aplicativo da web com token apropriado? (o usuário não deve ser solicitado a inserir o token.)

A solução proposta é: :

Quando o usuário clica no botão do software de download a partir do aplicativo da Web, em vez de fornecer o software, geramos um arquivo VBScript que contém o token e o local de download do pacote de software (MSI) e o entrega como um download. Depois disso, quando o usuário invocar o script, as seguintes coisas acontecerão.

  • O software será baixado e o token será passado para o instalador e uma ação personalizada dentro do instalador receberá o token e configurará o aplicativo de acordo

O mundo do Windows aceitará a solução acima? Eles sentem isso não natural? Existe uma solução melhor para o problema em questão?

    
por k4vin 03.04.2015 / 10:07
fonte

4 respostas

6

A solução padrão que você certamente viu de outros fornecedores de software é

  • permite que o usuário baixe e instale o software, talvez com ou sem o registro, mas deixe que o próprio software conduza o usuário pelo processo de registro posteriormente.

Por meio desse processo, depois que o usuário é autenticado, o token é baixado na forma de um arquivo de licença. Se você quiser permitir que o usuário instale o software em uma segunda máquina sem uma nova autenticação, permita que o arquivo de licença seja copiado para a outra máquina. Você escreveu "o usuário não deve ser solicitado a digitar o token" - mas, na verdade, onde está a diferença para o usuário se ele tiver que copiar um arquivo VBS para uma segunda máquina ou se tiver que copiar um arquivo de licença?

Observe que isso não impede que seu usuário distribua o software junto com o arquivo de licença para outra pessoa, mas como sua própria abordagem não impede isso, acho que você não está atrás de uma solução para esse problema.

Uma abordagem diferente não é usar o VBS, mas gerar um downloader personalizado na forma de um arquivo exe (não é muito difícil fornecer um código-fonte C ou C ++ personalizado modificando apenas um pequeno arquivo de código e depois compilado on-the-fly pelo seu servidor web). Pelo menos isso proíbe modificações pelo usuário comum com um editor de texto simples como o Bloco de Notas, que seria possível para um downloader do VBS. E você não precisa ensinar seus usuários como executar um script VB.

E se você realmente deseja fornecer pacotes de instalação personalizados, há uma terceira opção. É possível gerar ou regenerar seus pacotes MSI on-the-fly, para que você possa substituir o arquivo de token pessoal dentro de um pacote MSI para cada download individual. Esta postagem SO contém algumas informações sobre isso e aqui é mostrado como um único arquivo pode ser substituído dentro de um MSI compactado. Essa pode ser a solução mais suave para o seu caso.

    
por 03.04.2015 / 12:37
fonte
9

Scripts baixáveis para serem executados - VBScript ou Javascript - sempre soam muito duvidosos para mim, especialmente porque há muitas ovelhas negras por aí abusando de tais coisas para instalar malware. Você não quer treinar ninguém usando seu programa para confiar, baixar e usar esses scripts.

Infelizmente, não consigo pensar em nenhum incêndio seguro & esqueça a solução para isso que não incluirá possíveis vulnerabilidades de segurança (como alguém que, sem intenção, passa o token para um colega de trabalho como parte do pacote do instalador).

Teoricamente, você poderia instalar um plugin de navegador para atuar como uma ponte de autenticação / comunicação entre o aplicativo da web e o programa nativo (semelhante ao que a EA faz com o seu plugin Battlelog para os mais novos jogos de Battlefield), mas mesmo isso não é algo perfeito.

Como tal, eu ainda aconselho vivamente a ir a (um pouquinho) de forma mais intrusiva e pedindo ao usuário para detalhes de login, uma vez que o programa está instalado. Tenha em mente que você também pode querer revogar os tokens (mesmo que seja devido a uma máquina roubada).

    
por 03.04.2015 / 10:43
fonte
4

Você pode, embora eu não esteja certo de recomendá-lo, incorporar o token do usuário no nome do instalador e colocar o código no instalador para recuperá-lo.

Para provar que eu não inventei, o antivírus Sophos faz isso. De maneira bastante previsível, o número um em sua lista de Problemas mais comuns de instalação é "Renomeando o instalador nome do arquivo". Mas presumo que o benefício é que, como eles não modificam o conteúdo do instalador, o servidor que o distribui não precisa acessar as chaves privadas que o assinam.

De qualquer forma, o princípio geral é que, para softwares sérios, você provavelmente quer distribuir um executável assinado gerado no local mais seguro que possui, junto com um token não assinado gerado instantaneamente por algum servidor da Web voltado para o público. Se você não quiser fazer com que o usuário baixe dois arquivos, copie e cole o token, ou qualquer coisa desse tipo, então o nome do arquivo é os únicos bits que você deixou para se comunicar.

Colocar o token em um código não assinado destinado a ser executado com privilégios totais de usuário na máquina do usuário, mesmo que seja apenas um script, em vez disso, anula o propósito de assinar o instalador. Se você quiser seguir essa rota, você quase também deve distribuir um instalador não assinado com o token do usuário corrigido nele. Para uma pequena proporção de usuários nerds, um VBScript muito simples não precisa ser assinado, pois pode ser verificado com atenção para não ser malicioso. Mas não há muitos deles, então "quase" é "quase de fato".

    
por 03.04.2015 / 16:34
fonte
3

Existem dois aspectos envolvidos nesta questão.

  1. Embalagem do seu aplicativo
  2. Distribuição de tokens de usuário

Para o ponto 1, recomendo o modelo de implantação ClickOnce . Eu suponho que você construiu um aplicativo de estrutura Microsoft .NET. Mesmo que de outra forma, você poderia implementar algo semelhante à implantação do ClickOnce em sua plataforma de tecnologia. Pretendo destacar mais sobre o modelo de implantação em vez da tecnologia específica.

Para o ponto 2, poderia ser abordado de duas maneiras diferentes -

  1. Considere criar um aplicativo pequeno (algo semelhante ao seu código VBScript atual). No entanto, esta aplicação seria um executável como .exe. Esta aplicação será embalada junto com o programa que você pretende distribuir. Vamos chamá-lo como Product Activator. Seu único objetivo seria conectar-se a um serviço gerador de token e obter um token para o usuário atual. Supondo que você tenha campos de interface do usuário para coletar o ID do usuário. Este ativador de produto pode fazer parte de seu portfólio maior de aplicativos que você distribui pela Web.
  2. Como parte do aplicativo, pode haver um módulo / código de inicialização único que faz a mesma atividade que o ativador do produto descrito acima.

Deixe-me focar no serviço de geração de tokens. Este elemento está presente em ambas as opções da solução. O serviço é o código que você tem hoje para gerar tokens para os usuários. Você deve considerar hospedá-lo como um serviço da Web com descoberta e acesso limitados para evitar expor sua lógica de geração do token.

Em ambas as abordagens, o usuário não é solicitado a fornecer um token. No entanto, o ID do usuário pode ser uma entrada do usuário esperada do usuário. Em ambas as abordagens, como @Mario apontou, o risco de educar o usuário para executar um script VBScript é evitado. Além disso, o processo de instalação do aplicativo agora é uma tarefa de registrar os binários de seu aplicativo na máquina cliente. A lógica de registrar o usuário é uma perspectiva diferente e não está aberta para o usuário ajustar como seria se o usuário abrisse o arquivo VBScript.

    
por 03.04.2015 / 11:21
fonte