quarry
quarry copied to clipboard
barneygale
Microsoft Auth
Add Microsoft Auth from email and pass. It use not fully legal way to login but work without any user interaction
Does this code meet the relevant standards/EULA specifications for Microsoft?
Interesting. I think it would be better if logging in via user code was also supported in the library. Because as far as I know, this code doesn't work on accounts with 2FA.
In case you don't know what is that, here is the explanation:
- The system sends a request to Mircosoft.
- Microsoft returns the user code to the system.
- The system tells the user, "To sign in, use a web browser to open the page XXXX and enter the code YYYYYY to authenticate."
- The user opens the page XXXX and enters the code YYYY.
- The page asks the user to log in.
- The user login to the Microsoft account.
- The page verifies the input then accepts the request.
- The system receives the live token and continues.
XXXX is usally https://login.live.com/oauth20_remoteconnect.srf btw.
Here is an implemenation on Javascript: https://github.com/PrismarineJS/prismarine-auth/blob/master/src/TokenManagers/LiveTokenManager.js
Here is the protocol diagram: https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-device-code
Hello, is it a better choice to convert all functions from camelCase to snek_case?
Hello, is it a better choice to convert all functions from camelCase to snek_case?
Not in the same PR please. Only make 1 relevant change per PR.
Aside from that: The code styling of the project is a legacy choice. I'll only merge such a change if it doesn't cause major breakage.
Hello, is it a better choice to convert all functions from camelCase to snek_case?
Not in the same PR please. Only make 1 relevant change per PR.
Aside from that: The code styling of the project is a legacy choice. I'll only merge such a change if it doesn't cause major breakage.
Why create a new PR to convert these new functions to snek_case?
Why create a new PR to convert these new functions to snek_case?
Oh you're right, I thought you meant some existing functions got changes, I didn't read the PR all the way through.
@andriycraft changing line 76 (0bb2682) from http to https seems to break getXBLToken() to anyone who has tested this lmk if you share a similar or different experience.
Hey guys while I support being able to login, legally it seams wont work, as using the token in such a way and obtaining it this way is not allowed by the tos, you have to create your own azure account and setup a app on there, instructions from a bigger project linked below, but It seams this is not a legal way to login. :( sorry. This probably means it cannot be merged anymore and will cause issues if done so in the future, also using this on your account is at your own risk.
Multi-mc build Multi-mc custom build
I am currently working on a way to do this with OAuth2. Would that be merged?
The only supported way is with OAuth2, the same way the official launcher and third-party launchers authenticate. (Opening a browser, entering a code, signing in, and allowing).
@EnderC00kiez Though I am not a maintainer of this project I suspect it would be merged.
EDIT: I would also recommend supporting refreshing the token so users don't have to re-authenticate more than once, though storage of the token I'm not sure on, maybe allow the user to store it themselves, but also provide a basic text storage option built-in?
Okay. I don't know how handling the actual Azure token will work, as it's supposed to be confidential. I can try to work out a way to store secrets, because I don't want unsuspecting projects leaking private tokens. Edit: I have the actual authentication working, I just have to implement it into Quarry and allow saving the token
It dont matter if you share azure token, just look at open source projects (minus multi-mc).