by the following rules:
1) An initial dialog or panel load can take either HTML or JSON, but
the mime type must accurately reflect its payload.
2) dialog form submits can handle a pure HTML response, but the mime
type must also be correct. This properly resolves the problem
where the reauth code gets a JSON response first from the reauth
code, and then an HTML response when you reauth and continue on to
a given form -- try it out with Admin > Settings > Advanced.
3) All JSON replies must set the mime type correctly. The json::reply
convenience function does this for us.
4) By default, any HTML content sent back in the JSON response should be
in the "html" field, no longer the "form" field.
The combination of these allows us to stop doing boilerplate code like
this in our controllers:
// Print our view, JSON encoded
json::reply(array("form" => (string) $view));
instead, controllers can just return HTML, eg:
// Print our view
print $view;
That's much more intuitive for developers.
Also renaming auth::validate_too_many_failed_password_changes to validate_too_many_failed_auth_attempts since it's used in this generalized way in 3 places now.
separate from a successful or failed login.
1) Rename user_login_failed event to user_authenticate_failed
2) Rename failed_logins table to failed_auth (bump Gallery module to
v27 to rename the table)
3) auth::too_many_failed_logins -> auth::too_many_failures
4) auth::record_failed_auth_attempts -> auth::record_failed_attempts
auth::clear_failed_auth_attempts -> auth::clear_failed_attempts
Fixes ticket #585.
Separate out the password change form from the regular edit user form.
Require the old password to enter a new one. While I'm at it, roll
the password strength javascript into a Form_Script element so that we
can get rid of the old view (which incidentally fixes a bug where the
password strength meter would go away on form errors).
user_add_form_admin admin adding a user
user_edit_form_admin admin editing a user
user_add_form_admin_completed successfully added a user (admin)
user_edit_form user editing their own settings
user_edit_form_completed successfully edited a user (admin and user editing own settings)
1) Allow admins to edit the admin bit of other admins
2) Don't allow admins to delete themselves (partial fix for ticket #213)
3) Inline user::update(). Don't do form processing in helper methods!
4) Inline user::_get_edit_form() so that we can treat edit forms differently.
Trying to hard to make common functions makes for weird edge cases.
1) create common update function so processing consistent between the
user edit and admin edit.
2) created common private helper function to build the user edit form
the same way.
So a user can now change their user name if the new one doesn't exist.
