Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
TIdHTTP, TIdCookieManager, accepting cookies
#1
Dear All; when using the TIdHTTP and TIdCookieManager components, how do I accept a cookie?

Here's what I'm trying to:

Code:
TIdHTTP *IdHTTP1;
TIdCookieManager *IdCookieManager1;
//...

Code:
//IdHTTP1->CookieManager = IdCookieManager1; - set @ design

Code:
try{
  IdHTTP1->Get(stringServerURL, myMemoryStream);
}catch(...){}

with IdHTTP1->AllowCookies set to true, the Server returns OK and I see in the IdHTTP1->OnHeadersAvailable event handler the line "Set-Cookie: ..." shows 5 times (5 different cookies); the IdCookieManager1->OnNewCookie event also fires 5 times; and IdCookieManager1->CookieCollection->Count == 5 after IdHTTP1->Get() returns.

Looks like Indy components do their job but the server response is a 200Kb HTML doc that basically says "your browser blocks cookies...". I did try to set ACookie argument in the IdCookieManager1->OnNewCookie handler call to true but result is the same.

Please assist; many thanks in advance.
Boba TC.
Reply
#2
(04-02-2022, 01:55 AM)Boba TC Wrote: Dear All; when using the TIdHTTP and TIdCookieManager components, how do I accept a cookie?

You don't do that manually, TIdCookieManager handles that for you.

(04-02-2022, 01:55 AM)Boba TC Wrote: Here's what I'm trying to:
...
Looks like Indy components do their job

Sounds like it, yes.

(04-02-2022, 01:55 AM)Boba TC Wrote: but the server response is a 200Kb HTML doc that basically says "your browser blocks cookies...".

I'm going to guess that although TIdCookieManager is accepting the cookies, maybe it is not sending them back to the server, either due to a logic bug that makes it think they don't belong to the URL being requested, or maybe the cookies themselves are malformed in such a way that prevents it from sending them back.

Are you able to provide the actual URL for testing? Or at least a trace of the raw HTTP requests/responses? You can attach an Intercept component, such as one of Indy's TIdLog... components, to the TIdHTTP::Intercept property.

(04-02-2022, 01:55 AM)Boba TC Wrote: I did try to set ACookie argument in the IdCookieManager1->OnNewCookie handler call to true but result is the same.

I assume you meant VAccept, not ACookie, yes?

Reply
#3
Thank you, Remy, for looking at this;
You are correct, it is the VAccept argument, sorry for typo.
And now is the most funny part of all this troubling exercise:
when I look at the .LOG file I see that my socket has made only 1 SEND and I know there's no way for that server to tell me the truth yet, so I saved contents of my memory stream into HTML file and open the file with 4 different browsers: MozilaFireFox, GoogleChrome, MS IE and MS Edge....... all 4 pages are different: Chrome says "cookies are blocked", Fox: "you need to enable JS", my fingers refuse to type
MS responses 'cause the server in question is microsoftonline.com Big Grin.

So, how in this universe am I suppose to translate the OneDrive for Business authentication and sign in paper from MS English to understandable C++/Delphi?
Any thoughts are very welcome.
Boba TC
Reply
#4
(04-04-2022, 10:28 PM)Boba TC Wrote: So, how in this universe am I suppose to translate the OneDrive for Business authentication and sign in paper from MS English to understandable C++/Delphi?

The HTTP examples given on OneDrive for Business authentication and sign in (and Authorization and sign-in for OneDrive in Microsoft Graph, which you should be using instead) are very straight-forward, should be easy to translate them into TIdHTTP requests.  Cookies should not be a factor in OAuth handling, and JS is certainly NOT used in OAuth. Which makes me think you are not sending your requests to the correct URLs to begin with. But you didn't show your actual code and variable values, so it is hard to know for sure.

Reply
#5
(04-05-2022, 05:35 PM)rlebeau Wrote:
(04-04-2022, 10:28 PM)Boba TC Wrote: So, how in this universe am I suppose to translate the OneDrive for Business authentication and sign in paper from MS English to understandable C++/Delphi?

The HTTP examples given on OneDrive for Business authentication and sign in (and Authorization and sign-in for OneDrive in Microsoft Graph, which you should be using instead) are very straight-forward, should be easy to translate them into TIdHTTP requests.  Cookies should not be a factor in OAuth handling, and JS is certainly NOT used in OAuth.  Which makes me think you are not sending your requests to the correct URLs to begin with.  But you didn't show your actual code and variable values, so it is hard to know for sure.

well... I am using that link and the link clearly says "To start the sign-in process ..., use a web browser or web-browser control to load a URL request."
(All URLs to use are created when you register the application.) What I do not understand is: if Indy TIdHTTP component is basically a socket, 
so how do I run the script sent back in the reply to my request. It is that script that generates what I see when MS reply is viewed as HTML file.
There has to be a way to log-in with no browser usage; am I wrong? TIA.
Reply
#6
(04-06-2022, 09:54 PM)Boba TC Wrote: well... I am using that link and the link clearly says "To start the sign-in process ..., use a web browser or web-browser control to load a URL request."

OAuth does involve a small portion that requires user interaction to transit their credentials and get a token back, but the rest of the OAuth protocol can be handled by any HTTP library.

(04-06-2022, 09:54 PM)Boba TC Wrote: What I do not understand is: if Indy TIdHTTP component is basically a socket, 
so how do I run the script sent back in the reply to my request.

You can't. It needs to be run by a scripting engine, which is outside the scope of Indy.

(04-06-2022, 09:54 PM)Boba TC Wrote: It is that script that generates what I see when MS reply is viewed as HTML file.

You will have to use an embedded browser, such as TWebBrowser or TEdgeBrowser.

(04-06-2022, 09:54 PM)Boba TC Wrote: There has to be a way to log-in with no browser usage; am I wrong?

Yes, you are. At least a portion of the OAuth protocol requires a web browser.

Reply
#7
Thanks. I'll try TWebBrowser. Thanks again, Gambit, for keeping this source of knowledge alive, much appreciated. Boba.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)