-
-
Notifications
You must be signed in to change notification settings - Fork 850
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
Support multi-tenant config #564
base: master
Are you sure you want to change the base?
Support multi-tenant config #564
Conversation
We are also currently in need of this feature. As such we ended up creating our own patch a couple years ago, however at the time there appeared to be some reluctance to incorporate this feature. So our approach might be a bit more limited than the above but it also has less config and a few other advantages. Our use case is that we have multiple white-labelled apps, in the case of FCM this is easily solved as you can use the same token for multiple apps. However for iOS you need to generate a separate cert for each app. Our solution was to place all the certs in the same pem file and then read the Subject Name to pull out the correct key. However this means the JWT approach for iOS is not supported. (Im not sure if it could be supported, I simply haven't tried) We then pass the bundle-id as a prefix to the topic in the gorush request (Maybe in the case of the JWT token, we could just pass it in, instead of an id. And maybe we create a new key called "tenant" instead). This has a slight advantage over the URL path taking in this PR, because it mean the 3rd-Party app can just make one request to GoRush, and its GoRush's job to split the request. i.e.( Anyway, theres not much point to this post beyond just documenting one of the ways we solved this issue and some of the advantages it has. (It suited us well, as we mounted the cert file in docker, so if we needed to add another white-label, we didn't need to change the gorush config, we simply added the cert to the pem file. I wonder if this could be duplicated in this PR, essentially maybe mount a directory thats list all the cert file named by the app bundle id i.e. "my.app.pem"? (Should we have an equivalent for FCM/JWT?). And maybe move this PR away from using a different URL endpoint, and instead support adding a bundleID into the list of notifications, so the third party server cans still just make one request and have gorush deal with fanning it out.
|
60a7a68
to
2c29b4b
Compare
bff0f2d
to
6b6ef69
Compare
# Conflicts: # README.md # config/config.go # config/testdata/config.yml # gorush/const.go # gorush/global.go # gorush/log_test.go # gorush/notification_apns_test.go # gorush/notification_hms.go # gorush/notification_hms_test.go # gorush/notification_test.go # gorush/server.go # gorush/server_test.go # gorush/worker.go # logx/log.go # main.go # notify/feedback_test.go # notify/notification.go # notify/notification_apns.go # notify/notification_fcm.go # notify/notification_fcm_test.go # rpc/server.go # rpc/server_test.go
With the improvement of the FCM HTTP v1 API, there might be some opportunity to bring multi-tenant competencies on the table. I think we need to store multiple application's bearer tokens produced during the authorization. Can't we use this environmental variable capacities to adapt the application? |
@obuzyig I will take it. |
This should address #99 and #365