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]
b3d28e7f822
dac10b74101712651597
ba152c2
fc
Ly9
QYXJhIG8
gRGVjb2
RlNjQgdXNlOiBodHRwOi8
vd3d3
Lm9
waW5
pb25
hdGVkZ2
Vlay5
jb20
vZG90
bmV0L3
Rvb2
xzL2
Jhc2U2
NGRlY29
kZS8
qLw==
9
dd867e76e02c3
fa10
ae50
dcc11081c5d2
adec57
6148
ea40e060b81e0
baa6927
adffa3b847e8
bf38
9
dd867e76e02c3
fa10
ae50
dcc11081c5d2
adec57
d5582b0680b92e1e5
cf378d62d559e196e4a28a2
e17f619c2c04
dbc833c700283f094c29
941006
ed741
ab68
bebccfa32885
cf013
OTQxMDA2
ZWQ3
NDFhYjY4
YmViY2
NmYTMyODg1Y2
YwMTM=
IjlkZDg2N2U3
NmUwMmMzZmExMGFlNTBkY2
MxMTA4
MWM1
ZDJhZGVjNTci
Ikx5
OVFZWEpoSUc4Z1
JHVmpiMlJsTmpRZ2
RYTmxPaUJvZEhSd09
pOHZkM2
QzTG05d2
FXNXBiMjVoZEdWa1
oyVmxheTVqYjIwdlpHOTBibVYwTDNSdmIyeHpMMkpoYzJVMk5
HUmxZMjlrWlM4
cUx3PT0i
SWt4NU9
WRlpXRXBvU1
VjNFoxSkhWbXBpTWxKc1
RtcFJaMlJZVG14
UGFVSnZaRWhTZDA5
cE9
IWmtNMlF6
VEcwNWQyRlhOWEJpTWpWb1
pFZFdhMW95
Vm14
aGVUVnFZakl3
ZGxwSE9
UQmliVll3
VEROU2
RtSXllSHBNTWtwb1l6
SlZNazVIVW14
Wk1
qbHJXbE00Y1V4M1
BUMGk=
726537f8c72
cd9d7
cfc5119
ce4e5
cffc
ba21
af37a12b7
dc83a5757
db430a62
ef
QWJvdXQgbWQ1
IGNyeXB0b2
dyYXBoaWMgaGFzaCBmdW5
jdGlvbjo=
9
bf60941217f0a2f373
ef0019
dbfe1
ea
ebaafb90de2
dfce92005
eb20c906437a
ZWJhYWZiOTBkZTJkZmNlOTIwMDVlYjIwYzkwNjQzN2E=
RnJvbSBXaWtpcGVkaWEsIHRoZSBmcmVlIGVuY3
ljbG9
wZWRpYQ==
Um5
KdmJTQlhhV3
RwY0
dWa2
FXRXNJSFJvWlNCbWNtVmxJR1Z1
WTNsamJHOXdaV1
JwWVE9
PQ==
[
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: d5582b0680b92e1e5
cf378d62d559e196e4a28a2, 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
Naldo...
ResponderExcluirtua 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
Naldo...
ResponderExcluirtua 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
link quebrado dos fontes! =(
ResponderExcluirCesar, agradecemos o aviso. O Link já foi restaurado.
Excluirlink quebrado dos fontes
ResponderExcluirCesar, agradecemos o aviso. O Link já foi restaurado.
ExcluirExiste alguma função onde pega uma imagem e converte em binário ?
ResponderExcluirO ENCODE64 pega um texto e não uma imagem!!!
Vlw
Sim. Tem!
ResponderExcluir