Trouble Logging into Web API with QNetworkAccessManager
-
-
This post is deleted!
@NuclearPink said in Trouble Logging into Web API with QNetworkAccessManager:
connect(manager, SIGNAL(finished(QNetworkReply*)), SLOT(gotCookies(QNetworkReply*)));
connect(manager, SIGNAL(finished(QNetworkReply*)), SLOT(networkReply(QNetworkReply*)));Any reason why you're connecting same signal to two different slots?
Please be aware that order of slot execution is not guaranteed.
You may want to connect one slot at a time (first gotCookies which inside disconnect and reconnects to networkReply() for instance, or just work with QNetworkReply::finished signal instead
-
This post is deleted!
@NuclearPink
the curl command passes /tmp/cookies.txt what your Qt oode doesn't
so whats its contents?Also check for OpenSSL errors and ensure that your application can find OpenSSL libs
-
@Pablo-J-Rogina My intention there is just to split up two different kinds of responses that aren't related, so I'm not worried about order. The first slot just makes sure a login attempt is made only after cookies are retrieved (and is disconnected once they are), and the second prints out any replies from the server. If my way is bad practice I'll keep it in mind.
@raven-worx I thought that QNetworkAccessManager mostly abstracts cookies which is why I don't try to send them manually. Printing out manager->cookieJar()->cookiesForUrl() in the gotCookies slot shows me that they're retrieved correctly.
Here's a better version of the data that Qt is sending, retrieved from wireshark:
POST /login.cgi HTTP/1.1 Accept: */* Content-Type: multipart/form-data; boundary="boundary_.oOo._MTE4NDAzNTA0MQ==MzIxMzA1Mjg1Mzk2MTkzODgw" MIME-Version: 1.0 Cookie: AIROS_6872518A71F3=c3536a042ab27b9f4d549f1d047bcc1a; ui_language=en_US Content-Length: 298 Connection: Keep-Alive Accept-Encoding: gzip, deflate Accept-Language: en-US,* User-Agent: Mozilla/5.0 Host: 192.168.1.20 --boundary_.oOo._MTE4NDAzNTA0MQ==MzIxMzA1Mjg1Mzk2MTkzODgw Content-Disposition: form-data; name="username" ubnt --boundary_.oOo._MTE4NDAzNTA0MQ==MzIxMzA1Mjg1Mzk2MTkzODgw Content-Disposition: form-data; name="password" password --boundary_.oOo._MTE4NDAzNTA0MQ==MzIxMzA1Mjg1Mzk2MTkzODgw--So it looks like cookies are being sent.
Do I still need to worry about SSL if I'm telling replies to ignore errors? I do a similar thing in curl with the -k option because the Ubiquiti radio uses a self-signed certificate that I haven't set up to accept yet.
-
@Pablo-J-Rogina My intention there is just to split up two different kinds of responses that aren't related, so I'm not worried about order. The first slot just makes sure a login attempt is made only after cookies are retrieved (and is disconnected once they are), and the second prints out any replies from the server. If my way is bad practice I'll keep it in mind.
@raven-worx I thought that QNetworkAccessManager mostly abstracts cookies which is why I don't try to send them manually. Printing out manager->cookieJar()->cookiesForUrl() in the gotCookies slot shows me that they're retrieved correctly.
Here's a better version of the data that Qt is sending, retrieved from wireshark:
POST /login.cgi HTTP/1.1 Accept: */* Content-Type: multipart/form-data; boundary="boundary_.oOo._MTE4NDAzNTA0MQ==MzIxMzA1Mjg1Mzk2MTkzODgw" MIME-Version: 1.0 Cookie: AIROS_6872518A71F3=c3536a042ab27b9f4d549f1d047bcc1a; ui_language=en_US Content-Length: 298 Connection: Keep-Alive Accept-Encoding: gzip, deflate Accept-Language: en-US,* User-Agent: Mozilla/5.0 Host: 192.168.1.20 --boundary_.oOo._MTE4NDAzNTA0MQ==MzIxMzA1Mjg1Mzk2MTkzODgw Content-Disposition: form-data; name="username" ubnt --boundary_.oOo._MTE4NDAzNTA0MQ==MzIxMzA1Mjg1Mzk2MTkzODgw Content-Disposition: form-data; name="password" password --boundary_.oOo._MTE4NDAzNTA0MQ==MzIxMzA1Mjg1Mzk2MTkzODgw--So it looks like cookies are being sent.
Do I still need to worry about SSL if I'm telling replies to ignore errors? I do a similar thing in curl with the -k option because the Ubiquiti radio uses a self-signed certificate that I haven't set up to accept yet.
@NuclearPink said in Trouble Logging into Web API with QNetworkAccessManager:
Here's a better version of the data that Qt is sending, retrieved from wireshark:
so now compare it to the working request with curl.
Then its clear where the difference is.
