Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[BUG] Whoogle Link redirecting to one with cookies disabled #749

Closed
Fxzzi opened this issue May 5, 2022 · 6 comments
Closed

[BUG] Whoogle Link redirecting to one with cookies disabled #749

Fxzzi opened this issue May 5, 2022 · 6 comments

Comments

@Fxzzi
Copy link

Fxzzi commented May 5, 2022 •
edited

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.
@Fxzzi
Copy link
Author

Fxzzi commented May 6, 2022

This bug made Whoogle useless for me.

This right here.

@onedr0p
Copy link

onedr0p commented 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.

@navhawk80
Copy link

navhawk80 commented May 9, 2022 •
edited

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....

@benbusby
Copy link
Owner

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.

@DUOLabs333
Copy link
Contributor

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.

TrueMysterious pushed a commit to TrueMysterious/whoogle-search that referenced this issue May 26, 2022
@pull @benbusby
@SuperSandro2000 @invis-z @xatier @hoschi1337 @dr460nf1r3 @jacr13
[pull] main from benbusby:main (#8)
21a6913 
* Render error message w/o `safe` filter

The error message shown in the error template does not need to be
rendered using the safe filter, and furthermore opens up an XSS
vulnerability.

* Only create ip card if main result div is found

The ip address card that is created for searches like "my ip" only needs
to be created/inserted if a main result div id is found.

Fixes benbusby#735

* Remove unused `/url` endpoint

The `/url` endpoint was previously used as a way of mirroring the
`/url?q=<result domain>` formatting of locations in search results from
Google. Rather than have this unnecessary intermediary step, the result
path was extracted and used as the immediate path for each result item
instead.

This endpoint hasn't been in use for many versions and has been in need
of removal for quite some time.

* Bump version to 0.7.2

* Fix pipx dependencies (benbusby#738)

Missing cssutils

* Remove "/" before endpoints & tags (benbusby#734)

Removes the leading slash before imgres and other endpoints

Fix benbusby#733

* Add `WHOOGLE_URL_PREFIX` to app.json (benbusby#737)

* Update zh-tw translation (benbusby#736)

* Fix german translation error (benbusby#742)

"Nachrichten" is the correct translation of "News"

* Replace public instance url

s.alefvanoon.xyz -> s.tokhmi.xyz

Fixes benbusby#743

* Use `window` from Endpoint enum for anon view (benbusby#748)

Removes previously hardcoded "/window" from anon view links

* Update and add instances [skip ci] (benbusby#750)

Updates Garudalinux instance
Add dr460nf1r3.org instance

* Use `lax` for session `SameSite` value (not `strict`)

SESSION_COOKIE_SAMESITE must be set to 'lax' to allow the user's
previous session to persist when accessing the instance from an external
link. Setting this value to 'strict' causes Whoogle to revalidate a new
session, and fail, resulting in cookies being disabled.

This could be re-evaluated if Whoogle ever switches to client side
configuration instead.

Fixes benbusby#749

* Improve G page distinction between footer and results

Pages in the Whoogle footer that by default route to Google pages were
previously being removed, but caused results that also routed to similar
pages to no longer be accessible. This was due to the removal of the
'/url' endpoint that Google uses for each result.

To fix this, the result link is now parsed so that the domain of the
result can be checked against the disallowed G page list. Since results
are delivered in a "/url?q=<domain>" format -- even for pages to
Google's own products -- and the footer links are formatted as
"<product>.google.com", footer links are removed and result links are
parsed correctly.

Fixes benbusby#747

* Replace leading slash for image links (benbusby#762)

The leading slash was previously removed without noticing it was part of a
string replacement in benbusby#734. This caused the href of "View Image" contain a
leading "/" which is wrong.

* Remove duplicated handling of /url result links (benbusby#769)

It appears that result links beginning with '/url' were mistakenly
commited with an inefficient filtering process in its place. With the
way the code is structured, this less effective '/url' link filter took
precedence over the previous link filter, and also caused users with the
"open link in new tab" config enabled to no longer have access to that
feature.

Fixes benbusby#769

Co-authored-by: Ben Busby <contact@benbusby.com>
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
Co-authored-by: invis-z <22781620+invis-z@users.noreply.github.com>
Co-authored-by: xatier <xatierlike@gmail.com>
Co-authored-by: hoschi1337 <58056262+hoschi1337@users.noreply.github.com>
Co-authored-by: Nico <njcrypted@protonmail.com>
Co-authored-by: Joao A. Candido Ramos <joao.candido@etu.unige.ch>
@hj-collab
Copy link

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

@benbusby benbusby mentioned this issue Aug 1, 2022
Closed
8 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@onedr0p @Fxzzi @benbusby @DUOLabs333 @navhawk80 @hj-collab