bitwarden/server
1
0
Fork 0
mirror of https://github.com/bitwarden/server synced 2025-12-23 03:33:35 +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 ## Extending
If you want to extend this framework for sending your own notification type you do so by adding a 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 new enum member to the [`PushType`](./PushType.cs) enum. Assign a number to it that is 1 above the
highest value. You must then annotate that enum member with a next highest value. You must then annotate that enum member with a
[`[NotificationInfo]`](./NotificationInfoAttribute.cs) attribute to inform others who the owning [`[NotificationInfo]`](./NotificationInfoAttribute.cs) attribute to inform others who the owning
team and expected payload type are. Then you may inject team and expected payload type are. Then you may inject
[`IPushNotificationService`](./IPushNotificationService.cs) into your own service and call its [`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 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. 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 Since notifications are relayed through our cloud instance for self hosted users (if they opt in)
important to try and keep the information in the notification payload minimal. It's generally best it's important to try and keep the information in the notification payload minimal. It's generally
to send a notification with IDs for any entities involved, which mean nothing to our cloud but can then be used to get best to send a notification with IDs for any entities involved, which mean nothing to our cloud but
more detailed information once the notification is received on the device. can then be used to get more detailed information once the notification is received on the device.
## Implementations ## 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 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: 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). - 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. This implementation is always assumed to have available configuration when running in the cloud.
### Azure Queue ### 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 Used when the application is hosted by Bitwarden in the cloud, to send the notification over web
Queue. That queue is then consumed in our Notifications service, where the notification is sent sockets (SignalR). This sends the notification to a Azure Queue. That queue is then consumed in our
to a SignalR hub so that our clients connected through a persistent web socket to our notifications Notifications service, where the notification is sent to a SignalR hub so that our clients connected
service get the notification. through a persistent web socket to our notifications service get the notification.
This implementation is registered in DI when `GlobalSettings:Notifications:ConnectionString` is set This implementation is registered in DI when `GlobalSettings:Notifications:ConnectionString` is set
to a value. to a value.