Change Details

Things that are trickier than necessary to handle at the moment without these codes: - Differentiating between certain "UI" responses. For example - distinguishing between a clientlogin UI response indicating a temporary password needs to be changed vs a clientlogin UI response indicating the user should update their pwd of fewer than 8 characters when logging in for the first time after being granted admin rights. Presently the only differentiator in the response is the error message itself, which is problematic for apps because these messages sometimes refer to UI elements which may or may not be present in app interfaces ("Skip" buttons etc - sometimes for size constraint and localization reasons icon are used instead). - Differentiating between certain "FAIL" responses. For example - distinguishing when a login has failed because the user's repeated failed login attempts have triggered a captcha requirement. Less state would have to be managed if you could just check the clientlogin UI response for a "NeedsCaptcha" code and only *then* make a secondary "authmanagerinfo amirequestsfor login" query to fetch captchaID/URL.

Things which are trickier than necessary to handle at the moment without these codes: - Differentiating between certain "UI" responses. For example - distinguishing between a clientlogin UI response indicating a temporary password needs to be changed vs a clientlogin UI response indicating the user should update their pwd of fewer than 8 characters when logging in for the first time after being granted admin rights. Presently the only differentiator in the response is the error message itself, which is problematic for apps because these messages sometimes refer to UI elements which may or may not be present in app interfaces ("Skip" buttons etc - sometimes for size constraint and localization reasons icon are used instead). - Differentiating between certain "FAIL" responses. For example - distinguishing when a login has failed because the user's repeated failed login attempts have triggered a captcha requirement. Less state would have to be managed if you could just check the clientlogin UI response for a "NeedsCaptcha" code and only *then* make a secondary "authmanagerinfo amirequestsfor login" query to fetch captchaID/URL.

Things thatwhich are trickier than necessary to handle at the moment without these codes: - Differentiating between certain "UI" responses. For example - distinguishing between a clientlogin UI response indicating a temporary password needs to be changed vs a clientlogin UI response indicating the user should update their pwd of fewer than 8 characters when logging in for the first time after being granted admin rights. Presently the only differentiator in the response is the error message itself, which is problematic for apps because these messages sometimes refer to UI elements which may or may not be present in app interfaces ("Skip" buttons etc - sometimes for size constraint and localization reasons icon are used instead). - Differentiating between certain "FAIL" responses. For example - distinguishing when a login has failed because the user's repeated failed login attempts have triggered a captcha requirement. Less state would have to be managed if you could just check the clientlogin UI response for a "NeedsCaptcha" code and only *then* make a secondary "authmanagerinfo amirequestsfor login" query to fetch captchaID/URL.