[YTDLPWrapper] Enable using netrc file

[mp107]

Hi,
This change enables using netrc file in YTDLPWrapper plugin to allow yt-dlp to use authentication data stored in the netrc file.

The netrc file is a structured text file that - in principle - stores the credentials used during logging in to remote machines.
https://www.gnu.org/software/inetutils/manual/html_node/The-_002enetrc-file.html

The yt-dlp can use the netrc file to store credentials data (logins, passwords) for websites that need logging in to make access its contents (videos, live transmissions, etc.).
Link to yt-dlp's documentation describing using the netrc file: https://github.com/yt-dlp/yt-dlp#authentication-with-netrc

For some reason enabling just the "--netrc" flag (in code - by inserting "usenetrc": True does not seem to work so I used a workaround with using "cat" on a file stored in the default location - user's home directory.

If the netrc file does not exist, a warning is displayed, but the link generation process is not interrupted so the change should be transparent for users that have not created the file.

I leave it open to consider using a different file location or adding the option to customize this option for example in the user interface, from the system settings.

Nevertheless in my opinion it should be possible to use netrc file (or - possibly other way) to store credential data for yt-dlp used as a base mechanism of stream URL extraction in YTDLPWrapper plugin.

Best regards,
mp107

[jbleyel]

I have 3 2 important questions.

Why using netrc_cmd option and not usenetrc?

How about streams with user and password, are they still working?

How about different credentials for the same extractor?

[jbleyel]

For some reason enabling just the "--netrc" flag (in code - by inserting "usenetrc": True does not seem to work so I used a workaround with using "cat" on a file stored in the default location - user's home directory.

https://github.com/yt-dlp/yt-dlp/blob/b6951271ac014761c9c317b9cecd5e8e139cfa7c/yt_dlp/extractor/common.py#L1319-L1323

Running cat via shell command is a very bad idea.

[mp107]

Running cat via shell command is a very bad idea.

I agree. I used the "cat method" just as a workaround with hope that more suitable solution will be found later.

https://github.com/yt-dlp/yt-dlp/blob/b6951271ac014761c9c317b9cecd5e8e139cfa7c/yt_dlp/extractor/common.py#L1319-L1323

Thank you for bringing that piece of yt-dlp's code to my attention. Indeed, after further investigation I verified that the line mentioned below properly loads the netrc file from the specified location without using "cat workaround".

ydl = YoutubeDL({"format": "b", "no_color": True, "usenetrc": True, "netrc_location": "~/.netrc"})

How about streams with user and password, are they still working?

So - if I understood the question's context properly - you suggest that it was already possible to use in the YTDLPWrapper in a service that needed credentials (without a change in the code from that pull request). I had no success to make it work without the code change from this pull request but if there exists any solution I would like to ask you to describe it. If it is already possible most likely it would make that pull request unnecessary.

But in general yes - streams requiring credentials (user and password) are working now with the credentials stored in the netrc file.

How about different credentials for the same extractor?

I would need to know the answer to the previous question to address this question. I am currently unaware of any way of passing credentials to the YTDLPWrapper except the solution I suggested in that pull request.

But as far as I know a netrc file allows to store a single pair of credentials (login and password) per extractor.

[jbleyel]

Hi @mp107 , how should we continue here?
Do you have tested A and B?

A: ydl = YoutubeDL({"format": "b", "no_color": True, "usenetrc": True, "netrc_location": "~/.netrc"})
B : ydl = YoutubeDL({"format": "b", "no_color": True, "usenetrc": True})

I personally prefer B.

[mp107]

I've just tested it on a current OpenATV's develop build and option "B" works properly. Thank you for your work on investigating the issue.