Tgr added a comment.
I have no idea about the permission error, maybe you are using `assert` even though the login is unsuccessful? The captcha workflow unfortunately requires login to fail first. It works like this: - you get a login form with no captcha - you send a username and password - the server determines that you need to pass a captcha challenge because you don't have an email address (in which case we'd use an email challenge which is more meaningful security-wise) - since captchas are weak security measures (unlike email verification, passing a capctha doesn't in any way prove you own the account, it's just there to make automated password guessing harder), the server cannot at this point reveal whether the password was correct, so it fails the login - you get a login form with a captcha (because your login session was flagged as needing a captcha) - you send a username, password and captcha - you are logged in You can implement this in a client by checking authmanagerinfo after a failed login, but it's awkward. The point I was trying to make elsewhere is that the clientlogin API is meant for clients which render a login form, and clients using it are expected to be able to render fairly arbitrary forms and follow fairly arbitrary workflows. It does not have any stability guarantee like "the API will respond with a specific set of AuthenticationRequest subclasses" or "login will happen via a specific, predictable sequence of steps". The client is expected to display any response to the user (including AuthenticationRequest subtypes it wasn't aware of until now) relying only on the information documented in `AuthenticationRequest::getFieldInfo()`, including error messages and such. This isn't clear from the API docs which are cursory at best - frankly it's not a very useful API and we didn't expect much use of it, it was mostly created so that MediaWiki itself can render login forms dynamically on the client side (but then T362706: Permit displaying the login / signup page in a popup or iframe <https://phabricator.wikimedia.org/T362706> turned out to be a more feasible approach). I think OAuth would be far superior for basically any use case, including interactive login (in which case you can use a non-owner-only, non-confidential consumer and open the authorization URL in a popup with `display=popup` in the URL, which, uh, is probably not documented outside of MediaWiki release notes :( ). TASK DETAIL https://phabricator.wikimedia.org/T396927 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/
_______________________________________________ pywikibot-bugs mailing list -- [email protected] To unsubscribe send an email to [email protected]
