What a peculiar bug. Also modifies code to try and return the correct
status code, as well as return JSON based errors on any request that
Laravel thinks should have a JSON based response.
Removes the need for the javascript to be parsed by Blade template
engine by using a defined javascript variable with the values that are
necessary for checking everything and passing the correct values.
This does make it so that if a user does not have permission to do
something they could theoretically make the option show up in the
context menu, however when they click it, it will simply return an
error by the daemon.
* Fix @param namespaces for PHPDocs in ServerPolicy
* Reduce permission check duplication in ServerPolicy
This introduces a new checkPermission method to reduce code duplication when checking for permissions.
* Simplify logic to list accessible servers for the user
We can directly use the pluck function that laravel collections provide to simplify the logic.
* Fix pagination issue when databases/servers exceed 20
Laravels strips out the currently selected tab (or any GET query for that matter) by default when using pagination. the appends() methods helps with keeping that information.
* Refactor unnecessary array_merge calls
We can just append to the array instead of constantly merging a new copy.
* Fix accessing “API Access” on some versions of PHP
The “new” word is reserved and should not be used as a method name.
http://stackoverflow.com/questions/9575590/why-am-i-getting-an-unexpected-t-new-error-in-php
* Fix revoking API keys on older versions of php (5.6)
“string” was not a valid function argument type yet, so revoking keys results in an error on older installations.
* Fix issues with API due to methods named “list”
“list” is yet another reserved keyword in PHP and messes up older installations of PHP (5.6).
This renames all methods named “list” to “lists”. The API route names are left untouched (e.g. still called “api.admin.users.list”).
* Refactor and shorten some API logic
Used laravel collection methods where applicable to directly transform the values instead of converting back and forth.
This also removes some dead variables that were never used as well as getting rid of a n+1 problem in the Service API (loading service variables afterwards, not during the model creation).
* Return model save status in repositories where applicable
* Fix typo in ServicePolicy#powerStart
* Apply StyleCI corrections
* 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.
