Channel URL isn't always parsed correctly

[sdomi]

Rehike version

0.8.1

Operating system

Alpine Linux (edge)

PHP version

8.2.17

What's going on?

The new user URLs with the at-sign are parsed incorrectly, which can throw you onto someone else's channel.

I don't have spoons to read through the codebase and fix the bug myself (sorry :c), but my hypothesis is as follows:

given URLs containing the @ (for instance, https://www.youtube.com/@Stryder7x), rehike strips the @ and loads the channel from the old /user/<name> or /<name> schema. In the example linked above, those URLs aren't equal; On main YT, /user/stryder7x leads to a different, empty channel compared to /@Stryder7x, while on rehike both of those URLs show the same thing.

In bashtube (my now-dead youtube frontend), the watch page linking back to the channel just used the channel id as extracted by yt-dlp (instead of trying to link to a pretty user url), so I never run into this problem, but that's not necessarily a fix.

also, great work on the project! i need to get involved with rehike some day :3

EDIT: ...it's even worse. on main youtube, if I go to https://www.youtube.com/watch?v=DPfMATdVN-w and click onto stryder's channel, it loads properly. Then, if I reload, it loads the incorrect channel. Looking at the network log, it seems that youtube only parses this correctly when navigated using the /youtubei/v1/browse endpoint, OR by directly referencing the correct channel ID (https://www.youtube.com/channel/UCYDnJiF0_RqSjkjvjRbG1tA). I suppose that linking to an ID instead of a pretty channel URL would be the only workaround for now.

[kawapure]

We are bound by the same limitation as YouTube themselves, and this is a long-lasting YouTube bug. The only way to access these channels correctly is by UCID.

For request URLs, we look through the entries in router.php for a match and open the corresponding controller. The default match attempts to lookup a channel UCID for making an InnerTube request, and we use YouTube's own navigation/resolve_url API for this, same as the official web frontend and mobile apps when accessing a URL.

EDIT: ...it's even worse. on main youtube, if I go to https://www.youtube.com/watch?v=DPfMATdVN-w and click onto stryder's channel, it loads properly. Then, if I reload, it loads the incorrect channel. Looking at the network log, it seems that youtube only parses this correctly when navigated using the /youtubei/v1/browse endpoint, OR by directly referencing the correct channel ID (https://www.youtube.com/channel/UCYDnJiF0_RqSjkjvjRbG1tA).

Yes, the official frontend takes the UCID from the request metadata for that link and uses it to make the request. It then puts the pretty URL with the history API.

I suppose that linking to an ID instead of a pretty channel URL would be the only workaround for now.

I will look into that. I think it would mostly just require a small little check at the top ParsingUtils::getUrl() to throw in the UCID for URLs starting with "/@". There are some exceptions, such as watch.

[kawapure]

Aforementioned patch applied here: a9d2144

[sdomi]

thx! <3