Is there a way to make the client have only read-only permissions to channels since we are distributing the client key with the web app using the pusher.js sdk?
The application key itself does not determine the permissions of a client. It only identifies which application the client is connecting to.
By default all subscriptions are read-only. Pusher offers three channel types:
Public
Private - with a private- name prefix that also requires subscription authentication
Presence - with a presence- prefix that also require subscription authentication and additional functionality for adding functionality to show which users are subscribed to that channel
A above, in order to subscribe to either Private or Presence channels your server needs to authentication the subscription request.
If you actually want a client to be able to trigger events on channels you need to:
Enable client events for an application
Subscribe to, and be authenticated for, a private or presence channel: channel = pusher.subscribe('private-channel')
Once subscribed (check using the pusher:subscription_succeeded callback) call channel.trigger('client-event', eventData) being sure to prefix the event name with client-
Related
Where do I specify which specific organisation within my account a webhook should be monitoring?
If you have webhooks enabled for your app, you will receive events for all orgs connected to your app. Each event will have a tenantId that you can use to see which org the event is for.
Put another way, your app either has webhooks on for ALL organisations or none.
You can get more details about this here: https://developer.xero.com/documentation/webhooks/overview#devx-app:~:text=Tenant%20ID%09The%20ID%20of%20the%20tenant%20that%20the%20event%20happened%20in%20relation%20to%20(e.g.%20OrganisationID)
When using the PubNub Presence feature, is it possible to provide a HTTP callback that PubNub calls when a user joins or leaves a channel? In my case I want to call a Parse.com cloud function.
To clarify: I don't want to call the function from a client, but have the PubNub.com servers take care of it.
Calling a web service on PubNub Presence events
PubNub offers Presence "HTTP Callback" generated from PubNub.com servers. You must ask your Account Manager to enable for you; send an email to support#pubnub.com to enable. Ask for "Presence Callback Active" and "Presence Callback Inactive" settings. You'll want to setup a dev/prod key pair to point the WebHook URLs at different environments.
The HTTP callback URL that is triggered when a channel becomes active.
Webhooks are now supported for all presence events: join, leave, timeout and state-change, as well as the channel active and inactive events.
For a full explanation please read this StackOverflow about PubNub Presence Webhooks and how to get them configured for you keys.
For a startup considering making public notifications intended for website users available via a Pusher channel, how do you prevent people from subscribing to that channel for a long period of time (camping essentially)? I know you can disconnect users after a period of inactivity if they are connected from a web client (by checking for activity on the client and sending a disconnect after a period of inactivity), but what if users decide to connect via a command-line app or something similar?
Pusher provides private channels where the subscription to those channels need to be signed using your application secret in order for the subscription to be allowed.
Given the command-line app example you've provided the author of that application would not know the application secret and would therefore not be able to subscribe to the private channel.
I would like to use Azure Notification Hubs to send push notifications to users of my app running across iOS, Android and Windows Phone.
I have managed to get the basics working but I don't know how to manage the App uninstall story.
On starting, the mobile app will call my Identity Svc to get an Auth Token.
It then calls its Platform Notification service (eg Google Cloud Messaging, APNS) to get a PNS Token.
After persisting the token to local storage it will call a back-end Contact Svc to register the customer's device. This service will create a subscription to the Azure Notification hub for the device.
This is illustrated in the following diagram:
Later on a back-end publishing service will call the Contact Service requesting a push notification for a particular user id. The contact service will lookup the Id allocated to a tag on the notification hub and send a push request.
What options are available to determine when a customer uninstalls the app? Is it just a matter of trapping errors when calling "Send" on the notification hub? I guess this could work if only sending to a single user but my intention is that certain message types are to be published to multiple subscribers. On the initial registration of a device a subscription will be created for a tag of the user id but also for a more general tag such as "New Promotion". The publishing service would later want to issue a "New Promotion" notification to all devices.
Why do you need to know app uninstalls?
Notification Hubs automatically expire registrations for devices that get uninstalled.
Also, I would avoid persisting the PNSHandles in your service at all.
The current guidelines for using hubs are the following:
store the registrationIds of the registrations associated with the device in local storage. This enables you to update tags and channel information with a single update call.
Because mobile connections are not always reliable, it is best to avoid creating a new registration without being able to store the registrationId in local storage. This can result in the device registering multiple times, causing duplicate notifications. You can achieve this by using the Create Registration ID and Create or Update Registration REST APIs.
The first API returns a registrationId without actually creating a registration. When the ID has been securely stored on the device storage, the device can call the Create or Update Registration API.
So I would have your ContactSvc expose two functionalities:
a) create registration id (just call hub to get it)
b) create or update registration given (registrationId, pnsHandle, tags?)
Then your device keeps the regId in its storage, ad after getting the handle from PNS, if as regId is not there creates a new one with endpoint a), then updates the registration with pnsHandle and tags.
Note that in this way your service does not need to persist handles or UUIDs, and does not need to worry about app uninstalls.
If you are keeping track of users, one approach is to periodically (once a month?) check in your hub if its registrations are still there...
You can reach me at #eliodamaggio if this is not clear.
We have a WMQ - WAS/JMS client setup through server connection channels where we are trying to put in security through user Ids.
Now, we set up a local user id on the MQ box, mquserid, and left the channel's MCAUSER blank.
We thought: the id running the MQ client (WAS in our case) wasuserid, when passed to MQ will fail as it is not setup on MQ box. So we shall then set up JAAS alias (with User Id: mquserid) for the Queue connection factory on WAS which will then be passed to MQ and will allow connections.
But, we are able to connect and put messages without the JAAS alias :(
I wrote a standalone Java program to connect to QMs and it is behaving correctly depending on the user Id I pass when obtaining connection.
Does WMQ treat WAS in a special way allowing connections without checking against its local user registry?
No, WAS is treated like any other connection.
In version 6 and earlier of WAS it will send a blank ID if the user ID on the WMQ connection is not specified. You can tell if this is the case by looking at the channel status while WAS is connected. The MCAUSER of the running channel will contain the ID that was used to connect. If the running channel status shows no MCAUSER value then WAS did not present an ID.
The other possibility is that the SVRCONN channel definition (not status) has a value such as mqm in the MCAUSER. In this case, the ID presented during the connection request is ignored. Again, check the channel status to see what ID is being used at run time or just check the SVRCONN channel definition to look for an MCAUSER value.
Now here's the kicker - if the channel's MCAUSER is blank then WMQ will accept whatever ID is presented. If no ID is presented, then the connected app or user runs as an administrator. If an app or user can be a WMQ administrator then they can do anything on the QMgr and can also remotely execute arbitrary OS commands on the server under the QMgr. Not good.
The correct answer is to set the MCAUSER on the channel to whatever value the app is supposed to connect as. At this point, the app cannot use any other ID because the channel will override it. However, anyone can connect to that channel so the next step is to authenticate the connection request. You can use an exit like BlockIP2 which is free or MQAUSX which is a commercial vendor product. BlockIP2 will filter incoming requests by IP address which may be sufficient for connections arriving from a static IP in a locked datacenter. MQAUSX will actually check the UserID and password sent during the connection request from WAS (or any client, for that matter). You can also use SSL and the channel's SSLPEER attribute to authenticate requests using X.509 certs. Note that if you use MQAUSX to validate a user ID and password either use SSL encryption with it or use both the client-side and server-side versions of the exit. Otherwise your credentials are flowed in cleartext over the wire which defeats the purpose.
Of course, if you secure the app's channel it's necessary to secure the other channels on the host such as SYSTEM.DEF.* and SYSTEM.AUTO.* or else an attacker will simply bypass the app channel.
Note that if the RCVR, RQSTR and CLUSRCVR channels do not authenticate requests or contain an MCAUSER value they also expose admin access. For example, if I want to control your QMgr and you locked the SVRCONN channels, I'd create a QMgr on my desktop, delete my SYSTEM.DEF.RECEIVER, create a new SDR channel called SYSTEM.DEF.RCVR and point it at yout QMgr. If your SYSTEM.DEF.RCVR (or S.D.RQSTR or S.D.CLUSRCVR) or any other of these channel types that you have defined lack SSL or an exit then I can connect and if they lcak an MCAUER then I can administer the QMgr anonymously and execute OS commands.
Any channel definition without an MCAUSER value allows administrative access.
Any channel without SSL/SSLPEER and/or an exit allows anonymous connections.
For more on this, please see the WMQ Hardening presentation and WMQ Security Lab documents at https://t-rob.net/links. Also, please see the articles on SSL and other WMQ security topics in the Mission:Messaging column on IBM developerWorks Tech Journal.