 | Leafish Development | 261 Members |
| Where cool things get made | 16 Servers |
| Leafish Development | 261 Members |
| Where cool things get made | 16 Servers |
| Sender | Message | Time |
|---|---|---|
| 26 Feb 2023 | ||
 skillman623 | Line 122 in protocol/login.rs is where the flow starts by defining the pub enum AccountType::Microsoft. It's then called on 299 of screen/launcher.rs This sets the account type to be Microsoft. On 367 of screen/launcher.rs , it prepares the other variables needed to login. aname (line 367) will be the account name (under 'account_name_txt') apw (line 368) will be the account password. you don't have to pay attention to 369 nor 370. 367 is where the auth taken is defined (auth::AUTH_CLIENT_TOKEN) // you will have to bind the auth token from the auth scheme linked above in the auth file. For line 380, this uses try_login from crate::screen You will want to have it try the refresh token (if it exisits) and if it fails then request a new auth token (using the client_token as the auth token variable). Line 390 seems to always overwrite the username and password in the config. It's strongly advised to never store the client password (that's why there's a refresh token, to reauth instead). This should probably have a todo to hide a save password under an advancced options dropdown while explaining to the user that this is dangerous and explaining why. This covers the leafish side of things (and stevenarella should you want to patch that as their auth scheme is very similar as this is a fork of that). | 20:55:42 |
| skillman623 | Hotdog | 20:55:48 |
| skillman623 | * TODO: Info on auth flow //this needs to be documented once implimented Line 122 in protocol/login.rs is where the flow starts by defining the pub enum AccountType::Microsoft. It's then called on 299 of screen/launcher.rs This sets the account type to be Microsoft. On 367 of screen/launcher.rs , it prepares the other variables needed to login. aname (line 367) will be the account name (under 'account_name_txt') apw (line 368) will be the account password. you don't have to pay attention to 369 nor 370. 367 is where the auth taken is defined (auth::AUTH_CLIENT_TOKEN) // you will have to bind the auth token from the auth scheme linked above in the auth file. For line 380, this uses try_login from crate::screen You will want to have it try the refresh token (if it exisits) and if it fails then request a new auth token (using the client_token as the auth token variable). Line 390 seems to always overwrite the username and password in the config. It's strongly advised to never store the client password (that's why there's a refresh token, to reauth instead). This should probably have a todo to hide a save password under an advancced options dropdown while explaining to the user that this is dangerous and explaining why. This covers the leafish side of things (and stevenarella should you want to patch that as their auth scheme is very similar as this is a fork of that). | 20:56:44 |
| skillman623 | Oh, well that's odd. Each account has its own background. IMO in the future if we implement a spinning background how stevenarella does, this should cache a user's /home in their last server they played on or, should it not exist, their spawnpoint. (run a check and if the server announces essentials it should cache a few chunks when a user next uses /home ). | 21:02:19 |
| skillman623 | * Oh, well that's odd. Each account has its own background. This is defined in Launcher::background selection (6) in screen::launcher.rs IMO in the future if we implement a spinning background how stevenarella does, this should cache a user's /home in their last server they played on or, should it not exist, their spawnpoint. (run a check and if the server announces essentials it should cache a few chunks when a user next uses /home ). | 21:03:50 |
 javaimpact | pollster rules lol | 21:06:52 |
 Hotdog | pollster? | 21:07:18 |
| javaimpact | oof, no idea but i dont think so | 21:07:26 |
| javaimpact | https://crates.io/crates/pollster | 21:07:42 |
| Hotdog | that looks incredibly and also like it should be in the standard library | 21:07:59 |
| Hotdog | * that looks incredible and also like it should be in the standard library | 21:08:17 |
| Hotdog | Where is Leafish account data stored on the filesystem? I donked something up | 21:10:08 |
| Hotdog | found it | 21:13:00 |
| Hotdog | Okay, I think I have a working login | 21:13:47 |
| Hotdog | Two more function to go, gonna have dinner now | 21:13:58 |
| Hotdog | skillman, where did you get stuck with setting up Azure? | 21:30:16 |
| javaimpact | really great work, thank you for this! | 21:32:10 |
| Hotdog | can i have some insight on what exactly verification_tokens requires? I'm assuming [0] is the username and [1] is the authentication key for a given account | 21:37:39 |
| skillman623 | Getting it to auth. | 21:45:15 |
| Hotdog | What do you have right now? | 21:48:11 |
| javaimpact | i can take a look at this tmrw i'll have to sleep now | 21:58:58 |
| Hotdog | Alright | 22:05:29 |
| Hotdog | I'm pretty stumped on how refresh should work. I'll ask you about it tomorrow | 22:05:43 |
| skillman623 | I gtg for the night. It'll be ~ 16 hours before I can respond, then I'll take another look. | 22:12:20 |
| Hotdog | Oke, night y'all | 22:13:14 |
| skillman623 | Password -> server server gives an auth token. Auth token is then used instead of password and is sent to the azure (and then microsoft thorough it). Then it goes into either xbox live auth flow or not depending if its on windows. From there the refresh token (or whatever the xbox live equivalent is) is sent instead of the auth token along with the password. | 22:16:05 |
| Hotdog | Right | 22:22:47 |
| Hotdog | Christ, Microsoft is exhausting | 22:22:54 |
| Hotdog | I like how Cuberite doesn't notice how I'm destroying stone incredibly quickly with my bare fists | 22:27:08 |
| skillman623 | I'd open an issue for it. That means they don't have checks for it. | 22:52:47 |