Remove uploadableTextures from fullProfile #212
Conversation
As far as I'm aware, authlib-injector does not use this anywhere. I'd like if it were removed because in ReIndev, a popular b1.7.3 mod, it attempts to base64 decode every "value" field in `properties`. Under Mojang authentication server it succeeds, but with drasl it will try to Base64-decode something like "skin,cape" and fail.
Here you can see what I'm referring to. |
|
I think it's not the best API design on authlib-injector's part to modify the existing endpoints but not sure what we can do. PR ReIndev? |
Reindev is proprietary, can't
Yeah, me neither. In cases where it breaks stuff though, I think that it should just be done away with, and I would prefer conformity to mojang's responses. I think that ideally drasl's responses should even 1:1 mirror the spacing that mojang's auth server serves with the json on particular routes, but that'd add way too much complexity.
AFAIK HMCL is the only launcher for authlib-injector which uses its protocols. I really doubt there are all that many drasl users who want to use HMCL. Maybe you could add a config option |
|
If you approve of it, I can get to work on a PR for opt-in/opt-out (whatever you think is better I don't mind) disabling of authlib-injector-specific route logic which is known to break things (currently just this) |
Or better yet, itd be cleaner to have the option able to disable the authlib-injector "yggdrasil server" protocol support globally, which as of now would only break support for HMCL |
|
Actually, I should probably just handle this in Loki. That'd be simpler. |
2 participants
As far as I'm aware, authlib-injector does not use this anywhere. I'd like if it were removed because in ReIndev, a popular b1.7.3 mod, it attempts to base64 decode every "value" field in
properties. Under Mojang authentication server it succeeds, but with drasl it will try to Base64-decode something like "skin,cape" and fail.