PC Toledo

Pessoal, estou com um grande desafio (pelo menos para mim!).

É o seguinte: tenho um sitema em que faço o licenciamento anual. Esse sistema vai personalizado com nome/cpf do cidadão. Cada licença é para apenas um cpf. Ocorre que, alguns cidadãos querem utilizar o sistema para controlar também o cpf da esposa, do pai, do amigo, etc, mas quer economizar na licença.

Então, o que ele faz: registra as entradas e saídas do seu cpf e faz o backup (disponibilizado pelo próprio programa) e, em seguida, pelo próprio programa, restaura um backup anterior em que ela havia registrado as ocorrências do cpf do seu pai, por exemplo. Insere as novas movimentações e faz novo backup. Pronto, já pode restaurar o backup do seu tio e repetir todo o processo, para quantos quiser. O seu único trabalho vai ser controlar qual backup pertence a quem. Com isso vai pagar uma só licença.

O tal backup nada mais é que um arquivo .zip que contém os dois .dbf compactados.

Agora pergunto aos colegas: alguém pode me dar uma luz de como posso bloquear isso?

Antonio Carlos

Acredito que um arquivo auxiliar armazenando o hash do CPF "autêntico" seja a solução.

Note que o esquema do cliente com esses back-ups é legítimo e não vai contra o uso do programa. E se consta em algum contrato, não tem a menor validade. É o programa que precisa ficar "vinculado" a este e/ou àquele CPF. Se no programa nada consta nesse sentido, o usuário está absolutamente certo. Afinal, os dados são dele. Assim, ele pode fazer com os arquivos de dados o que bem entender.

AlaminoJunior,

Acredito que um arquivo auxiliar armazenando o hash do CPF "autêntico" seja a solução.

Poderia me detalhar como seria isso?

Maligno,

Note que o esquema do cliente com esses back-ups é legítimo e não vai contra o uso do programa

Considero como se eu vendesse o ingresso para o cidadão A assistir um filme. Ele assiste e dá um jeitinho e repassa o ingresso para o cidadão B também assistir o mesmo filme...

Seria o que o Maligno complementou

É o programa que precisa ficar "vinculado" a este e/ou àquele CPF

. Restringir o aplicativo a um único ou vários CPF´s, usando um arquivo auxiliar com o hash dos mesmos. Pois do contrário o cara faz o que bem entende mesmo.


Eu penso que pode ser da seguinte forma:
A sua aplicação ao ser iniciada, busca no arquivo auxiliar (que pode ser um dbf) o número do CPF. Se este número coincidir com o CPF digitado pelo usuário, o acesso é permitido.
Só um detalhe: note que eu mencionei o uso de hash.
Então você pega o CPF "autêntico", submete o danado ao HB_MD5(), ou o HB_CRYPT(), ou os dois, e armazena o resultado disso no arquivo auxiliar, e nunca o próprio número.

Lembrando que antes disso tudo, talvez precise deixar clara essa política com o cliente, para prevenir um possível constrangimento.

Considero como se eu vendesse o ingresso para o cidadão A assistir um filme. Ele assiste e dá um jeitinho e repassa o ingresso para o cidadão B também assistir o mesmo filme...

Nada a ver com o caso. Não foi um bom exemplo. Se fosse possível (o ingresso é inutilizado), seria ilegal, claro. Mas o seu caso é muito diferente. Por menos que você goste, os dados são do cliente. Sempre serão. É propriedade dele e ele pode usá-los do jeito que bem entender. Nem por contrato você pode mudar isso. Seria ilegal apenas se ele modificasse o programa.

O que pode ser feito é isso o que você quer: criar um vínculo no programa. Algum tipo de trava que inviabilize o esquema que ele usa.

Nada a ver com o caso. Não foi um bom exemplo

Maligno, pode ateh nao ter sido um bom exemplo, mas foi o que me veio naquele momento. Mesmo assim, acho que deu para entender. Bom, acho que encontrei a solucao: em vez de criar um novo arquivo de backup a cada solicitacao, criarei sempre o backup com o mesmo nome de arquivo, porem com uma senha aleatoria e guardada no arquivo auxiliar de forma criptografada. Se nao resolver, vai dificultar...

Obrigado a todos

Carlos, eu faco assim:

Uso o backup tb em meu sistema mas apenas o sistema com o CNPJ (o cpf no seu caso) e a licenca poderah abrir o arq. zip, ou seja, uso uma senha gerada pelo sistema baseado no cnpj + cod.aleatorio, com isso c qualquer outro sistema (meu eh claro) tentar abrir os dbfs isso n serah possivel. N sei c entendi o seu dilema mas eh o q faco aqui.

Marcos Roberto

Marcos, como você no teu programa, se o cidadão tentar importar um backup em que a senha não confira com o esperado pelo programa? Não vai gerar algum tipo de erro? Você utiliza o HB_UnZipFile para isso?

Grato

Antonio Carlos

Uso hbzip. Sim, o sistema soh recupera o banco de dados (backup) com a validacao do arq. de backup q eh feito conforme descrevi no post acima. Ou seja, o sistema n apresenta erro ele apenas diz q o backup n eh do sistema corrente.

Marcos Roberto.

Marcos, sem querer abusar, já abusando: você poderia informar a linha de comando para efetuar o backup e restaurá-lo com o HBZIP? O hbzip é xHarbour ou Harbour? Ou é um programa externo?

Antonio Carlos

Olá Carlos,
A hbzip pode usar com Harbour e xHarbour. No link abaixo tem exemplode Back-up e Retore do mesmo, caso não esteja usando lib graficas, é só remover a parte grafica que ela compila tranquilamente. E a lib hbzip faz parte da Contrib do x[H]arbour.
viewtopic.php?f=43&t=6757

Caros, estou quase lá... Quando a senha do arquivo compactado não confere, o programa não está restaurando (é isso que preciso), mas a mensagem ao usuário é como se tivesse ocorrido tudo certo. Vejam o código abaixo:
Ou seja, restaurando ou não (quando há divergência na senha) a mensagem é sempre a mesma ("Restauração realizada com Sucesso").

Alguma dica?

Kra eh soh uma ideia mas vc pode pegar a data de um arq. seu ou o tamanho dele e fazer a comparacao depois do processo de restauracao, caso o arq. seja tenha sido alterado poderia se dizer q foi feito a restauracao. Eh logico q n eh um processo 100% mas c vc pegar um arq. mais usado a margem d erro diminui muito.

Marcos Roberto

Marcos, é uma boa dica!

Esse retorno .t. para uma senha divergente não seria um bug?

Antonio Carlos