YunoHost-Apps / peertube_ynh

Federated (ActivityPub) video streaming platform using P2P for YunoHost
https://joinpeertube.org/fr/
GNU Affero General Public License v3.0
87 stars 27 forks source link

Setting to "private" prevents federation from working properly #341

Closed matlag closed 1 year ago

matlag commented 1 year ago

Describe the bug

If the application is set to "private", input request from other instances gets redirected to the Yunohost's login page, and so peertube does not receive messages from other instances.

Context

Steps to reproduce

I lost track of when this started. But initially, it was subscribed channels not updating. I tried many things to get them to work (unsubscribe/resubscribe, search updated videos, etc.). Eventually, I attempted to delete instances I was following and try to follow them again. That's when I figured that they all ended as pending, no follow request was accepted. I checked DNS requests, and "something" was being sent out (I didn't get to the details of the content, but I assume that was ok).

So since I have a second instance, I attempted to follow my second instance, configured on auto-accept. Instance1 showed it as pending. I checked the log on Instance2, and that's where I found the issue (servers names replaced by instance1.tld as the one with the issue, attempting to follow instance2.tld, the logs are from instance2):

Sep 12 00:33:52 instance2.tld peertube[2769]: [peertube.instance2.tld:443] 2022-09-12 00:33:52.422 warn: Error in ActivityPub signature checker. {
Sep 12 00:33:52 instance2.tld peertube[2769]:   "err": {
Sep 12 00:33:52 instance2.tld peertube[2769]:     "stack": "RequestError: Unexpected token < in JSON at position 0 in \"https://instance1.tld/yunohost/sso/?r=aHR0cHM6Ly9wZWVydHViZS5jaHR>
Sep 12 00:33:52 instance2.tld peertube[2769]:     "message": "Unexpected token < in JSON at position 0 in \"https://instance1.tld/yunohost/sso/?r=aHR0cHM6Ly9wZWVydHViZS5jaHRpc3VyZWwubmV>
Sep 12 00:33:52 instance2.tld peertube[2769]:     "name": "ParseError",
Sep 12 00:33:52 instance2.tld peertube[2769]:     "responseBody": "<!DOCTYPE html>\n<html>\n<head>\n  <meta charset=\"utf-8\">\n  <title>YunoHost Portal</title>\n\n  <!-- Responsive -->>
Sep 12 00:33:52 instance2.tld peertube[2769]:     "responseHeaders": {
Sep 12 00:33:52 instance2.tld peertube[2769]:       "server": "nginx",
Sep 12 00:33:52 instance2.tld peertube[2769]:       "date": "Mon, 12 Sep 2022 00:33:49 GMT",
Sep 12 00:33:52 instance2.tld peertube[2769]:       "content-type": "text/html",
Sep 12 00:33:52 instance2.tld peertube[2769]:       "transfer-encoding": "chunked",
Sep 12 00:33:52 instance2.tld peertube[2769]:       "connection": "close",
Sep 12 00:33:52 instance2.tld peertube[2769]:       "x-sso-wat": "You've just been SSOed",
Sep 12 00:33:52 instance2.tld peertube[2769]:       "cache-control": "no-cache",
Sep 12 00:33:52 instance2.tld peertube[2769]:       "content-security-policy": "upgrade-insecure-requests",
Sep 12 00:33:52 instance2.tld peertube[2769]:       "x-content-type-options": "nosniff",
Sep 12 00:33:52 instance2.tld peertube[2769]:       "x-xss-protection": "1; mode=block",
Sep 12 00:33:52 instance2.tld peertube[2769]:       "x-download-options": "noopen",
Sep 12 00:33:52 instance2.tld peertube[2769]:       "x-permitted-cross-domain-policies": "none",
Sep 12 00:33:52 instance2.tld peertube[2769]:       "x-frame-options": "SAMEORIGIN",
Sep 12 00:33:52 instance2.tld peertube[2769]:       "permissions-policy": "interest-cohort=()",
Sep 12 00:33:52 instance2.tld peertube[2769]:       "strict-transport-security": "max-age=63072000; includeSubDomains; preload"
Sep 12 00:33:52 instance2.tld peertube[2769]:     },
Sep 12 00:33:52 instance2.tld peertube[2769]:     "statusCode": 200
Sep 12 00:33:52 instance2.tld peertube[2769]:   }
Sep 12 00:33:52 instance2.tld peertube[2769]: }

I converted the app to "public" using the following

export app="peertube"
ynh_permission_update --permission="main" --add="visitors"

as found in the install script.

Then I deleted the instances I was attempting to follow (on Instance1, of course), and re-added them, and most request got instantly approved according to auto-accept policies of the remote instances.

Expected behavior

I don't have a good answer here. Now that we're here, I'm wondering how my setup has been working until now...

I would say ideally, "private" should prevent access to the main page but not redirect server to server communication, if that's possible.

Logs

See above. There was no error message at any time on Instance1 (because it wouldn't get any answer, I guess...)

yalh76 commented 1 year ago

Expected behavior

I don't have a good answer here. Now that we're here, I'm wondering how my setup has been working until now...

I would say ideally, "private" should prevent access to the main page but not redirect server to server communication, if that's possible.

For now, private instance is made to not federarate at all with other instances... What would be the goal to have an instance able to federate with other instances but where no one can go on it to see available videos ?

matlag commented 1 year ago

I'm probably a particular case because as of today, I use Peertube only as a "consumer" of content, not a producer. So I don't see any benefit in letting people connect to my instance. But there is no real drawback either. I see it more like an additional "entrance" in my system: the more login pages, the more security risk (I'm not saying this is a legitimate concern, I'm not qualified to answer that). So, I have no strong feeling about how it's made.

I identify this as a bug because it used to work and then it didn't with the same settings. Again, I don't think it's wrong to have it this way (private=non federated) but if there was a warning about the change, I missed it, and I may not be the only one to miss it. I don't know how to "fix" this. Maybe this thread itself is sufficient documentation.

yalh76 commented 1 year ago

As far as I see the code of peertube_ynh, it's like that (private=non federated) since the beginning