* Allow API to set a custom ID for server creation.
Useful when dealing with billing systems such as WHMCS
* Correct API code changes based on feedback.
This bug was reported to us by a user (@Ferry#1704) on Discord on
Monday, November 7th, 2016.
It was disclosed that it was possible to bypass the 2FA checkpoint by
clicking outside of the modal which would prompt the modal to close,
but not submit the form. The user could then press the login button
which would trigger an error. Due to this error being triggered the
authentication attempt was not cancelled. On the next page load the
application recognized the user as logged in and continued on to the
panel.
At no time was it possible to login without using the correct email
address and password.
As a result of this bug we have re-factored the Authentication code for
logins to address the persistent session. Previously accounts were
manually logged back out on 2FA failure. However, as this bug
demonstrated, causing a fatal error in the code would prevent the
logout code from firing, thus preserving their session state.
This commit modifies the code to use a non-persistent login to handle
2FA checking. In order for the session to be saved the application must
complete all portions of the login without any errors, at which point
the user is persistently authenticated using Auth::login().
This resolves the ability to cause an exception and bypass 2FA
verification.
* move password rules to Models\User::PASSWORD_RULES
* validate new password according to rules on password reset
* add password requirements info to auth.passwords.reset view
This action allows servers to be deleted, but only be soft-deleted for
10 minutes. After that time period the server will be completely
removed from the database and daemon. This allows some safety if a
server is accidentally deleted.
Force deleting a server will still work. If the daemon is in-accessible
the server will fail to be deleted. When server is soft-deleted admins
can still view its information page in the admin CP, however the server
will be suspended and inaccessible on the front-end or though the
daemon.
Admins can manually delete the server ahead of the delete timer, or if
it failed to delete previously they can do an immediate retry.
