-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
V15: Notification Hub #17776
base: v15/dev
Are you sure you want to change the base?
V15: Notification Hub #17776
Conversation
We don't need it, but seems like a thing that a server event router should be able to do.
src/Umbraco.Cms.Api.Management/Factories/DataTypePresentationFactory.cs
Outdated
Show resolved
Hide resolved
src/Umbraco.Cms.Api.Management/ServerEvents/ServerEventUserManager.cs
Outdated
Show resolved
Hide resolved
src/Umbraco.Cms.Api.Management/ServerEvents/Authorizers/DocumentEventAuthorizer.cs
Show resolved
Hide resolved
|
||
public override IEnumerable<string> AuthorizedEventSources => [Constants.ServerEvents.EventSource.Relation]; | ||
|
||
protected override string Policy => AuthorizationPolicies.TreeAccessDocuments; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Relations also exist for media
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we then require both TreeAccessDocuments
and TreeAccessMediaOrMediaType
? Or neither? What do you suggest? :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we don't have notifications for specific relations and both the parent/child can be of any entity type that supports them, I think we should probably use TreeAccessDocumentsOrMediaOrMembersOrContentTypes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great point, I've updated that 😄
Creates a SignalR hub that relays server events to the backoffice frontend.
Terminology
Details
Each event consists of:
These default events are
The events come from a single hub using a single method
notify
. Upon connecting, the user is authorized to receive certain events. This means that users with onlyDocumentTreeAccess
will only see document events, and so on.Additionally, it's also possible to notify a specific user. This still goes through the
notify
method and notifies all the users' connections. It is used to notify a specific user that they've been updated.Events are routed using the "group" concept in SignalR, every event source is its own group. An
IEventSourceAuthorizer
is then used to authorize a user (using a ClaimsPrincipal) for one or more event sources (groups), if a user is approved it's added to the group. This means that an authorizer is required for each event source for the routing to be used. If authorization is not required theIServerEventRouter.BroadcastEventAsync
method can instead be used, this sends the event to all connected users.If a user is updated, the authorization is re-run ensuring that any permission changes are reflected in the event routing.
This means to extend this you must:
IEventSourceAuthorizer
EventSourceAuthorizerCollection
IServerEventRouter.RouteEventAsync
, this can be done from anywhere, but a notification handler is an ideal placeIf you want to authorize using a standard .Net Core policy you can use the
EventSourcePolicyAuthorizer
abstract class, and specify which event sources should be authorized using which policy.Note that the event source authorized by the
IEventSourceAuthorizer
must be the same as the one yourServeEvent
for the event to be routed anywhereExample of adding event authorizer
Testing
YOUR-ACCESS-TOKEN-HERE
with that token in thewwwroot/js/event.js
fileNote: The auth token is short lived, so it may expire