PROPOSTA CONTRA FRAUDE NA DATA
A categoria certa seria "Segurança", mas eu vou de "Pizza" mesmo.
O caso começa assim: meu cliente tem uma funcionária bastante competente, mas de pouca confiança (vai entender...
). Por quê? é que ela precisa fazer vários lançamentos numa planilha, e a coisa atrasa de vez em quando. Pra não levar uma esfrega, ela vai e muda a data. Não me venham com "Tira o reloginho do systray!" porque ela já aprendeu a mudar pelo prompt do DOS.
Pronto. Chegamos na velha polêmica do Windows/DOS burrão que deixa todo mundo zoar com a data dele.
Tio Max precisa de uma coisa simples que barre a edição das tabelas se houver fraude. Acompanhem a idéia:
1- Abri o notepad, salvei um arquivo texto em branco e o renomeei como Gama.exe. Gama é o nome da empresa, o que dá um certo respeito quanto ao arquivo. Imagino que ela não vá se atrever a apagar o menino, e se tentar abrir, ele não é reconhecido. Deixei no diretório onde se encontra meu aplicativo, mas poderia deslocá-lo facilmente para o C:\ ou ...\Windows\, aumentando a segurança;
2- Na inicialização do meu aplicativo, coloquei a seguinte rotina:
Sendo "modif" uma variável pública de módulo.
Ou seja, meu aplicativo checa a data da última alteração do pseudo-pograma e joga essa data na variável modif. Se a data atual for menor, babau, pára tudo. Se for maior ou igual, então abro e fecho o Gama.exe só pra atualizar sua data;
3- Como eu carreguei "modif" com aquela data, sempre que for editar a tabela do BD, faço a mesma consulta (If modif > Date Then babau), pra evitar que a funcionária sabidinha mude a data enquanto meu pograminha estiver aberto.
Gostaria que os colegas se pronunciassem sobre esse método. Se é razoavelmente seguro. De antemão, já avisei pro meu cliente que não há rotina 100% segura. Basta que o usuário saiba como a barreira foi feita pra começar a derrubá-la.
O caso começa assim: meu cliente tem uma funcionária bastante competente, mas de pouca confiança (vai entender...
). Por quê? é que ela precisa fazer vários lançamentos numa planilha, e a coisa atrasa de vez em quando. Pra não levar uma esfrega, ela vai e muda a data. Não me venham com "Tira o reloginho do systray!" porque ela já aprendeu a mudar pelo prompt do DOS.Pronto. Chegamos na velha polêmica do Windows/DOS burrão que deixa todo mundo zoar com a data dele.
Tio Max precisa de uma coisa simples que barre a edição das tabelas se houver fraude. Acompanhem a idéia:
1- Abri o notepad, salvei um arquivo texto em branco e o renomeei como Gama.exe. Gama é o nome da empresa, o que dá um certo respeito quanto ao arquivo. Imagino que ela não vá se atrever a apagar o menino, e se tentar abrir, ele não é reconhecido. Deixei no diretório onde se encontra meu aplicativo, mas poderia deslocá-lo facilmente para o C:\ ou ...\Windows\, aumentando a segurança;
2- Na inicialização do meu aplicativo, coloquei a seguinte rotina:
'armazena última alteração
modif = DateValue(FileDateTime(App.Path & "\Gama.exe"))
If modif > Date Then
MsgBox "A data de seu computador está errada." & vbCrLf & "O aplicativo não poderá ser aberto." & vbCrLf & "Corrija a data antes de tentar novamente.", vbCritical, "GamaPack informa:"
Unload Me
Exit Sub
Else
Open App.Path & "\Gama.exe" For Output As #1
Close #1
End If
Sendo "modif" uma variável pública de módulo.
Ou seja, meu aplicativo checa a data da última alteração do pseudo-pograma e joga essa data na variável modif. Se a data atual for menor, babau, pára tudo. Se for maior ou igual, então abro e fecho o Gama.exe só pra atualizar sua data;
3- Como eu carreguei "modif" com aquela data, sempre que for editar a tabela do BD, faço a mesma consulta (If modif > Date Then babau), pra evitar que a funcionária sabidinha mude a data enquanto meu pograminha estiver aberto.
Gostaria que os colegas se pronunciassem sobre esse método. Se é razoavelmente seguro. De antemão, já avisei pro meu cliente que não há rotina 100% segura. Basta que o usuário saiba como a barreira foi feita pra começar a derrubá-la
.
Tive um problema semelhante a um tempo atras.
Alguns computadores, pela idade, perdiam as informacoes do setup. Como o setup buscava a hd automaticamente, o usuario nem percebia que a data estava errada. Então, quando o administrador ia buscar os resultados do dia, parte não encontrava. Obviamente porque os terminais estavam com erros de data.
A solucao que encontrei foi que, de dentro do executavel, o sistema buscar a data e hora do servidor.
Alguns computadores, pela idade, perdiam as informacoes do setup. Como o setup buscava a hd automaticamente, o usuario nem percebia que a data estava errada. Então, quando o administrador ia buscar os resultados do dia, parte não encontrava. Obviamente porque os terminais estavam com erros de data.
A solucao que encontrei foi que, de dentro do executavel, o sistema buscar a data e hora do servidor.
Tópico encerrado , respostas não são mais permitidas