* Allow admins to see last online text
* Use viewLastSeenAt permission
* Move permission to UserSerializer, removed from ForumSerializer
* Remove extra comma from ForumSerializer to keep diff clean
* Add permission to new seed migration
* Remove AbstractOAuth2Controller
There is no reason to provide an implementation for a specific oAuth2
library in core; it's not generic enough (eg. auth-twitter can't use it).
This code could be moved into another package which auth extensions
depend on, but it's a negligible amount of relatively simple code that
I don't think it's worth the trouble.
* Introduce login providers
Users can have many login providers (a combination of a provider name
and an identifier for that user, eg. their Facebook ID).
After retrieving user data from a provider (eg. Facebook), you pass the
login provider details into the Auth\ResponseFactory. If an associated
user is found, a response that logs them in will be returned. If not, a
registration token will be created so the user can proceed to sign up.
Once the token is fulfilled, the login provider will be associated with
the user.
Permission to rename/hide/edit one's own discussion/post is only granted
if the user has permission to reply to the discussion. This makes sense
if you think of these actions as forms of "replying" to a discussion.
Fixes#1419 because suspended users do not have permission to reply to
discussions, therefore they will not be granted these "own" permissions.
By not letting PHP render the stack trace, we prevent displaying
sensitive information (such as the database credentials). Instead,
we display a simple line with the exception message.
In the console, the full exception can still be shown, as that is
a tool only for forum admins anyway.
Fixes#1421.
This is in preparation for fixing #1421 - it allows us to
encapsulate the exception handling in the server classes, so that
we can keep the skeleton (flarum/flarum) lean.
When loading notifications, $this->type was null and thus array_get
was returning an array instead of null. I assume this issue was
introduced in a Laravel version upgrade? Anyway, this fixes it.
By moving the DispatchRoute middleware into an `afterResolving`
callback, this will allow a new Middleware extender to add a `resolving`
callback to the appropriate container binding, removing the need for the
ConfigureMiddleware event.
The ConfigureMiddleware event has been deprecated and should be removed
in beta 9.
This can be achieved using the Route extender, which is more
flexible, as it does not necessary connect the URL with the current
frontend's router.
(Example use-case: The ext-embed frontend will be a new frontend,
however any routes using this frontend will be part of the forum
route group.)
Refs #851.
By passing in just the frontend identifier, we can hide some of the
implementation details, in this case the identifier of the Frontend
instance in the IoC container.
