Hi.

I'm trying to login to a website using the following code:

oHTTP=CREATEOBJECT("wwHttp")
oHTTP.AddPostkey("username","123456789")    && Dummy username
oHTTP.Addpostkey("password","a1b2c3")       && Dummy password
lcHTML = oHTTP.HTTPGet( "https://www.acesso.gov.pt/v2/loginForm?partID=PFAP&path=/geral/dashboard")

I'm getting error 500 from it.

I have also tried to pass username and password as parameters to HTTPGet but the result is the same.

If I create an object using InternetExplorer.Application and do the login with the same credentials, I manage to do it successfully.

TIA,

Carlos

Well that depends entirely on what the server is expecting you to send. Maybe you're not sending all the information that is required.

To check this - use an Http Proxy tool like Fiddler or the browser dev tools to look at all the HTTP headers that are sent and what format the POST data is sent. Many sites require more than just the fields on a form to submit and authentication often involves JavaScript operations that you can't automate with plain HTTP requests like this.

Just took a quick look - here's what the client sends:

POST https://www.acesso.gov.pt/v2/login HTTP/1.1
Host: www.acesso.gov.pt
Connection: keep-alive
Content-Length: 153
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
Origin: https://www.acesso.gov.pt
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4023.0 Safari/537.36 Edg/81.0.396.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Referer: https://www.acesso.gov.pt/v2/loginForm?partID=PFAP&path=/geral/dashboard
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Cookie: autentica_JSessionID=F8fTpqQP1ftGhkSgnMbvsm2hChp7DN3RH6LHQL11pZ4NCGqzgy22!864191444!-1103816643; ACESSONOVO-47873-SG_ACESSO_SUL=JJJFLPAKFAAA

path=%2Fgeral%2Fdashboard&partID=PFAP&authVersion=2&_csrf=cfc860c9-1cd0-4d21-8f23-adfff0e61ed2&selectedAuthMethod=N&username=123456789&password=123456789

There's a cookie set and a few more variables to pass to the server. I suspect you have to set all those values not just the username and password.

Realize that you can't automate everything using just HTTP requests and most likely this site doesn't want you to do this so there are protections against making this easy. The Cross-Site reference cookie is going to make this very difficult to process with plain HTTP requests unless you parse the incoming GET request first.

+++ Rick ---

Hi, Rick.

Thank you for your reply.

About the first error, I didn't realize that I was using a previous version of wwIpStuff (my fault 😉 ).

In terms of this request, I have noticed that this auth cookie is using during all the operations. Is there a way of using this cookie during the subsequent requests or keeping it alive until we do the logoff?

Thanks,

Carlos

Yes you can capture cookies and pass them along, but the way this works is that you probably have to hit the GET page first to receive the cookie.

wwHTTP (and WinInet) picks up any cookies it gets by default and stores them and the sends them back on the next request so you probably don't even have to do anything else. If that doesn't work you can capture the cookie from the HTTP headers of the first request and then send it in the outgoing headers of the second request.

+++ Rick ---

Hello, Rick.

I'm going to try it meanwhile.

Thanks for your help,

Carlos

Hello, Rick.

It seems that it is not possible to get the files I want using http requests 😦

I even tried to do a mix between InternetExplorer.Application and your library, getting the cookie from the first one and adding it before the request but I'm still unable to get them.

Thanks.

I'm not surprised although using IE automation you should be able to play back a request sequence that works. There are also other solutions using Chromium based automation engines that can be used, but those require large runtime installs (basically chromium).

Looks to me though you're trying to do something that the site owners do not want you to do, eh? 😃 So probably not a bad thing this doesn't work. If they wanted to make that data available they would have an API to access it...

+++ Rick ---

So it seems 😉

Thanks.