I am keen to do some modifications to the Discourse Mobile app to get push notifications working for our self-hosted installation of Discourse, particularly on iOS. From reading the What if I want to white-label the Discourse Mobile apps? thread, it seems that I would need to configure the allowed user api push urls setting to a URL which can receive the notifications, and then re-publish the notification, for example, to the Apple Push Notification Service. I had a few questions about the notifications: Is there any information about the format of the request which would be sent to the URL defined in the allowed user api push urls setting, and capabilities required on that server to receive the request? Does each user need to opt-in for push notifications, for the notifications to be sent to the on-forwarding server (defined in the URL above)? The only setting I could find was Enable Push Notifications in the user profile, but below the button it talks about having to change that setting on every browser…which is a bit confusing, since the notifications would be sent to an app rather than a browser, so I am not sure what that means? Also, when I click the button nothing happens - and it says Permission Denied in the console as I blocked browser notifcations, but again I am unsure how that is relevant to push notifications (and different from the Desktop Notifications setting further up in the user settings). EDIT: I also just noticed that Enable Push Notifications is not present in my self-hosted installation of Discourse, only in my meta account (hosted installation). Thanks!

I did a bit of trawling through the Discourse source code, and found the following in the post_alerter.rb file: app/services/post_alerter.rb c531f4ded MessageBus.publish("/notification-alert/#{user.id}", payload, user_ids: [user.id]) push_notification(user, payload) DiscourseEvent.trigger(:post_notification_alert, user, payload) end end end def push_notification(user, payload) if SiteSetting.allow_user_api_key_scopes.split("|").include?("push") && SiteSetting.allowed_user_api_push_urls.present? clients = user.user_api_keys .where("('push' = ANY(scopes) OR 'notifications' = ANY(scopes)) AND push_url IS NOT NULL AND position(push_url in ?) > 0 AND revoked_at IS NULL", SiteSetting.allowed_user_api_push_urls) .pluck(:client_id, :push_url) if clients.length > 0 Jobs.enqueue(:push_notification, clients: clients, payload: payload, user_id: user.id) end end end This adds another question to the list above: does each user who wants to opt-in for push notifications need a user-based API key? I am still not sure about the workflow of how a user would start an iOS app, agree to receive push notifications, and then all the stuff on the backend of Discourse happens to allow the push notifications for that user. Perhaps @sam could advise about how this works with the Discourse Mobile app and the hosted installations of Discourse?

[图片] skoota: does each user who wants to opt-in for push notifications need a user-based API key? yes [图片] skoota: I am still not sure about the workflow of how a user would start an iOS app, agree to receive push notifications, and then all the stuff on the backend of Discourse happens to allow the push notifications for that user. When you create your user api key and “approve” the app to read access, push access is implied. This can be controlled by your mobile phone anyway cause you can later on disallow push notifications. [图片] skoota: Is there any information about the format of the request which would be sent to the URL defined in the allowed user api push urls setting, and capabilities required on that server to receive the request? You are going to have to look at the tests and try it out yourself, totally open to having some public information out there, so go ahead and draft a topic!

Thanks for the info @sam [图片] sam: When you create your user api key and “approve” the app to read access, push access is implied. This can be controlled by your mobile phone anyway cause you can later on disallow push notifications. Okay, so I am still a bit confused here… Am I correct that users cannot create their own API keys? Does that mean an admin would have to create the keys for each individual user who wants push? I am guessing this is not the case, since Discourse hosted instances provide push (in fact, I got a push notification to my iPhone for your reply to this thread) and you are probably not setting up the keys for each individual user! What is the sequence of events for creating the user API key and approving the app? I have created an API key for my own user, and then logged into Discourse Mobile and authorized my phone (so it appears under “Apps” in my user profile). Is that it? I am a bit confused about when the user API key comes into play / is used? Is the allowed user api push urls setting the only place I need to specify the URL to which notifications should be pushed, or is that somehow worked into the user API key? [图片] sam: You are going to have to look at the tests and try it out yourself, totally open to having some public information out there, so go ahead and draft a topic! More than happy to, once I get my head around this myself :slight_smile:

[图片] skoota: Am I correct that users cannot create their own API keys? No that is 100% incorrect. api keys and user api keys are two completely different things, see (which may need a bit of updating): [图片] User API keys specification Integrations Discourse contains a system for generating API keys per user if a very specific protocol is followed. This feature facilitates “application” access to Discourse instances without needing to involve moderators. High level description At a high level: Client (desktop app, browser plugin, mobile app) generates a private/public key pair and return url Client redirects to a route on discourse giving discourse its public key Discourse gets approval from user to use app Discourse generat… [图片] skoota: What is the sequence of events for creating the user API key and approving the app? see: DiscourseMobile/js/site_manager.js at main · discourse/DiscourseMobile · GitHub read to end of file. [图片] skoota: Is the allowed user api push urls setting the only place I need to specify the URL to which notifications should be pushed, or is that somehow worked into the user API key? No, it needs to be hardcoded here as well: DiscourseMobile/js/site_manager.js at main · discourse/DiscourseMobile · GitHub

Righto, I am now starting to understand. So am I correct in saying that when a user logs into the Discourse Mobile app, and goes through the authorisation screen (to authorise the Discourse Mobile app / device to their Discourse account), it automatically creates a user API key for the Discourse Mobile app - as the app is displayed in the “Apps” section of the user’s profile page? [图片] sam: No, it needs to be hardcoded here as well: DiscourseMobile/js/site_manager.js at main · discourse/DiscourseMobile · GitHub Is there any way to set that through the UI at the moment, or must it be hardcoded? If it must be hardcoded, a totally basic question for you - how can I get that into my production instance? I also noticed in site_manager.js that the scopes does not include push by default. js/site_manager.js main user_api_public_key: this.rsaKeys.public, }; if (type === 'full') { params = { auth_redirect: this.urlScheme, application_name: this.deviceName, public_key: this.rsaKeys.public, }; } return this.serializeParams(params); }); } async requestAuth(url) { try { const authRequest = await SafariWebAuth.requestAuth( url, this.customScheme, false, …which concurs with what is displayed in the “Apps” section of my profile page: Read and clear notifications Read user session info Do I also need to hardcode in the push scope?

[图片] skoota: If it must be hardcoded, a totally basic question for you - how can I get that into my production instance? I am not following your question at all, I linked to source code for the mobile app you are planning on re-branding… [图片] skoota: Do I also need to hardcode in the push scope? You are looking at the source code for the mobile application that is shipped… read and clear notifications implies push

[图片] sam: I am not following your question at all, I linked to source code for the mobile app you are planning on re-branding… Sorry, my bad. I have been looking at the Discourse source code all morning and I didn’t notice that was the mobile app. Makes far more sense now :slight_smile: One last thing. With the allowed user api push urls in the Discourse settings, I am guessing that’s a way to allow the Discourse admin to control/limit where pushes can be sent regardless of what an external app registered? I also assume that needs to be the full URL for the push destination (e.g. http://forum.example.com/api/publish_ios)? Thanks for the advice, will report back with how it goes and look at writing-up a howto (assuming it goes well).

[图片] skoota: to allow the Discourse admin to control/limit where pushes can be sent regardless of what an external app registered? Correct, that is the point, end users have only limited control over where push notifications go. This is required for security, cause a rogue app could then make you leak information without you knowing it.

Thanks @sam. Appreciate your help :slight_smile:

Custom Push Notifications: allowed user api push urls

Development

ayazmaroof (Ayaz Maroof) 2017 年11 月 8 日 01:43 11

@skoota Just stumbled upon this. I am trying to do something similar for our own discourse. Were you able to get push notifications working?

话题		回复	浏览量
Push Notifications without using "allowed user api push urls " Development	4	575	2021 年3 月 1 日
Auto generation of user api keys for push notification Development	3	1429	2017 年11 月 13 日
iOS Mobile App Notifications Product Support	53	10340	2022 年6 月 7 日
iOS: Push notifications for independent sites Feature	4	1156	2023 年4 月 8 日
How can I beef up Discourse notifications? Product Support	12	2022	2025 年9 月 3 日

Custom Push Notifications: allowed user api push urls

相关话题