asked on

Can't seem to retrieve cookie using tracking pixel

Hi,
I have set up our own tracking pixel on our main site. If I have a cookie from the site on my machine it is retrieved when I load the pixel directly "https://www.mydomain.com/pixel" in my browser no issue.

So on another site (different domain), I have it on the page as an img tag ie:

<img src="https://www.mydomain.com/pixel">

Open in new window

When I load the other site's page, the page requests the pixel and the script is being triggered but I'm not getting the cookie.

Any idea why??

$request->hasCookie('CRef') // this is loading as 'false'
$request->cookie('CRef') // has no value

gr8gonzo

The best tool for checking these things is Fiddler, but if you don't want to install anything, you can use your browser's developer tools (hit F12) to look at the Network activity and you can usually see the request and response headers.

First, you'll have to make sure the cookie is created on the main domain first and is properly set (if you can share an example raw cookie here, that would be helpful).

Once you've ensured it's properly set, then use the same Network tab on the developer tools to view the request for the tracking pixel from the dealer domain.

tjyoung

ASKER

Hi, i have all this. Give me a sec and I'll upload

tjyoung

ASKER

tjyoung

ASKER

first bit is cookie is set
second bit is from the 'other site'

tjyoung

ASKER

Better copy from Google Chrome Dev tools:

Request URL: https://mydomain.com/pixel?id=saf
Request Method: GET
Status Code: 200
Remote Address: 34.239.130.183:443
Referrer Policy: strict-origin-when-cross-origin
cache-control: private, no-cache, no-cache=Set-Cookie, proxy-revalidate
content-encoding: none
content-length: 42
content-type: image/gif
date: Tue, 19 Jan 2021 20:01:39 GMT
expires: Wed, 11 Jan 2000 12:59:00 GMT
last-modified: Wed, 11 Jan 2006 12:59:00 GMT
pragma: no-cache
server: nginx
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
:authority: mydomain.com
:method: GET
:path: /pixel?id=saf
:scheme: https
accept: image/avif,image/webp,image/apng,image/*,*/*;q=0.8
accept-encoding: gzip, deflate, br
accept-language: en-US,en;q=0.9
if-modified-since: Wed, 11 Jan 2006 12:59:00 GMT
referer: https://othersite.com/
sec-fetch-dest: image
sec-fetch-mode: no-cors
sec-fetch-site: cross-site
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.141 Safari/537.36

ASKER CERTIFIED SOLUTION

Julian Hansen

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

tjyoung

ASKER

I’m on laravel 7 and php 7
Any idea how to set it? Or where? Is it the header when the pixel is passed or somewhere where the cookie is created?

tjyoung

ASKER

Looks like laravel 7 would be in the sessions config? See a setting for lax, none etc. Trying that now

tjyoung

ASKER

As a follow up, I set the samesite to 'none'. Worked great for this, but those who are logged into the actual main site started receiving 403 errors. Switched back to lax and all was well but of course the original issue returns.
Another option I see is 'null' wondering about that perhaps.
Never as simple as one would hope lol

Julian Hansen

We use the SameSite=none for redirects away from the site to Payment Gateway. This broke sometime last year and we traced it to the SameSite setting.

By setting to none when the redirect came from the payment processor the cookie was included in the redirect - without it that did not happen.

I am surprised that you are getting 403's with this.

tjyoung

ASKER

Bit more digging... seemed to get the error when they were doing a POST. So they were logged in ok, but once doing an ajax post, they'd get the error.
Any ideas?

tjyoung

ASKER

could this be anything related?
/*
|--------------------------------------------------------------------------
| HTTP Access Only
|--------------------------------------------------------------------------
|
| Setting this value to true will prevent JavaScript from accessing the
| value of the cookie and the cookie will only be accessible through
| the HTTP protocol. You are free to modify this option if needed.
|
*/

'http_only' => true,

grasping at straws here

Julian Hansen

http_only just means you cannot see or manipulate the cookie in JavaScript. It is still sent with the request providing the protocol, port and domain are the same.

There should be no difference between an AJAX post and a normal HTTP request through the URL or PostBack. The thing to look for is if you are changing the protocol (HTTP vs HTTPS) or the port.

Again - in the scenario I referred to above - all our forms are AJAX - they work fine on the Session cookie - and the redirect from payment processor also works fine.

tjyoung

ASKER

Ok, I'll dig later tonight. Maybe they were still logged in prior to my changes or something.
Regardless, the above did solve the issue so I'll look at the rest and see once they are offline tonight.
Thanks again for your help!