Trusted Domains: Allow trusting a domain regardless of HTTP basic auth credentials

[Tremolo4]

TL;DR: If you want to trust URIs with credentials in them, you have to add the full thing to the trusted domains: user:pass@example.com. This PR makes it so you can just add example.com, even when using credentials.

Long version
I have the following use-case: I have a webserver that serves videos, but they are protected with HTTP basic authentication. It is possible to embed the credentials in a URL like so:

https://username:password@example.com/video.mkv

This URL works, for example, in mpv. I can add this URL in the syncplay playlist and it works fine. But I get the untrusted domain warning and have to click the playlist entry manually. If I add example.com to the "trusted domains" in the Advanced menu, I still get the warning. Only if I add username:password@example.com to the trusted domains, the warning disappears.

This workaround is not very good because the credentials are saved on disk in the syncplay settings and also the trusted domain entry has to be adjusted if the credentials change.

Therefore, I've rewritten the trusted domain checking code to ignore the credentials. I use urllib.parse to make it quite simple and safe.

I have taken care to match the old behavior exactly, except: If someone already uses the workaround above, i.e. already has a domain with basic auth credentials in the trusted domains list, it will no longer match anything. If this exception is undesired, I can easily make it so that trusted domains with embedded credentials are also still matched.

Note that trusted domains can not only be domains, they can also have a path attached, e.g. example.com/videos. For these cases, there is another -- IMO unimportant -- difference: The old code only trusts URLs if a trusted domain is a prefix plus a slash. For example:
Trusted domain example.com/videos allows example.com/videos/wat.mkv but not example.com/videoswat.mkv.
Trusted domain example.com/videos/ allows example.com/videos//wat.mkv but not example.com/videos/wat.mkv.
My new code does not add the extra slash -- each of the two trusted domains above match both given example URLs. I prefer this compared to the old behavior, but I can change it if desired.

[Et0h]

I've not tested it yet, but this looks like a great improvement to me. Thanks for your contribution.

[Tremolo4]

Thanks!

I just noticed that there is an "add [domain] as trusted" option when right clicking a domain in the playlist. I made it so that the credentials are also stripped there.

[Et0h]

Great, thanks for your work on this!

[name-snrl]

@Tremolo4 hello, I think this commit broke wildcard matching mechanism. can you fix that? or do I need to create a new issue?

[Tremolo4]

When you say wildcard-matching, do you mean using a *? Just try removing the *. I think it always does a prefix match.

[name-snrl]

Just try removing the *

Unfortunately, this did not solve the problem. I tried trusteddomains = ['youtube.com', 'youtu.be', 'eu.ngrok.io'] and trusteddomains = ['youtube.com', 'youtu.be', '.eu.ngrok.io'], still doesn't work(

ERROR: Could not automatically load [example] because it is not on a trusted domain. You can switch to the URL manually by double clicking it in the playlist, and add trusted domains via File->Advanced->Set Trusted Domains. If you right click on a URL then you can add its domain as a trusted domain via the context menu.

[Tremolo4]

I see. I thought you were using the * in the path component (after /), not subdomains. I'll see what I can do.