mirror of
https://github.com/benbusby/whoogle-search.git
synced 2026-04-25 04:05:57 +03:00
[GH-ISSUE #553] [BUG] Query decryption issue #352
Labels
No labels
Fixed (Pending PR Merge)
Stale
bug
enhancement
enhancement
good first issue
help wanted
keep-open
needs more info
pull-request
question
theme
unfortunate
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/whoogle-search#352
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @FourPeaksAdmin on GitHub (Nov 23, 2021).
Original GitHub issue: https://github.com/benbusby/whoogle-search/issues/553
Describe the bug
When doing a whoogle search, the request comes up in search perfectly fine, but then when switching to images, the address gets messed up and enters from arbitrary search query
To Reproduce
Steps to reproduce the behavior:
Deployment Method
Version of Whoogle Search
"Docker Network Traffic Monitor" becomes "gAAAABhn...." when switching from ALL to Images
@benbusby commented on GitHub (Nov 23, 2021):
It looks like your instance is failing to decrypt your search queries. The second string you're seeing is the encrypted contents of the search, but somehow your session key is being reset between actions.
What browser are you using? Do you have any plugins enabled that block cookies?
Also, are you pulling the
0.6.0tag or thelatesttag (which also shows "Version 0.6.0" on the home page)?@benbusby commented on GitHub (Nov 23, 2021):
Also, for future reference, it's usually best to blur out or crop out your actual search URL in screenshots unless you want other users using your instance.
That being said, I was able to navigate to your instance home page and perform the same steps (search something -> switch to other result tab) without any issues. I'm guessing this is an issue with how your browser is performing the search, since it looks like you're searching using your browser's URL bar to perform the search. I'm curious if somehow the session key is being reset that way.
If you're not already, I'd recommend using the
latestdocker tag for now.@FourPeaksAdmin commented on GitHub (Nov 23, 2021):
I am using the latest image pulled
image: benbusby/whoogle-search:latestI also tried navigating to the search url and just doing a search from within there and like you, am not experiencing this issue.
This is the search query url I have baked into the custom search for the address bar
https://search.fourpeakslandscape.com/search?lr=&safe=off&gbv=1&nfpr=1&q=%sAs for showing my public instance, Im not concerned as I can just change the url in traefik and I can use the new URL, but thank you for the the reminder as I did technically space on that part lol.
As for the browser, im using vivaldi and on the last version of Whoogle I did not have this issue, I will test on firefox and see if the same result happens.
UPDATELooks like it must be a glitch in the matrix because its not happening anymore in vivaldi right now. Must just be a random thing that happens. But, since its not happening currently, not much to go on so maybe just close the ticket?
@benbusby commented on GitHub (Nov 23, 2021):
Hmm. I'm curious why you would've encountered the issue in the first place, but I'll just close the issue in the meantime. My best guess is that something weird happened where either Vivaldi performed the search without a valid session (so using the app's default encryption key), but the next action you took (switching result tabs) had a valid session and was using a different key (and therefore unable to decrypt the query properly).
@accountForIssues commented on GitHub (Feb 17, 2022):
@benbusby I can replicate this issue (latest docker version as of Feb 16).
If I right click search a word in Firefox (Android or Fedora Linux) or Chromium, the search page URL is
https://whoogle-instance/search?cookies_disabled=1and when I click on next (page of results), the issue in OP appears.The cookies are not disabled as I can see a cookie stored using Dev Tools. Also, the same cookie is used fine for subsequent searches.
Further, in the initial page of results, any images/resources don't appear so there is definitely an issue with decryption.
However, if I click on a different result tab such as images/videos, the search works properly. If I then go back and click next, the next page also works fine. So, switching result tabs lets Whoogle know of the local session so the subsequent requests are properly decrypted.
I noticed that switching result tabs perform a GET request with plain text query whereas going to the next page of results sends an encrypted query.
Can anything be done on Whoogle's side ? Like if Whoogle cannot detect a valid session (I assume that's what's happening in the initial request), then the
Nextpage should also be requested using plain text GET.