Fijxu/invidious
4
4
Fork 2
Code Issues 21 Pull requests Projects Releases Packages 1 Wiki Activity Actions

[Bug] frequent mcaptcha and auto refreshing #35

New issue
Closed
opened 2024-11-06 03:14:59 -03:00 by blucybrb14de · 3 comments
blucybrb14de commented 2024-11-06 03:14:59 -03:00
Copy link

Hello,

I wasn't sure exactly where to report this to, as it's really only a bug that occurs in my browser, I'm currently using the git version of Qutebrowser on Gentoo GNU/Linux:

inxi-output.log

qutebrowser v3.3.1
Git commit: 1127c0de1-dirty on HEAD (2024-10-29 11:17:56 +1300)
Backend: QtWebEngine 6.7.3
based on Chromium 118.0.5993.220

I keep running into problems with mcaptcha appearing really frequently, and refreshing and staying on the page after verifying.

I do use tor with Qutebrowser using a command, which is binded to set content.proxy socks://localhost:9050, as :tor. I have also tried disabling it, before launching invidious/materialious, but it does not seem to make a difference, after so many uses. After running into mcaptcha whenever I revisit on a new tab, it delete the cookies stored for my login.

Logs

Currently not sure if I am able to provide logs, as qutebrowser does not want to launch from my terminal in Hyprland. Not sure if any logs from ~/.local/share/qutebrowser would help, as this is pretty self-described.

Screenshots

Mcaptcha-bug.png

Please let me know if there is anything I am missing, or if there are any workarounds available or addition information that I can provide. Much appreciated.

Hello, I wasn't sure exactly where to report this to, as it's really only a bug that occurs in my browser, I'm currently using the git version of Qutebrowser on Gentoo GNU/Linux: [inxi-output.log](/attachments/66f8ba0b-ffe7-4c7b-a209-a346668435a0) ``` qutebrowser v3.3.1 Git commit: 1127c0de1-dirty on HEAD (2024-10-29 11:17:56 +1300) Backend: QtWebEngine 6.7.3 based on Chromium 118.0.5993.220 ``` I keep running into problems with mcaptcha appearing really frequently, and refreshing and staying on the page after verifying. I do use tor with Qutebrowser using a command, which is binded to set content.proxy socks://localhost:9050, as :tor. I have also tried disabling it, before launching invidious/materialious, but it does not seem to make a difference, after so many uses. After running into mcaptcha whenever I revisit on a new tab, it delete the cookies stored for my login. **Logs** Currently not sure if I am able to provide logs, as qutebrowser does not want to launch from my terminal in Hyprland. Not sure if any logs from ~/.local/share/qutebrowser would help, as this is pretty self-described. **Screenshots** ![Mcaptcha-bug.png](/attachments/59758e8d-0187-4652-86e9-d5c340ced0bd) Please let me know if there is anything I am missing, or if there are any workarounds available or addition information that I can provide. Much appreciated.
Mcaptcha-bug.png
177 KiB
inxi-output.log
15 KiB
blucybrb14de changed title from [Bug] to [Bug] frequent mcaptcha and auto refreshing 2024-11-06 03:16:06 -03:00
Fijxu commented 2024-11-06 14:00:14 -03:00
Owner
Copy link

The captcha is IP based so if you trying to access from the Tor network, I'm guessing your public IP changes every time you do a new connection to a site leading to this behavior.

or if there are any workarounds available

If you accessing from Tor, please use the tor domain at http://inv.nadekonw7plitnjuawu6ytjsl7jlglk2t6pyq6eftptmiv3dvqndwvyd.onion/

The captcha is IP based so if you trying to access from the Tor network, I'm guessing your public IP changes every time you do a new connection to a site leading to this behavior. >or if there are any workarounds available If you accessing from Tor, please use the tor domain at http://inv.nadekonw7plitnjuawu6ytjsl7jlglk2t6pyq6eftptmiv3dvqndwvyd.onion/
blucybrb14de commented 2024-11-07 18:22:11 -03:00
Author
Copy link

After re-testing, it does seem like if I have my default proxy set normally, the behavior does not occur with mcaptcha. I'm guessing there's no tor materialious instance, or a way to save cookies. :(

After re-testing, it does seem like if I have my default proxy set normally, the behavior does not occur with mcaptcha. I'm guessing there's no tor materialious instance, or a way to save cookies. :(
Fijxu commented 2024-11-07 21:31:36 -03:00
Owner
Copy link

About Materialious, you have high chances of getting a captcha if you visit the history page (to see the videos you watched) because if you compare it with the history page of invidious, the Materialious one has video title and channel name whereas Invidious doesn't.

Invidious doesn't store the video details on the database to later show them on the history, so what Materialious does, is to call the /api/v1/videos endpoint to grab the video information like the title and channel, the problem is that calling the /api/v1/videos is very resource intensive and if you request it a lot of times. And materialious calls the api endpoint like with no delay at all so all requests come in a burst to the server, making everything sluggish.

What I want to do, is to store the video information like the Title and channel on the DB so invidious doesn't try to fetch the video every time on third party clients. This has to be a change made on upstream so third party clients can adopt it.

About the privacy concerns, IMO, storing the Title and channel of a video to show it on the history doesn't matter that much because if you enable history, only the IDs of the videos you watch will be stored on the DB but that doesn't mean the admin of the instance cannot know what you watch on Invidious because the ID is already stored lol.

Shit english sorry if you don't understand something lollo!L!!

About Materialious, you have high chances of getting a captcha if you visit the history page (to see the videos you watched) because if you compare it with the history page of invidious, the Materialious one has video title and channel name whereas Invidious doesn't. Invidious doesn't store the video details on the database to later show them on the history, so what Materialious does, is to call the `/api/v1/videos` endpoint to grab the video information like the title and channel, the problem is that calling the `/api/v1/videos` is very resource intensive and if you request it a lot of times. And materialious calls the api endpoint like with no delay at all so all requests come in a burst to the server, making everything sluggish. What I want to do, is to store the video information like the Title and channel on the DB so invidious doesn't try to fetch the video every time on third party clients. This has to be a change made on upstream so third party clients can adopt it. About the privacy concerns, IMO, storing the Title and channel of a video to show it on the history doesn't matter that much because if you enable history, only the IDs of the videos you watch will be stored on the DB but that doesn't mean the admin of the instance cannot know what you watch on Invidious because the ID is already stored lol. *Shit english sorry if you don't understand something lollo!L!!*
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
history-testing
testingbuh
testing3
testing2
testing
xdxdxd
experimental
test
external-proxy
debug
test123
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: Fijxu/invidious#35
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?