Login broken on instances served on the tor network if they are also served on the clearnet

[stemy2]

Hello,

I can login and perform a search on instances, but when i'm switching on their onion version (using the button "onion site" on the Tor adress bar), it doesn't work as well, logginig in redirects me to homepage where i'lm still disconnected and search returns me zero results. I tested with all instances that happens to have an onion version.

For wich reason are there issues on onion sites that doesn't exist on their clearweb version ?

[Perflyst]

I dont think it was ever possible to login on an onion instance which actually was just a clearnet instance but is exposed through an onion url too. The reason is that in the config file https is set to true and also a domain is configured. Those settings are used in the cookie for the login.

To support login on onion, I think you would need to host a onion only instance. Maybe invidious could support serving two domains at the same time.

Searching is also broken on clearnet, see https://github.com/iv-org/invidious/issues/1422

[FireMasterK]

Fixed on http://w6ijuptxiku4xpnnaetxvnkc5vqcdu7mgns2u77qefoixi63vbvnpnqd.onion/

[Kreyren]

I was brainstorming this with snopyta's maintainers

Observed issues

We noticed following issue highlighted in (among others) RSS feed i.e. http://c7hqkpkpemu6e7emz5b4vyz7idjgdvgaaa3dyimmeojqbgpea3xqjoid.onion/channel/UCVls1GmFKf6WlTraIb_IaJg generates XML file storing:

<feed xmlns:yt="http://www.youtube.com/xml/schemas/2015" xmlns:media="http://search.yahoo.com/mrss/" xmlns="http://www.w3.org/2005/Atom" xml:lang="en-US">
  <link rel="self" href="/feed/channel/UCVls1GmFKf6WlTraIb_IaJg"/>

Which is invalid due to the

href="/feed/channel/UCVls1GmFKf6WlTraIb_IaJg"

that expects

href="http://c7hqkpkpemu6e7emz5b4vyz7idjgdvgaaa3dyimmeojqbgpea3xqjoid.onion/feed/channel/UCVls1GmFKf6WlTraIb_IaJg"

assuming config.domain set to nil.

Which is supposed to expand from variable HOST_URL defined at https://github.com/iv-org/invidious/blob/192d2b86b61f2212d1ae5423eba033deaf386c01/src/invidious.cr#L55 that expands in https://github.com/iv-org/invidious/blob/192d2b86b61f2212d1ae5423eba033deaf386c01/src/invidious/helpers/utils.cr#L273

Proposed solution

I was helping set up dotya.ml's hidden service for gitea which had/has same issue as explained in https://git.dotya.ml/dotya.ml/community/issues/21

and resolved in https://git.dotya.ml/dotya.ml/gitea-templates/commit/26b38bf13d6b145f073f033378f7c1afdc2cdcea in terms of image sources to use relative paths.

but i think the solution here should be to rework https://github.com/iv-org/invidious/blob/master/src/invidious/helpers/utils.cr#L273 to allow for hidden_service property in config with logic to expand based on deployment? Where i am not sure what would be the expression to handle e.g.

On clear -> Store invidious.snopyta.org in HOST_URL On hidden -> Store c7hqkpkpemu6e7emz5b4vyz7idjgdvgaaa3dyimmeojqbgpea3xqjoid.onion in HOST_URL

---

Happy to consider contribution based on what we agree on should be the solution.

---

UPDATE: These variables can be used to to craft expression based on where the service is deployed:

• {env.request.host}

• {host}

• {request.host}

I currently can't develop solution due to the https://github.com/iv-org/invidious/issues/1487

[TheFrenchGhosty]

A 10$ bounty has been added to this issue.

Anyone opening a PR fixing this issue, will receive 10$ (in BTC) from the Invidious project.

More details: https://github.com/iv-org/invidious/issues/1898

[FireMasterK]

I have a fix, which is to be used in nginx, does that count?

[TheFrenchGhosty]

@FireMasterK Ideally invidious should support multiples domain names (or 1 domain name + 1 tor onion). A solution with nginx is "good" but far from ideal.

[FireMasterK]

proxy_cookie_domain invidious.kavin.rocks $host;

That's what I use. You can change invidious.kavin.rocks to your instance.

[github-actions[bot]]

This issue has been automatically marked as stale and will be closed in 30 days because it has not had recent activity and is much likely outdated. If you think this issue is still relevant and applicable, you just have to post a comment and it will be unmarked.

[GlowingUmbreon]

This could be resolved by using Request.hostname to get the domain of the instance instead of using CONFIG.domain. Is there any particular reason why CONFIG.domain exists instead of getting it based on the request domain?

[unixfox]

Is there any particular reason why CONFIG.domain exists instead of getting it based on the request domain?

I can't recall everything, but it's being used in many places. One of which is to be sure that the video player will use the correct domain for proxying the video stream from YouTube servers.

But to be 100% fair, it's a relic from the past. In my opinion, invidious should find the correct domain only from the header X-Forwarded-Host: <host> because this header is native in some reverse proxy. This way you can have a single invidious process for multiple domains.

As the host header is not always accurate, invidious may not receive the original domain in the "host" header, hence Request.hostname will not work in all cases.