starred/whoogle-search

Fork 0

mirror of https://github.com/benbusby/whoogle-search.git synced 2026-04-25 04:05:57 +03:00

[GH-ISSUE #749] [BUG] Whoogle Link redirecting to one with cookies disabled #473

New issue

Closed

opened 2026-02-25 20:35:51 +03:00 by kerem · 6 comments

kerem commented

2026-02-25 20:35:51 +03:00

Owner

Originally created by @fxzzi on GitHub (May 5, 2022).
Original GitHub issue: https://github.com/benbusby/whoogle-search/issues/749

Hello, I am using a local instance of Whoogle. Navigating the to the page http://localhost:5000/ Works completely fine, but if I try accessing it from my startpage: https://fxzzi.github.io/startpage/ It sends me to the link http://localhost:5000/?cookies_disabled=1

This occurs on Firefox and Librewolf. I am not sure whether it's a problem with Whoogle or Librewolf.

Originally created by @fxzzi on GitHub (May 5, 2022). Original GitHub issue: https://github.com/benbusby/whoogle-search/issues/749 Hello, I am using a local instance of Whoogle. Navigating the to the page [http://localhost:5000/](http://localhost:5000/) Works completely fine, but if I try accessing it from my startpage: [https://fxzzi.github.io/startpage/](https://fxzzi.github.io/startpage/) It sends me to the link [http://localhost:5000/?cookies_disabled=1](http://localhost:5000/?cookies_disabled=1) This occurs on Firefox and Librewolf. I am not sure whether it's a problem with Whoogle or Librewolf.

kerem closed this issue

2026-02-25 20:35:51 +03:00

kerem commented

2026-02-25 20:35:51 +03:00

Author

Owner

@fxzzi commented on GitHub (May 6, 2022):

This bug made Whoogle useless for me.

This right here.

@fxzzi commented on GitHub (May 6, 2022): > This bug made Whoogle useless for me. This right here.

kerem commented

2026-02-25 20:35:51 +03:00

Author

Owner

@onedr0p commented on GitHub (May 7, 2022):

I think @benbusby should document what causes this to happen. What are the causes of cookies being disabled when you have this behind a reverse proxy. It's not very user friendly.

@onedr0p commented on GitHub (May 7, 2022): I think @benbusby should document what causes this to happen. What are the causes of cookies being disabled when you have this behind a reverse proxy. It's not very user friendly.

kerem commented

2026-02-25 20:35:51 +03:00

Author

Owner

@navhawk80 commented on GitHub (May 9, 2022):

I found this bug since 0.7.0 version. This bug is not presented in old 0.6.0. version. So I'm using 0.6.0 till it will be fixed in 0.7....

@navhawk80 commented on GitHub (May 9, 2022): I found this bug since 0.7.0 version. This bug is not presented in old 0.6.0. version. So I'm using 0.6.0 till it will be fixed in 0.7....

kerem commented

2026-02-25 20:35:51 +03:00

Author

Owner

@benbusby commented on GitHub (May 10, 2022):

I just pushed a commit that should fix the issue documented here (accessing a Whoogle instance from an external link causing configuration/cookies to be disabled).

The cause of this was the SameSite attribute being set to strict, which disallows session persistence for requests initiated by a third party (see: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite#strict). This was originally implemented in a (perhaps misguided) attempt to improve overall security, but came at the cost of breaking functionality when interacting with the app from a third party context. This has been updated to use lax for the SameSite attribute, which will allow access from external links without disrupting configuration/sessions.

As far as how this cookies_disabled state is reached, session validation occurs as follows:

User visits Whoogle instance for the first time
Flask creates a session id for the user (ex/ "asdf123")
Flask initiates a temporary redirect to a /session endpoint, with the previous session id included as a URL param (i.e. /session/asdf123)
The Flask session is validated against the session ID provided in the URL
- If the session from the URL param does not match the session that Flask created for that user, then the command to create the cookie for the user must have failed for some reason (typically this is seen when a user's environment is configured to block cookie creation). The cookies_disabled param is then appended to subsequent requests to avoid a situation where Flask continuously attempts creating a new session every time that user hits a Whoogle endpoint.
- If the session from the URL param does match the session that Flask created for the user, then the cookie has successfully been set and the user can reliably have a unique configuration for that instance.
User is redirected to the appropriate page, with or without the cookies_disabled param attached

In short, this solution was devised as a way to create a mostly equal "session experience" for users and instance maintainers without A) relying on users to enable Javascript, B) causing runaway session creation for public instance maintainers, and C) allowing users with cookies blocked to still be able to use Whoogle, albeit in a diminished capacity.

Let me know if anyone needs any clarification regarding anything I've mentioned.

@benbusby commented on GitHub (May 10, 2022): I just pushed a commit that should fix the issue documented here (accessing a Whoogle instance from an external link causing configuration/cookies to be disabled). The cause of this was the `SameSite` attribute being set to `strict`, which disallows session persistence for requests initiated by a third party (see: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite#strict). This was originally implemented in a (perhaps misguided) attempt to improve overall security, but came at the cost of breaking functionality when interacting with the app from a third party context. This has been updated to use `lax` for the `SameSite` attribute, which will allow access from external links without disrupting configuration/sessions. As far as how this `cookies_disabled` state is reached, session validation occurs as follows: 1. User visits Whoogle instance for the first time 2. Flask creates a session id for the user (ex/ "asdf123") 3. Flask initiates a temporary redirect to a `/session` endpoint, with the previous session id included as a URL param (i.e. `/session/asdf123`) 4. The Flask session is validated against the session ID provided in the URL - If the session from the URL param **does not** match the session that Flask created for that user, then the command to create the cookie for the user must have failed for some reason (typically this is seen when a user's environment is configured to block cookie creation). The `cookies_disabled` param is then appended to subsequent requests to avoid a situation where Flask continuously attempts creating a new session every time that user hits a Whoogle endpoint. - If the session from the URL param **does** match the session that Flask created for the user, then the cookie has successfully been set and the user can reliably have a unique configuration for that instance. 5. User is redirected to the appropriate page, with or without the `cookies_disabled` param attached In short, this solution was devised as a way to create a mostly equal "session experience" for users and instance maintainers without A) relying on users to enable Javascript, B) causing runaway session creation for public instance maintainers, and C) allowing users with cookies blocked to still be able to use Whoogle, albeit in a diminished capacity. Let me know if anyone needs any clarification regarding anything I've mentioned.

kerem commented

2026-02-25 20:35:51 +03:00

Author

Owner

@DUOLabs333 commented on GitHub (May 16, 2022):

Thanks! The commit referenced fixed an unrelated bug where the CSS sometimes didn't load. Not sure what cookies had to do with it though.

@DUOLabs333 commented on GitHub (May 16, 2022): Thanks! The commit referenced fixed an unrelated bug where the CSS sometimes didn't load. Not sure what cookies had to do with it though.

kerem commented

2026-02-25 20:35:51 +03:00

Author

Owner

@hj-collab commented on GitHub (Jun 8, 2022):

@benbusby Facing the same issue with 0.7.3. Any solution?

@hj-collab commented on GitHub (Jun 8, 2022): @benbusby Facing the same issue with 0.7.3. Any solution?

kerem referenced this issue

2026-02-25 20:37:01 +03:00

[PR #473] [MERGED] feat: block title or url by regex #887