Quando faço login e logout de um site específico:https://worldcat.authn.worldcat.org/login/administradouser-ui/cmnd/useraction/login?acsURL=https%3A%2F%2Fauthn.sd00.worldcat.org%2Fwayf%2Fmetaauth-ui%2Fcmnd%2Fprotocol% 2Facs%2Fsaml2&controllerMethod=samlpost(é a página de login do oclc.org/developer), esta é a sequência de solicitações HTTP:
Para login:
Estou usando o proxy Charles.
Não vejo minhas informações de login sendo passadas. E vejo que ao final de cada login/logout, há uma solicitação POST sendo feita com um monte de caracteres inúteis no corpo da entidade. Por exemplo, esta é a solicitação POST do login:
POST / HTTP/1.1
Host: ocsp.digicert.com
User-Agent: ocspd/1.0
Content-Length: 88
Content-Type: application/ocsp-request
Connection: close
0V0T �0M0K0I0 +�_¦zµ'5ÎC£Ç
a1aÕ/(çF8´,áÆÙâ6
¥Þ$QèÖ~èÏ
Estou tentando entender como essa tecnologia funciona. Se minhas informações de login não forem passadas nas solicitações HTTP ou não forem detectadas, por que e de que outra forma elas poderiam ter chegado ao servidor?
Responder1
Você está fazendo login em um site HTTPS, o que significa que a comunicação é criptografada. A solicitação que você procura é na verdade uma das do CONNECT, mas você não conseguirá ver seu conteúdo desta forma.
Você precisa configurar o proxy Charles paraman-in-the-middle sua conexão HTTPS. Isso fará com que o proxy Charles descriptografe o conteúdo que seu navegador está enviando para mostrá-lo a você, antes de criptografá-lo novamente e enviá-lo ao site original. Observe que, conforme mencionado na página vinculada, a menos que você adicione o certificado Charles CA como confiável, isso mostrará um aviso no navegador.
As solicitações POST que você está vendo são, na verdade, devido a HTTPS. Seu navegador está entrando em contato com a CA que emitiu o certificado do site, perguntando se o certificado ainda é válido. Se você quiser entender a solicitação POST que mostrou, leia sobreOCSPe provavelmente encontre um decodificador ASN.1, pois esse é o formato do corpo da solicitação.