Okay, I'd like to use Cookies for a system. The server returns the cookie in the response, but my next call using a TServerRequest doesn't send it. What are the steps needed to make it work?

Do I need to read the cookie from the response header and add it to Cookies, and that's it? Or do I need to read the cookies and put them in the next request?

(I'm only working in the IDE right now, in case that affects anything)

--

Matthew Jones

Matthew Jones wrote:

> Do I need to read the cookie from the response header and add it to Cookies

Interesting - in PAW I see that there is a header returned called "Set-Cookie". But when I log the request.RequestHeaders there is no such header.

Do I have to pass in an "accept cookies" header or something in the original call?

--

Matthew Jones

Matthew Jones wrote:

> Interesting - in PAW I see that there is a header returned called "Set-Cookie".

Running in Chrome, there is no cookie passed (or at least, not shown in the debug info). I'm confused!

--

Matthew Jones

"Matthew Jones" wrote:

Matthew Jones wrote:

>> Interesting - in PAW I see that there is a header returned called "Set-Cookie".

>Running in Chrome, there is no cookie passed (or at least, not shown in the debug info). I'm confused!

I use a lot of cookies, they work well.  I'm certain the problem is in your server code not passing the cookie.

If you are using PHP, setcookie() is your friend, but you have to call it before sending any body output, as it is part of the header.

Erick
EWB Programming Books and Component Library
http://www.erickengelke.com

Hmm, there is an undocumented "CrossOriginCredentials" option that says something about Cookies. Given I'm accessing a different host in my requests, I guess that is something. Back when I've dug deep.


--

Matthew Jones

erickengelke wrote:

>  I'm certain the problem is in your server code not passing the cookie.

Hmm, I'm not! Just been experimenting, and if I set this CrossOriginCredentials, then the cookie is set (it isn't shown in the debug header info though in Chrome). But, the call fails with the browser complaining about something or other to do with CORS. So the cookie is coming out.

This is probably some CORS thing, and this is a core requirement of the system. Grrr.

--

Matthew Jones

Matthew Jones wrote:

> This is probably some CORS thing

https://stackoverflow.com/questions/43114750/header-in-the-response-must-not-be-the-wildcard-when-the-requests-credentia/43409061

Okay, the server was sending the '*' as the accept, but Chrome doesn't like that if I set the (required) CrossOriginCredentials option. So I've set the CORS policy to be an explicit server, and it works.

--

Matthew Jones

"Matthew Jones" wrote:

Matthew Jones wrote:

> This is probably some CORS thing

>https://stackoverflow.com/questions/43114750/header-in-the-response-must-not-be-the-wildcard-when-the-requests-credentia/43409061

>Okay, the server was sending the '*' as the accept, but Chrome doesn't like that if I set the (required) CrossOriginCredentials option. So I've set the CORS policy to be an explicit server, and it works.

Ah, that would be correct.  It's best to limit cookies to sites you have control over, or trust, rather than *.

There are some additional issues with CORS, such as browsers with ad blocking will often fail because they assume CORS is ads.  And it raises all sorts of stink with security people looking at your code.


But since you say it is a requirement, I'll mention that a good solution to eliminate CORS while having separate servers do the work, is to use a reverse proxy with Apache or NGinx.  There you define a subdirectory in your Web tree as being something the server passes on to another server.  That also passes cookies, BTW.

Erick

Erick
EWB Programming Books and Component Library
http://www.erickengelke.com