Incorrect referrer parameter in /api/send

[broscr]

Describe the Bug

When redirecting from Google to a website, it was detected that the document. referrer was correct, but the referrer carried in the request sent by/API/send was incorrect, resulting in the source domain name being none in the monitoring data

Database

PostgreSQL

Relevant log output

No response

Which Umami version are you using? (if relevant)

2.11.3

Which browser are you using? (if relevant)

Chrome

How are you deploying your application? (if relevant)

NodeJS v: 18.19.1 - NextJS v:12.0.7

[jungju]

I am experiencing the same issue. I am also using Next.js.

[FabioGodoyy]

I'm facing a similar problem where the document.referrer is accurate, but the referrer passed in the /api/send request is incorrect, leading to the absence of the originating domain in the analytics data. My setup includes NodeJS v18.17.1 and NextJS v14.1.0. Has anyone found a workaround for this issue?

[fxck]

Having the same problem, funnily enough, when I used a manually beautified version of the script.js it works properly.

edit: I'm gonna try the source script as well https://github.com/umami-software/umami/blob/master/src/tracker/index.js I'm thinking there has to be some problem with the minification process

edit2: ok, it's not a minification problem

something seems to be happening with currentRef inside the init() function, before calling init it still has the correct value, inside init it does not

it seems to have the correct value up until it actually goes through this condition

if (document.readyState === 'complete' && !initialized) {}

and funnilly enough if you read referrer !== hostname ? referrer : '' at the same point the value is already messed up, it still returns the correct referref value

edit3:

handlePush is the cuplrit, it changes the referrer before it has a chance to send the initial request

[fxck]

This should work as a temp fix https://gist.github.com/fxck/4f31c37eb9a6fbca09c39518c07e55e6 use at your own risk.

[obstkompost]

i think i have the same issue

[mikecao]

@fxck Can you open a PR with your changes?

[obstkompost]

it would be great, if this could be fixed in the next version

[fxck]

@mikecao I could, but I didn't because I had to do some significant changes and hack around the way the script is initialized, including adding a little event queue. And I'm absolutely not sure that it won't break any other use cases. I would be the best if the person that wrote the script originally looked into my findings here and fixed it properly.

[mikecao]

This is now fixed in dev, 291c64f

Will get a release out soon.

[mikecao]

Fixed in v2.13.2.

[andreagrandi]

@mikecao I'm running the 2.13.2 version but as you can see from the screenshot I'm still experiencing this bug.
Note: I've updated the app yesterday and the data you see is only from today, so the bug is still present.