The current message confusingly mentions bad 'username' when username is not involved.  The
new message is the same as that introduced for an incorrect current password on the self
delete profile form (FS#2751)

Added an explanation that what we do is like normal CBC but that we
additionally encrypt the IV which is actually suggested by the NIST for
non-random (but unique) IVs. In the decryption process it's not
necessary to decrypt the IV, this should save some time.

This replaces the deprecated and broken Blowfish implementation that has
previously been used and should provide a lot more security.

If you want better random initialization and more control over the
password strength install the passpolicy plugin.

This is needed to replace the password generator by a plugin
implementation. Related to PR #166 and FS#2147

No need for HMAC here because there's no length attack vector here. We
only care for the existance of the file and each reset request is
completely (random) independent from each other.

This adds $INPUT in all places where it was still missing and available.
$INPUT is now also used in places where using $_REQUEST/... was okay in
order to make the code consistent.

In the case of a failed authentication initialization, the
authentication setup was simply continued with an unset $auth object.
This restores the previous behavior (before merging #141) of simply
returning after unsetting $auth. Furthermore this re-introduces the
check if $auth is set before checking $auth and removes a useless
check if $auth is true (could never be false).

IE9 send different HTTP_ACCEPT_LANGUAGE header on ajax request. This causes different results from auth_browseruid. This patch removes the HTTP_ACCEPT_LANGUAGE from the browser id calculation.

It seems, some servers require a special Status: header for sending the
HTTP status code from PHP (F)CGI to the server. This patch introduces a
new function (adopted from CodeIgniter) for simplifying the status
handling.

The returned type is important in particular when we deal with xmlrpc. Indeed,
this value is directly returned to the client eg when the wiki.getAllPages method
is queried.

Currently the 'perms' attribute may be either an int or a string, and its up to
the xmlrpc client to resolve it (although Dokuwiki's documentation only tells it
can be an int).

This patch makes sure we'll always return perms as int.

merged the wrong change here

ACL checking of DokuWiki is currently always case-sensitive
regardless of auth backend setting ($auth->isCaseSensitive).
This commit enables case-insensitive match in the same way
of auth_isMember().

Internet Explorer 8 (and maybe others) seem to use different
capitalization in the ACCEPT_CHARSET header between "normal" requests
and AJAX requests. This causes a browser UID mismatch and thus an
unecessary reauthentication.

We need to decide how to handle the renaming of the auth classes. Should
this be done automatically somehow? Or is an admin expected to fix this
manually when updating?

This is untested and probably broken currently

passwords now need to be reset within 3 days of requesting the password
change mail