starred/whoogle-search

Fork 0

mirror of https://github.com/benbusby/whoogle-search.git synced 2026-04-26 12:45:48 +03:00

[GH-ISSUE #538] [BUG] Incorrect initial forwarding session #345

New issue

Closed

opened 2026-02-25 20:35:30 +03:00 by kerem · 8 comments

kerem commented

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

Owner

Originally created by @eddydc on GitHub (Nov 19, 2021).
Original GitHub issue: https://github.com/benbusby/whoogle-search/issues/538

Describe the bug
It seems that there is something wrong with the Nov 18th release concerning the session forwarding. The first time when one starts a search, thing gets forwarded to an URL which couldn't be interpreted. I've configured things in such way that Whoogle runs on port 443 towards my NAS and then reversed proxied to port 5005 internally.
The first time a session URL seems to be generated that couldn't be reverse proxied. All attempts after that works fine, except for the images where not all results are shown.

To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Deployment Method

Heroku (one-click deploy)
[ X] Docker on Synolgy NAS
run executable
pip/pipx
Other: [describe setup]

Version of Whoogle Search

[X ] Latest build from [source] (i.e. GitHub, Docker Hub, pip, etc)
Version [version number]
Not sure

Desktop (please complete the following information):

OS: all
Browser FF
Version [e.g. 22]

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

Originally created by @eddydc on GitHub (Nov 19, 2021). Original GitHub issue: https://github.com/benbusby/whoogle-search/issues/538 **Describe the bug** It seems that there is something wrong with the Nov 18th release concerning the session forwarding. The first time when one starts a search, thing gets forwarded to an URL which couldn't be interpreted. I've configured things in such way that Whoogle runs on port 443 towards my NAS and then reversed proxied to port 5005 internally. The first time a session URL seems to be generated that couldn't be reverse proxied. All attempts after that works fine, except for the images where not all results are shown. **To Reproduce** Steps to reproduce the behavior: 1. Go to '...' 2. Click on '....' 3. Scroll down to '....' 4. See error **Deployment Method** - [ ] Heroku (one-click deploy) - [ X] Docker on Synolgy NAS - [ ] `run` executable - [ ] pip/pipx - [ ] Other: [describe setup] **Version of Whoogle Search** - [X ] Latest build from [source] (i.e. GitHub, Docker Hub, pip, etc) - [ ] Version [version number] - [ ] Not sure **Desktop (please complete the following information):** - OS: all - Browser FF - Version [e.g. 22] **Smartphone (please complete the following information):** - Device: [e.g. iPhone6] - OS: [e.g. iOS8.1] - Browser [e.g. stock browser, safari] - Version [e.g. 22] **Additional context** Add any other context about the problem here.

kerem

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

closed this issue
added the
bug
label

kerem commented

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

Author

Owner

@eddydc commented on GitHub (Nov 19, 2021):

Further investigation seems to reveal that somewhere in the redirect a URL is forced with HTTP instead of HTTPS. Since I've blocked any HTTP requests, this results in an error. I can always trigger this behavior by clicking the preferences link.

@eddydc commented on GitHub (Nov 19, 2021): Further investigation seems to reveal that somewhere in the redirect a URL is forced with HTTP instead of HTTPS. Since I've blocked any HTTP requests, this results in an error. I can always trigger this behavior by clicking the preferences link.

kerem commented

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

Author

Owner

@benbusby commented on GitHub (Nov 22, 2021):

Should be fixed with the above commit. You'll need to set HTTPS_ONLY=1 for your instance to ensure the correct protocol is being used in the redirect.

@benbusby commented on GitHub (Nov 22, 2021): Should be fixed with the above commit. You'll need to set `HTTPS_ONLY=1` for your instance to ensure the correct protocol is being used in the redirect.

kerem commented

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

Author

Owner

@eddydc commented on GitHub (Nov 23, 2021):

Unfortunately it doesn't work all the time and strand sometimes on a non HTTPS url. Version 0.5.4 never has that issue.

@eddydc commented on GitHub (Nov 23, 2021): Unfortunately it doesn't work all the time and strand sometimes on a non HTTPS url. Version 0.5.4 never has that issue.

kerem commented

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

Author

Owner

@benbusby commented on GitHub (Nov 23, 2021):

Nothing changed with routing between 0.5.4 and 0.6.0. Does the 0.6.0 tag have that issue for you? Or are you just using the "latest" build?

Are you able to send me the full session validation URL? It should look like: /session/<uuid>?follow=<redirect url>. With the referenced commit, it should be impossible to "sometimes" redirect to a non-HTTPS URL if you're correctly setting the HTTPS_ONLY var and are using the latest image.

@benbusby commented on GitHub (Nov 23, 2021): Nothing changed with routing between 0.5.4 and 0.6.0. Does the 0.6.0 tag have that issue for you? Or are you just using the "latest" build? Are you able to send me the full session validation URL? It should look like: `/session/<uuid>?follow=<redirect url>`. With the referenced commit, it should be impossible to "sometimes" redirect to a non-HTTPS URL if you're correctly setting the `HTTPS_ONLY` var and are using the latest image.

kerem commented

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

Author

Owner

@eddydc commented on GitHub (Nov 23, 2021):

I'm using the latest tag build
I'm using whoogle mainly as predefined search engine which results in eg /search?q=whoogle
When I click on the images tab, it results in /search?q=gAAAAABhnTlOSGMTy_5mos4ZzyoPRcAXHynLB1W6XdZrKhdTmyb2koHX_8fvXrEjvQsLi1BWp22yd6ViGqL6Zb5lQnMibKe4Tw==&tbm=isch&source=lnms

@eddydc commented on GitHub (Nov 23, 2021): I'm using the latest tag build I'm using whoogle mainly as predefined search engine which results in eg /search?q=whoogle When I click on the images tab, it results in /search?q=gAAAAABhnTlOSGMTy_5mos4ZzyoPRcAXHynLB1W6XdZrKhdTmyb2koHX_8fvXrEjvQsLi1BWp22yd6ViGqL6Zb5lQnMibKe4Tw==&tbm=isch&source=lnms

kerem commented

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

Author

Owner

@eddydc commented on GitHub (Nov 23, 2021):

I don't know if it's important but my whoogle is protected by the userid/pwd parameters and called with the basic authentication in the URL itself, eg https://userid:pwd@server

@eddydc commented on GitHub (Nov 23, 2021): I don't know if it's important but my whoogle is protected by the userid/pwd parameters and called with the basic authentication in the URL itself, eg https://userid:pwd@server

kerem commented

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

Author

Owner

@jackyzy823 commented on GitHub (Dec 17, 2021):

@benbusby

The following url is https however the base redirect url is still http.

example in http headers:

Location: http://<whoogle.tld>/session/?follow=https%3A%2F%2F<whoogle.tld>%2F

so there're several methods.

if using nginx as reverse proxy. then do proxy_redirect http:// https://
use waitress recommend ways

I recommend something like this:

 waitress.serve(app, listen="{}:{}".format(args.host, args.port), url_scheme= 'https'  if bool(os.getenv('HTTPS_ONLY', 0)) else 'http' )

@jackyzy823 commented on GitHub (Dec 17, 2021): @benbusby The following url is https however the base redirect url is still http. example in http headers: Location: http://<whoogle.tld>/session/<uuid>?follow=https%3A%2F%2F<whoogle.tld>%2F so there're several methods. - if using nginx as reverse proxy. then do proxy_redirect http:// https:// - use `waitress` [recommend ways](https://docs.pylonsproject.org/projects/waitress/en/stable/reverse-proxy.html) I recommend something like this: ```python waitress.serve(app, listen="{}:{}".format(args.host, args.port), url_scheme= 'https' if bool(os.getenv('HTTPS_ONLY', 0)) else 'http' ) ```

kerem commented

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

Author

Owner

@eddydc commented on GitHub (Dec 20, 2021):

The first time a browser gets started a userid/pwd popup is prompted despite the fact that they are provided in the URL.
Whoogle is run on a Synology nas and a reverse proxy, which is a stripped-down version of ngix and not a full version (otherwise, I could let the proxy do the authentication). I've set both HTTP as HTTPS as a rule in the proxy.
It is still an issue, even with 0.7.
0.6 has the same issue, but 0.5 never has/had this issue, so it can't blamed on the reverse proxy.

Isn't it better to work with token like searX instead of basic auth (one never knows when the support of credentials in the URL will be ended)?

I hope that a solution will be found soon.

@eddydc commented on GitHub (Dec 20, 2021): The first time a browser gets started a userid/pwd popup is prompted despite the fact that they are provided in the URL. Whoogle is run on a Synology nas and a reverse proxy, which is a stripped-down version of ngix and not a full version (otherwise, I could let the proxy do the authentication). I've set both HTTP as HTTPS as a rule in the proxy. It is still an issue, even with 0.7. 0.6 has the same issue, but 0.5 never has/had this issue, so it can't blamed on the reverse proxy. Isn't it better to work with token like searX instead of basic auth (one never knows when the support of credentials in the URL will be ended)? I hope that a solution will be found soon.

kerem referenced this issue

2026-02-25 20:36:54 +03:00

[PR #345] [MERGED] Add Portuguese Translation #852