Allow age restricted songs to play by sending age check confirmation

[gechoto]

Before:

"playabilityStatus": {
    "status": "AGE_CHECK_REQUIRED",
    "reason": "This video may be inappropriate for some users.",
    [...]
},

After:

"playabilityStatus": {
    "status": "OK",
    "playableInEmbed": true
},

This implements what the desktop/web player does when you click the button to confirm your age.

I guess you still need to be logged in for this to work. I haven't tested without login but it works with my account.

Maybe fixes #1442

[gechoto]

This does not seem to work anymore since you switched to the IOS client:
dc6bfce

Now I have to find out how this is done on IOS but I don't have an IOS device for testing.
Can someone with an IOS device help out?

[gechoto]

Just saw that ViTune also added this contentCheckOk:

25huizengek1/ViTune@504b6f7

but in ViTune it is a String instead of a Boolean. I'm not sure why. I can't test if it makes a difference currently since this confirmation seems to have a cooldown (currently I can play age restricted songs without confirming).

[gechoto]

@25huizengek1 what is the reason you made this contentCheckOk field a string instead of a boolean?

[25huizengek1]

@gechoto I actually can't recall, it was a really rushed debugging session in order to fix streaming for ViTune. During testing it didn't seem to matter though.

[gechoto]

@25huizengek1 how did you find all the values needed for the IOS client? Do you have a real IOS device for testing?

@z-huang I currently can't get age restricted songs to work with the IOS client. Would it be okay as a quick fix to re-add the ANDROID_MUSIC client?
We could maybe do something like this:

• if user is logged in try with ANDROID_MUSIC client and use IOS only as fallback
• if user is logged out jump straight to the IOS client

[z-huang]

It's okay. You can add it in this PR.

[gitguardian]

⚠️ GitGuardian has uncovered 1 secret following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

Since your pull request originates from a forked repository, GitGuardian is not able to associate the secrets uncovered with secret incidents on your GitGuardian dashboard.
Skipping this check run and merging your pull request will create secret incidents on your GitGuardian dashboard.

🔎 Detected hardcoded secret in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
14305798	Triggered	Google API Key	93ac477	innertube/src/main/java/com/zionhuang/innertube/models/YouTubeClient.kt	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secret safely. Learn here the best practices.
3. Revoke and rotate this secret.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}

[gechoto]

@z-huang done. I suggest to squash the commits on merge.

[25huizengek1]

@gechoto Since I don't own any Apple devices, I just tried different combinations of versions (or user agents) I found in the community: for example yt-dlp, https://github.com/zerodytrash/YouTube-Internal-Clients, NewPipeExtractor, etc.

The rest of the values I got myself by just guessing from the traffic on desktop and Android.