New authentication process

[chemelli74]

Currently one of the biggest issue is the local authentication towards the device.
We have a non linear approach to login to cloud and retrieve the needed data (token,keys,subtype).

My idea is to clean this up in a linear approach thus making easier to fix the wrong steps.

Rework current logic in new functions:

• async_get_default_keys(): get the default hardcoded keys

• async_login_preset_account(): login to cloud using hardcoded account credentials.

• async_login_username(): login to cloud using specified user credentials.

• async_get_cloud_keys(): get method 1 and method 2 keys from cloud login

• async_get_cloud_subtype(): get device subtype from cloud login

• async_device_authentication(): use token/keys to check if they work for local authentication to the device.

With those the authentication process could be something like:

• async_get_default_keys()
• async_device_authentication()
• if ok -> done (store the info in configuration entry for future debug).
• If KO -> async_login_preset_account()
• If KO -> async_login_username()
• If ok -> async_get_cloud_keys()
• async_device_authentication()
• If KO -> abort

[rokam]

I do agree

[rokam]

@chemelli74 I did a PR because I think async_get_default_keys should be a static method

[wuwentao]

@chemelli74 @rokam
sorry, and I'm really not found this topic, just found this discussion now, first of all, I can agree with lib func split , This has a huge impact, and the logic is reversed, my comments as below:

1. please don't use perset account as the first option: It will obviously cause this perset account to have a large number of usage requests with most of the devices, which is very likely to cause this account to be directly blocked or other security risks, such as speed limit, request limit, or other potential high-frequency usage risks, and from a large number of different IPs or devices. I strongly oppose this solution, and the default action should be user MUST log in with his account to perform these operations, and only enable this perset account as a backup solution. in addition, all of us don't have this account email permission and recovery info, someone may login and reset passwd, it's really not a safe or first priority solution for all the user and us. we should consider the impact for this account and future account usage issue

2. not always use perset MSmart cloud as first option, as it only support MSmart Cloud, there is still MideaAirCloud for Midea Air/NetHome Plus/Ariston Clima exist, user know which cloud they are using, if it can works, why we always use perset cloud as first option? so the user login input should always be the first solution and not using perset account and preset cloud as first solution, you are doing a reverse precess with current normal process

3. async_get_cloud_subtype should not exist, still using get_device_info or you can rename to a new name after async func, as in current solution, it only need subtype and some sn8 info, we still need to parse all device response from cloud and save all the device info for future usage, so please don't limit it only to subtype or sn8, it's a lib func, so it should get all the device info from cloud and just return the result, integration or API user can select which one is need or whether to use it.

[rokam]

@wuwentao atm we are just segregating method responsibilities, the order of operation is part of the integration. To wrap it up, those points are relevant on the integration side. The lib will provide the way to do it.

[wuwentao]

yes, the process is control in integration side, but @chemelli74 may start rework with config_flow, I'm not sure, so just want to share these important info to prevent addition effect.