bitwarden/server
1
0
Fork 0
mirror of https://github.com/bitwarden/server synced 2025-12-22 19:23:45 +00:00
Code Issues Releases Wiki Activity

Formatting

Browse Source
This commit is contained in:
Justin Baur
2025-09-04 11:09:39 -04:00
parent c3181d581e
commit 3e412955e2
1 changed files with 12 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

25
src/Core/Platform/Push/README.md
View File

@@ -29,8 +29,8 @@ await pushNotificationService.PushAsync(new PushNotification<MyPayload>
## Extending
If you want to extend this framework for sending your own notification type you do so by adding a
new enum member to the [`PushType`](./PushType.cs) enum. Assign a number to it that is 1 above the next
highest value. You must then annotate that enum member with a
new enum member to the [`PushType`](./PushType.cs) enum. Assign a number to it that is 1 above the
next highest value. You must then annotate that enum member with a
[`[NotificationInfo]`](./NotificationInfoAttribute.cs) attribute to inform others who the owning
team and expected payload type are. Then you may inject
[`IPushNotificationService`](./IPushNotificationService.cs) into your own service and call its
@@ -40,10 +40,10 @@ You should NOT add tests for your specific notification type in any of the `IPus
implementations. They do currently have tests for many of the notification types but those will
eventually be deleted and no new ones need to be added.
Since notifications are relayed through our cloud instance for self hosted users (if they opt in) it's
important to try and keep the information in the notification payload minimal. It's generally best
to send a notification with IDs for any entities involved, which mean nothing to our cloud but can then be used to get
more detailed information once the notification is received on the device.
Since notifications are relayed through our cloud instance for self hosted users (if they opt in)
it's important to try and keep the information in the notification payload minimal. It's generally
best to send a notification with IDs for any entities involved, which mean nothing to our cloud but
can then be used to get more detailed information once the notification is received on the device.
## Implementations
@@ -56,19 +56,18 @@ before its returned task completes.
Used when the application is hosted by Bitwarden in the cloud. This sends the notification to the
configured Azure Notification Hub, which we currently rely on for sending notifications to:
- Our mobile clients, through the Notification Hub federation with mobile app notification systems, and
- Our mobile clients, through the Notification Hub federation with mobile app notification systems,
and
- Our clients configured to use Web Push (currently the Chrome Extension).
mobile clients and any clients configured to use Web Push (currently Chrome Extension).
This implementation is always assumed to have available configuration when running in the cloud.
### Azure Queue
Used when the application is hosted by Bitwarden in the cloud, to send the notification over web sockets (SignalR). This sends the notification to a Azure
Queue. That queue is then consumed in our Notifications service, where the notification is sent
to a SignalR hub so that our clients connected through a persistent web socket to our notifications
service get the notification.
Used when the application is hosted by Bitwarden in the cloud, to send the notification over web
sockets (SignalR). This sends the notification to a Azure Queue. That queue is then consumed in our
Notifications service, where the notification is sent to a SignalR hub so that our clients connected
through a persistent web socket to our notifications service get the notification.
This implementation is registered in DI when `GlobalSettings:Notifications:ConnectionString` is set
to a value.