Pular para o conteúdo principal

Postagem em destaque

BlackTDN :: Previsão de Horas para Customizações em ERP TOTVS

_Créditos da imagem: Gerada com auxílio do ChatGPT_ --- # **Previsão de Horas para Customizações em ERP TOTVS: Uma Abordagem Baseada em Fatores de Complexidade** No universo de customizações para o ERP da TOTVS, uma das etapas mais desafiadoras é a estimativa precisa do esforço necessário para o desenvolvimento. Muitas vezes, projetos aparentemente simples podem se tornar complexos devido a fatores como dificuldade de acesso ao ambiente ou falta de conhecimento da regra de negócio. Por isso, criamos uma metodologia de cálculo baseada em fatores de ajuste para tornar as estimativas mais precisas e confiáveis. ## **Por que uma boa estimativa é essencial?** Um orçamento mal calculado pode impactar diretamente o cronograma, os custos e até a qualidade da entrega. No caso de projetos relacionados ao ERP TOTVS, onde cada customização está ligada a regras de negócios específicas e a um ambiente muitas vezes complexo, subestimar ou superestimar o tempo necessário pode gerar problemas sign

Protheus :: Autenticação WebService versão 2.0

Dando continuidade ao tema sobre validação de acesso aos métodos do WebService do Protheus, iniciado no "post": Protheus :: Autenticação nos WebServices Protheus. Usando MD5 (Message Digest Algorithm 5) , vou publicar, nesse novo "post", a versão 2.0 do programa ali originalmente publicado. Essas alterações foram necessárias porque minha querida amiga Carla Soneta ( que solicitou o exemplo ) alertou-me sobre possíveis falhas no método anterior, uma vez que qualquer pessoa que tivesse acesso aos métodos de validação e que de alguma forma conseguisse capturar o usuário e senha poderia fazer uso indevido dos métodos ali publicados. Sendo assim, e sem querer encerrar o assunto ( pois existem n maneiras de autenticar um WebService ), vou descrever, em breves palavras, as alterações e melhorias implementadas nessa nova versão.

Essa nova versão, em relação à anterior, traz as seguintes alterações:

1 ) Na anterior o usuário e senha estavam fixos no programa. Nessa versão existe um arquivo de configuração onde vários usuários e várias senhas deverão ser configurados para acesso ao WS. Para que isso fosse possível implementamos o Conceito de "CheckSum". Nesse modelo qualquer senha definida no arquivo de configuração de usuário e senhas poderá ser usada para qualquer usuário e vice-versa. Bastando informar, junto com o usuário e a senha, o "CheckSum" dessa combinação. Mas como isso funciona? Funciona da seguinte forma: O WS de validação de usuário irá procurar no arquivo u_wsuservalid.ini as configurações de usuários e senhas, as senhas não estão diretamente associadas a um determinado usuário, vale para qualquer um. Para que essa verificação seja aceita pelo WS de autenticação, será necessário informar uma combinação numérica que relacione o usuário à senha. por exemplo:

No arquivo de configuração ( u_wsuservalid.ini ) poderemos ter as seguintes informações:

[UserName]
naldodj
Carla
NaldoDj
Soneta
NALDODJ
Carla Soneta
NaldoDJ
CarlaSoneta
NALDOdj
SonetaCarla
NAlDoDj
CarlaS
ODLANJD
SCarla
OdlanJD
SonetaC
odlanjd
CSoneta
OdlanJd
Naldo&Soneta

[UserPassWord]
b3d28e7f822dac10b74101712651597ba152c2fc
Ly9QYXJhIG8gRGVjb2RlNjQgdXNlOiBodHRwOi8vd3d3Lm9waW5pb25hdGVkZ2Vlay5jb20vZG90bmV0L3Rvb2xzL2Jhc2U2NGRlY29kZS8qLw==
9dd867e76e02c3fa10ae50dcc11081c5d2adec57
6148ea40e060b81e0baa6927adffa3b847e8bf38
9dd867e76e02c3fa10ae50dcc11081c5d2adec57
d5582b0680b92e1e5cf378d62d559e196e4a28a2
e17f619c2c04dbc833c700283f094c29
941006ed741ab68bebccfa32885cf013
OTQxMDA2ZWQ3NDFhYjY4YmViY2NmYTMyODg1Y2YwMTM=
IjlkZDg2N2U3NmUwMmMzZmExMGFlNTBkY2MxMTA4MWM1ZDJhZGVjNTci
Ikx5OVFZWEpoSUc4Z1JHVmpiMlJsTmpRZ2RYTmxPaUJvZEhSd09pOHZkM2QzTG05d2FXNXBiMjVoZEdWa1oyVmxheTVqYjIwdlpHOTBibVYwTDNSdmIyeHpMMkpoYzJVMk5HUmxZMjlrWlM4cUx3PT0i
SWt4NU9WRlpXRXBvU1VjNFoxSkhWbXBpTWxKc1RtcFJaMlJZVG14UGFVSnZaRWhTZDA5cE9IWmtNMlF6VEcwNWQyRlhOWEJpTWpWb1pFZFdhMW95Vm14aGVUVnFZakl3ZGxwSE9UQmliVll3VEROU2RtSXllSHBNTWtwb1l6SlZNazVIVW14Wk1qbHJXbE00Y1V4M1BUMGk=
726537f8c72cd9d7cfc5119ce4e5cffc
ba21af37a12b7dc83a5757db430a62ef
QWJvdXQgbWQ1IGNyeXB0b2dyYXBoaWMgaGFzaCBmdW5jdGlvbjo=
9bf60941217f0a2f373ef0019dbfe1ea
ebaafb90de2dfce92005eb20c906437a
ZWJhYWZiOTBkZTJkZmNlOTIwMDVlYjIwYzkwNjQzN2E=
RnJvbSBXaWtpcGVkaWEsIHRoZSBmcmVlIGVuY3ljbG9wZWRpYQ==
Um5KdmJTQlhhV3RwY0dWa2FXRXNJSFJvWlNCbWNtVmxJR1Z1WTNsamJHOXdaV1JwWVE9PQ==

[TimeOut]
1300

Onde:

[UserName] define todos os usuários possíveis para acesso ao WS
[UserPassWord] define todas as senhas possíveis para acesso ao WS
[TimeOut] define o tempo, em segundos, para a validade de uma mensagem obtida através do método GetMessages.

Ex.:

Vamos supor que para a validação do WS foi selecionado o usuário "Naldo&Soneta", observe que na ordem, esse usuário possui o valor 20. E, para a senha, a escolha foi: d5582b0680b92e1e5cf378d62d559e196e4a28a2, que, se observarmos a ordem, teria o valor 6, então, o "CheckSum" para autenticar esse usuário e senha seria 20 + 6, 26. Não existe limite para a quantidade de usuários e de senhas e essa quantidade não precisa, necessariamente, ser igual. Posso ter 10 usuários para 1000 senhas como posso ter 1000 usuários para duas senhas. o "CheckSum" é que irá definir se o usuário ou senha estão ou não corretos. Para que isso fosse possível e, diferente da versão anterior, o método "ValidUserWs" do WS "u_wsUserValid", na versão 2.0 receberá, também, como parâmetro, a propriedade: "CheckSum".

Para que esses usuários e senhas sejam autenticados é necessário que o arquivo de configuração esteja na pasta "\wstoken\" abaixo do "rootpath" do "protheus". O "Client", usuário dos WS também deverá possuir esse arquivo, pois para que os usuários e senhas sejam autenticadas deverão estar nas duas pontas ( no "server" do "protheus" e no Cliente usuário do WS) . É o cliente do WS quem escolhe qual usuário e senha utilizar.

Além do conceito de múltiplos usuários e senhas e "CheckSum", foi implementado, nessa nova versão, o conceito de "TimeOut". Lembrando que para a validação do usuário e senha do WS, além do usuário, senha e, agora, "CheckSum", é necessário informar, também, o "MD5 Hash" de uma mensagem obtida através do método "GetMessage" do WS "u_wsGetMessages". Na versão anterior essa mensagem ia "crua" para o cliente e ele, após obtê-la, calculava o "MD5 Hash" e a devolvia para o método de validação. Nessa nova versão, a mensagem vai criptografada via "Base64". O Cliente solicitante da Mensagem deverá decodificá-la antes de obter o "Hash" a ser enviado para autenticação. O "TimeOut" irá definir o tempo, em segundos, que uma mensagem ,obtida através do método "GetMessage", terá validade.

O método ClearStackMD5Hash também teve um tratamento especial. Na versão anterior, qualquer um, com acesso do WS u_getmessages poderia limpar a "pilha" de mensagens, tornando a autenticação inviável. Na versão 2.0 esse método foi vinculado a um novo WS, o "u_wsClearMessages". Esse novo WS é unica e exclusivamente utilizado para limpar a "pilha de mensagens" obtidas através do método "GetMessage". A diferença básica é que agora, para limpar a "pilha" de mensagens obtidas através de "GetMessage", será necessário autenticar-se também. Ao contrário da versão anterior, o método ClearStackMD5Hash passou a receber, como parâmetro de entrada: UserWs ( Usuário ), UserWsPasswd ( Senha ) , CheckSum ( numero que relaciona o usuário à senha ), Token ( "MD5 Hash" da mensagem obtida através de "GetMessage") e HASHMD5UserAndPsw ( que definirá se deverá ser informado, no usuário e senha, os valores originais ou o "MD5 Hash" de cada um).

O WS para teste desse modelo de autenticação de WS também foi alterado de forma a contemplar as melhorias implementadas na versão 2.0. Os nomes dos programas e dos métodos são sugestivos, então acredito que vocês, caso queiram testa-los e utilizá-los, não terão problema.

Vale lembrar que:

1 ) O arquivo de configuração "u_wsuservalid.ini", que será encontrado na pasta "\wstoken\" ( abaixo do "RootPath" do Protheus), será criado na primeira vez que qualquer método dessa nova versão for executado. Ele deverá ser alterado para atender às suas necessidades.
2 ) Considerando que o programa "u_wsuservalid.prw" contém 3 WS diferentes, deverá ser gerado um "Client" para cada um deles.
3 ) No arquivo disponibilizado logo abaixo estão os "WebServices" bem como os "Clients" de cada um. Os nomes são sugestivos e poderão ser alterados a seu "bel" prazer.

Chega de enrolação e vamos ao que interessa: Clique aqui para obter a nova versão do WS para autenticação.

Carlinha, é sempre um prazer poder te ajudar. Grande abraço desse seu "amigo Malukinho". Obs.: Esse WS já está funcional, se for o seu desejo , e de seu cliente também, é só seguir o modedo implementado no WS de teste para usá-lo.

[]s

Comentários

  1. Naldo...
    tua séria de WS é muito legal. Tô acompanhando já faz um tempo. Num dos códigos vc postou a preparação do Ambiente utilizando RPCSetType(3) ou Prepare Environment.

    Ha casos em que os colegas utilizam a função ChkFile(alias) abrindo tabela a tabela.

    Qual a diferença entre as três alternativas: RPC, Prepare e ChkFile? E em termos de performance?

    []´s
    Marcelo Vicente
    marchvic@totvs.com.br

    ResponderExcluir
  2. Naldo...
    tua séria de WS é muito legal. Tô acompanhando já faz um tempo. Num dos códigos vc postou a preparação do Ambiente utilizando RPCSetType(3) ou Prepare Environment.

    Ha casos em que os colegas utilizam a função ChkFile(alias) abrindo tabela a tabela.

    Qual a diferença entre as três alternativas: RPC, Prepare e ChkFile? E em termos de performance?

    []´s
    Marcelo Vicente
    marchvic@totvs.com.br

    ResponderExcluir
  3. Existe alguma função onde pega uma imagem e converte em binário ?
    O ENCODE64 pega um texto e não uma imagem!!!

    Vlw

    ResponderExcluir

Postar um comentário

Postagens mais visitadas