[CHD-3198] [Code Cleanup] Fixed the simulator for Ticket and Message VA events.
6.1.4 checkpoint
Merged 6.1.4 into 6.2
[Code Cleanup] PHP strict mode fixes
* [Devblocks/Platform] Added DevblocksPlatform::strBase32Encode() and ::strBase32Decode() helper functions.  This is an uncommon encoding, but it's used for integration with Google Authenticator and there aren't built-in functions to base32 encode/decode (RFC-4648) in PHP5.
* [CHD-3191] [Localization] Fixed an issue where the jquery.combined.min.js script file may be truncated during download in some environments due to a malformed character encoding. (Thanks to Oleg Petrachev for reporting the issue!)
Merge branch '6.1.4' into 6.2
Login refactor

* [Login/Security/Usability] The login system has been renovated to support different authentication methods per worker.  Previously, a worker had to know to switch between password, LDAP, OpenID, etc.  Now, admins assign a specific method to a worker.  The login form has two steps: in the first the worker provides their email address, and then they are routed to the appropriate login method for their account.  This makes it much easier to standardize authentication on something like LDAP and hide normal Cerb password logins entirely.

* [Login/Security/Usability] When a new worker is invited to Cerb, or a worker's authentication method changes, they will be given the opportunity to set up their account's credentials on the next login.  Previously an admin had to establish the initial password for new workers, and it was sent in plaintext through email -- and was possibly communicated in other ways between the admin and worker (SMS, email, chat room, etc).  This process was a weak link in security.  Now the worker can verify their identity through a one-time code, and they can set up a secure password right from their browser.  This process also works for the advanced authentication methods like OpenID or Password+GoogleAuth.

* [Login/Security/Usability] When a login authentication method other than 'password' is in use, workers will not be shown the 'change password' option.  Additionally, if the OpenID plugin is installed but not activated for a given worker, they will not be shown the OpenID options in their preferences.  This should reduce confusion.

* [Login/Security/Recover] Each worker may now configure up to three 'secret questions' that are used to verify their identity when recovering their account's login information.  In the past, all a worker needed to do to reset their login information was receive a code to their email address.  The secret questions add an extra layer of security, because even if the code is intercepted (e.g. man-in-the-middle attack, packet sniffer, key logger) the attacker would need to know secret information about the worker to assume their identity.  The page for setting up these questions makes recommendations about secure questions, but they should be open-ended non-quantitative questions like "What is your favorite sentence in your favorite book?".  Answers to such questions are incredibly difficult to research or guess compared to "How old were you when…" or "What is your father's middle name?".  Secret questions shouldn't have answers that can be found with a Google search or through social media.  The wording of the answer much be exact, with all punctuation; although answers are case insensitive.  An optional hint may be provided for each question and answer pair.

* [Login/Security/Recover/Plugins] A new centralized system for recovering an a worker account has been implemented.  This saves plugin developers from having to implement redundant or inconsistent recovery methods.  When a worker starts the account recovery process they are sent a one-time code through email and they are asked their secret questions (if configured).  Once identified, their login method is instructed to reset their credentials and their next login will run through the set up process again.

* [Login/Security] When an invalid worker email address is typed into the login form, the password form will always be shown to make it more difficult for an attacker to discover valid logins.  If the login form specified "Invalid worker" then an attacker could guess valid email addresses by using known worker names.  They may still be able to guess worker email addresses, but the system will not confirm if they are valid or not.

* [Login/Security] Invalid email addresses or failed authentication (i.e. bad password) will now cause Cerb to pause for two seconds before reporting an error.  This slows down brute force attempts (at least on a single connection).  In a near future update this delay could become longer with each successive failure, and lock the account.

* [Login/Plugins] The login process may now be asynchronous.  For example, with the OpenID plugin there are multiple URL redirects before authentication is successful or fails.  Previously, Cerb expected an immediate answer from $extension->authenticate().  Plugins that need to redirect the browser before proceeding may redirect to the new /login/authenticated endpoint to finalize the new session.
* [Devblocks/Platform/QR] The jquery.qrcode plugin by Jerome Etienne is now available in the global jQuery environment.  This is useful to quickly send information to mobile phones from the screen.  See: http://jeromeetienne.github.com/jquery-qrcode/
* [CHD-3099] [Login/Security/Google Authenticator] Implemented a new worker login plugin for two-factor authentication using 'Password + Google Authenticator'.  This plugin requires workers to provide both their password and a time-based one-time password from the Google Auth mobile app (available for iOS, Android, and Blackberry).  Cerb supports configuring Google Authenticator with a QR code that is displayed on the screen during a worker's first login.  This significantly improves security by requiring both "something you know" (the password) and "something you have" (the physical mobile phone) in order to log in; and it's unlikely an attacker will have both.  Each worker's mobile device is configured (via QR code) with a different random 16-character secret.
[Code Cleanup] Fixed a typo in the constant name of hte HTTP_X_FORWARDED_PROTO header that's checks if SSL is enabled in a proxied connection.
6.1.4-release checkpoint
Merged 6.1.4 into 6.2
6.2-beta checkpoint