This accounts for poorly configured API clients that try to use cookies for authentication purposes. Treat everything with a session cookie as being a stateful request from the front-end.
Changes the API internals to use normal Laravel binding which automatically supports nested-models and can determine their relationships. This removes a lot of confusingly complex internal logic and replaces it with standard Laravel code.
This also removes a deprecated "getModel" method and fully replaces it with a "parameter" method that does stricter type-checking.
Versions of Pterodactyl prior to 1.6.3 used a different throttle pathway for
requests. That pathway found the current request user before continuing on to
other in-app middleware, thus the user was available downstream.
Changes introduced in 1.6.3 changed the throttler logic, therefore removing this
step. As a result, the client API could not always get the currently authenticated
user when cookies were used (aka, requests from the Panel UI, and not API directly).
This change corrects the logic to get the session setup correctly before falling
through to authenticating as a user using the API key. If a cookie is present and a
user is found as a result that session will be used. If an API key is provided it is
ignored when a cookie is also present.
In order to keep the API stateless any session created for an API request stemming
from an API key will have the associated session deleted at the end of the request,
and the 'Set-Cookies' header will be stripped from the response.
* cmd(upgrade): Attempt to gain users attention during upgrade
Changes color of the user and group to gain attention, common issue is having wrong user/group which breaks the panel. Outputs termination message when users spam enter skipping the upgrade wondering why it didn't upgrade.
Reminder to update wings, because users forget it.
* cmd(upgrade): Display wings upgrade documentation link
Due to wings pulling the server configuration rather than the Panel pushing it,
wings gets the wrong status for a server if both the status update and sync request
are ran in a transaction due to the status not being persisted in the database.
Fixes#3639
