Graylog creates a cookie on the top-level domain, instead of its subdomain about graylog2-server HOT 9 OPEN

Hey @AnnoyingTechnology,

thanks for reporting this. Just to clarify: you are talking about the first of the two cookies (the one starting with ph_phc_) which is problematic, while the authentication cookie is fine?

Edit: You are explaining that already in the first sentence, sorry.

from graylog2-server.

Related: #15527

from graylog2-server.

Thanks, @coffee-squirrel! I think disabling telemetry for now is a valid workaround if the overly wide cookie domain is an issue for you.
I think we should try to fix that nonetheless, as we want users to have as little privacy/security issues as possible when deciding to send telemetry data, because it helps us improving the product (finding out if features are actually used, at which scale, which user flows can be streamlined, etc.).
The cookie is set by the Posthog client library and it looks like they are doing this (setting it to *.domain.tld) on purpose to allow cross-domain tracking. We do not want this and it makes little sense for an on-premise product, so I hope there is a way to disable it.

from graylog2-server.

We experienced the same issue as @hydrapolic, created a separate issue since the cookie broke it for us, but the domain is irrelevant here.

Regarding the actual issue here: The top-level domain cookie does not make any sense at all, since we use graylog.<environment>.example.com with multiple instances and these cookies would get mixed up constantly.

from graylog2-server.

Hi @AnnoyingTechnology,

if you disable telemetry globally (graylog.conf ) the cookies gets not created.

# New for 5.1 disable telemetry global for all users
telemetry_enabled = false

best regards

from graylog2-server.

Wow, that's unexpected but it checks out.

Thanks!

(still a security concern for people who don't notice and leave this enabled)

from graylog2-server.

Hi @AnnoyingTechnology,

if you disable telemetry globally (graylog.conf ) the cookies gets not created.

# New for 5.1 disable telemetry global for all users
telemetry_enabled = false

best regards

Probably an other issues, but users not having telemetry disable could not connect to graylog after upgrading from 5.1 -> 5.2. Graylog is behind nginx with oauth2-proxy doing the authentication.

After setting telemetry_enabled = false they could login again. By checking the Cookie, it was very long containing special chars, so probably the processing in graylog changed for 5.2?

from graylog2-server.

Hey @hydrapolic,

do I understand you correctly that with Graylog 5.2 you were not able to login when telemetry was enabled? What error did you see? Can you create a separate issue for this?

from graylog2-server.

Hey @hydrapolic,

do I understand you correctly that with Graylog 5.2 you were not able to login when telemetry was enabled? What error did you see? Can you create a separate issue for this?

Yes, after upgrading from Graylog 5.1 to 5.2, users were unable to login, they received error 400. My user was able to login because I had telemetry disabled previously. After setting telemetry_enabled = false globally, users were able to login.

The only difference I saw was the cookie, mine was shorter, while the users had telemetry data in the cookie. Probably the cookie processing changed in 5.2 so that it's more stricter what to accept?

Unfortunately I don't have the logs any more, but I see no errors in the graylog log from that day, just http 400 from graylog in the nginx log.

We use oauth2-proxy with Azure for password management.

from graylog2-server.