Personalized Endpoints

[wont-stream]

I saw in the docs you have not yet added those yet
"
Adding personalized routes

Currently node-musickit-api doesn't support personalized routes (api.music.apple.com/v1/me)

It is going to require quite some work to support those routes, but I am certain I could pull it off
"

and was wondering if you have an ETA? I haven't found any other packages that support this yet and I'm relying one something for my API.

Thanks

[Exerra]

Yeah, sorry, I no longer have a paid Apple developer account so I cannot continue development on this myself. There are hacky workarounds with using the Apple Musickit JS lib to grab the user token and then using it in my package, but as I said, that is hacky and might not work.

This thread might have more info about it FoxxMD/multi-scrobbler#9

[Exerra]

As I mentioned before the biggest issue is the retrieval of a user token. Currently the only officially supported method is by using MusicKit on the Web, which is a client library imported on the webpage using a <script> tag.

I will have to figure out the best implementation. My gut says that I would have to implement route handlers for Elysia, Express and other backend frameworks, but I will try to figure out what is the most framework-agnostic, etc, way of implementing that.

Reading list for me later:

• https://dev.to/jurooravec/reverse-engineering-apple-s-musickitjs-to-create-apple-music-strategy-for-passportjs-12h

[Exerra]

Reading the article by Juro Oravec and subsequent cursory exploration makes me wonder if a quick implementation could be achieved just by using cookies.

For example, each authenticated Apple Music Web request includes an Authorization and Media-User-Token (MUT) header. The Authorization header is the developer token that the library already generates, while MUT is the user token for personalised routes.

Ideally Apple doesn't check whether the MUT belongs to the developer token, however I doubt that. I will have to test that, but if they do check that I could potentially modify the constructor of the main class to accept either a key or a token nabbed from the Apple Music Web client, and then for personalised routes the user could provide their own MUT rather than mounting a route handler, doing oauth, etc. That would also allow for more flexibility.

Alternatively, (and this would be the lazy way), I could remove private from the token variable, and since the constructor only saves the key to an internal variable the user could just modify it themselves.

I was meaning to remove private from those variables anyway to allow the user to use the internals of the package instead of only the getters, so the lazy version would be possible anyway. Still, I would like to modify constructor behaviour to make direct assignment of the developer token a "officially supported" feature.

[Exerra]

Obvious issue with the token nabbing approach is the lack of certainty of the expiry date of the AM token. For example, the developer token I just pulled from the AM web client is valid only for 35 days since issuing, with only 29 being left as of copying. That is a far cry from the 180d when using your own key. I have no idea of the MUT expiry, but with your own key it is 180d. Potentially the user could just force a login and get a new 180d key (if it even is 180d on the web client)

I could introduce new functions to check the expiry dates, etc, maybe even create event listeners so users can set up notifications in advance, but even then that just seems like a massive hassle. Especially in environments like multi-scrobbler, where the user would aim to only configure the token once or only revalidate once a half year.

That is, if the developer token is being matched to the MUT...

[Exerra]

It doesn't match the developer token to the MUT :)

A quick implementation is possible, but I still would like to support both token nabbing and oauth.