It seems now that you were correct, in that the landing page only provides anonymous credentials when you have the cookie from Īlso, the previous method going via /xhr/json/auth.php seems to be broken at the moment and is returning 500 errors for anonymous login attempts. More research and I'm still confused about this feature. In terms of actually using this, a quick example that I've tested is: I've noticed that there's a sessionType key in the settings which is set to anonymous, which could help, as could checking if the credentials are null before skipping the second authentication POST step in the anonymous login.
So, although the current code works, ideally it could be refactored to utilise the existing anonymous credentials from the landing page request and save one RTT and not perform the POST in that case. This occurs on any landing page, not only those redirected from. What you have noticed however, is that now, new requests to provide an anonymous session credentials anyway rather than null credentials.
This method stopped working a while ago, but now testing it again it seems like it is working again with the latest changes. The anonymous login was reverse engineered from the official client source code which sets the login type to anonymous when making the POST. Previously, any request to returned null credentials until the client authenticates with a HTTP POST to /xhr/json/auth.php, which then sets the session up with credentials that can then be used to open a WebSocket connection.
This is actually what the Spotify#anonymousLogin() method is supposed to do, however it seems that Spotify have changed the way that we can access it so some of the code should really be updated.
0 kommentar(er)
