Since freyr doesn't use custom-generated Apple Music tokens, and instead opts for the one embedded in the music.apple.com website, these tokens typically have a validity period of 3 months or under.
Making it so we have to update these tokens rather frequently, which is not ideal for persistence.
590 highlights a pattern for extracting the token from the website, and this patch automates that, merging it right into freyr's authentication logic.
Now, we no longer need a developerToken in conf.json as it would be fetched from the Apple Music website on the first-run.
And any subsequent token updates when expired will be updated with the same process.
Making sure, we never have any periods of unauthentication past this point.
Since freyr doesn't use custom-generated Apple Music tokens, and instead opts for the one embedded in the music.apple.com website, these tokens typically have a validity period of 3 months or under.
Making it so we have to update these tokens rather frequently, which is not ideal for persistence.
590 highlights a pattern for extracting the token from the website, and this patch automates that, merging it right into freyr's authentication logic.
Now, we no longer need a
developerTokeninconf.jsonas it would be fetched from the Apple Music website on the first-run.And any subsequent token updates when expired will be updated with the same process.
Making sure, we never have any periods of unauthentication past this point.