I have a Progressive WebApp Chat application and I want to be able to be able to send or receive Push Notifications (on Mobile) and Web (Chrome) Notifications while on Desktop. Right now, I have a web client that is able to receive tickles i.e. data without payloads (payloads will then be fetched through an API call from my server)
I am using Pubnub to talk to GCM and APNS. I have working apps on Web, iOS(native) and Android(native) clients of my project. Right now, I am able to receive Push Notifications on my web app but without the payload.
No where is the server publishing anything. All publishes are done by the clients since its mainly a chat app.
From my Web/Android client, my pubnubPayload is:
var pubnubPayload = {
"text": "no payload!",
"pn_gcm": {
"data": {
"title": "shash",
"babe": "ya"
}
}
}
And then do a normal publish like this:
Pubnub.publish({
channel: myChannel,
message: pubnubPayload,
callback: someFunc
});
So, when I subscribe to a pubnub channel like this:
Pubnub.subscribe({
channel: selectedChannel,
message: function(m){
console.log(m)
},
error: function (error) {
// Handle error here
console.log(JSON.stringify(error));
}
});
I receive the message through Pubnub AND a push notification (but without the payload) on my webapp.
My question is:
How do I receive push notifications on web that have a payload? Is there someway pubnub lets you publish encrypted messages for webs client to be able to read the payload of the GCM push notification without using Pubnub's Access Manager?
Or is using PAM my only option and should fix the no payload issue?
PubNub Access Manager not required for Message Encryption
PubNub Access Manager and message encryption are not directly related and is not required to encrypt your messages, but all applications using PubNub should implement Access Manager to control who can do what on channels by granting permissions (read/write/delete) to auth-keys that your client apps will init PubNub with to use those channels as you intended.
Encrypt using Standard TLS (formerly known as SSL)
To encrypt messages, simply initialize PubNub with TLS enabled (ssl might be the name of the parameter but it is the latest TLS, not the old SSL that was deprecated). This will use standard TLS encryption from your server or client apps to the PubNub network.
Encrypt messages using Cipher Key for AES 256 Encryption
If you wish to have your messages encrypted from your server/client apps to PubNub and all throughout PubNub, just provide a cipher key when you initialize PubNub. The best part about this is that you hold the keys, not PubNub, so no one can read your messages except the holders of those cipher keys.
Custom Encryption using the encrypt/decrypt API
The question asked here includes mobile push notifications which means you can't encrypt the full message if you want the mobile push message to be sent by PubNub to the push services (APNS/FCM) and handled by those services properly. The realtime message will be sent as is - encrypted - to the client subscribers. But you can encrypt the important/confidential parts of the message and leave the parts that need to be ready by PubNub and the push services unencrypted using the encrypt and decrypt APIs. The article, Encryption for APNS, GCM, WMS with PubNub, is a bit old but should provide the required insights.
Related
I've been breaking my head over how to do this, as it doesn't seem to fit any example I could find online.
My IOT device servers will run on the client network and may be accessed over it or over the open internet (with port forwarding). the device comes with a paper-printed initial pass like a router.
the client is running a mobile app.
As I hate planned obsolescence (ie, the device should keep working even if the company shuts down), I don't want to create a dependence on any third-party auth service, so the server and the app should just establish trust between themselves.
with the initial contact assumed to be trusted.
In all the examples for gPRC auth I could find, the client should somehow have ahead of time the server public key. but as there are many devices, and I want each one to have a unique cert, I don't see how I can ship the app preloaded for the specific device the user will get.
I have come up with the following:
the device generates private/public key
an insecure grpc channel serves the public key to the client
the secure grpc channel is established with that key
the client authenticates with the initial password to use the API over the secure channel
client changes the password
I'm not looking for super-max security, just basic common-sense security.
the main issue I have with the typical scheme where SSL is used to authenticate vs a domain is that I don't know via what domain/address the device would be accessed.
are there any glaring problems in the scheme? or any reason it would not work?
Thanks!
Am using IBM Worklight Studio 6.1.0.02-20160314-1430
Its Hybrid application.
Request and Response data between app and adapter calls is clearly getting visible when do inspect(Network-->query) in an application. Its also possible to edit request or response parameters by interrupting worklight app using third party tool like Charles. Implemented SSL pinning in the application but some how SSL pinning also breakable as lot of tools already available in online. Is Worklight giving any encrypt-decrypt mechanism for request and response parameters which is communicating between adapter and app.
Currently I tried adding custom encryption from app side and custom decryption at adapter side for request parameters. This is very tedious process as my app having hundreds of procedures. Please let me know any centralized security I can implement so that request and response should not be visible anywhere between app and worklight server even if someone inspect also.
When you redirect your traffic through a proxy such as Charles , it is expected to see communication in plain text. In this scenario you configure the setup by accepting certificates issued by Charles and modify your application to direct communication via Charles. You will not see your data in plain text if you try to sniff an on-going SSL traffic.
That said, certificate pinning feature is available out of the box starting MFP 7.1 onwards. Certificate pinning is done before making any calls to the server and as such all your communication can be secured.
You already seem to have adopted the other approach of encrypting parameters at the client and decrypting later at the server. In case you have many adapter invocations, you can have a single method that produces encrypted content and all your adapter invoke parameters can be passed through this.
1) Are push notification messages from IBM Mobilefirst are guaranteed? At least delivering them to APNS server? What happens if APNS server is not reached from MFP, is there any retry mechanism? How can I know push message is delivered?
2) Is there a time out value that we can control when MFP connects to APNS to send push message?
3) Are there any other such settings related to push with APNS in MFP? Where can I find details and explanations of such configurations/settings/properties?
1) MFP server does its best to deliver push notifications to the respective mediator. If delivery to APN server does not happen successfully , MFP server retries dispatching the notification. After multiple retries, if the notification cannot be sent to APNS, the information is logged and can be found in the standard logs. This is where you should be analyzing your network settings.
If push notification is delivered successfully to the mediator, the "message sent" count is incremented. This can be found either by accessing the Push notifications tab in Operations Console or using REST API calls.
2) Timeout value for the connection to APNS ? There is no timeout value as such that can be controlled.Communication with APNS happens over persistent socket connections. There is a timeout value to keep this socket open.
"push.apns.connectionIdleTimeout"
3) Refer to the KnowledgeCenter link on Push Properties.
I've read a tutorial about Apple push notification
here
Due to it, I have to provide App Id to identify which application will receive the notification.
In case of MDM server, the receiver is built-in client, so what value I have to put in field "App Id" when I register for SSL certificate
on another question I've post, I was answered that in case of MDM, the field "Topic" is used for built-in client to receive the notification. Topic is put in MDM payload that server sent to client. So how server register this field with APNS
Thank all,
1) You don't go through usual push certificate creation route.
What you do is following
You create a CSR for APNS request signging certificate
You send it to Apple and Apple will sign it, so you will have APNS request signing certificate
Each custom will create APNS CSR and send it to you
You will sign it with APNS request signing certificate
You will return this APNS CSR to the customer
The customer will upload it to Apple
Apple will sign it
Now, the customer has APNS certificate
The customer uploads it to the MDM server
All of these is described in a lengthy details in MDM protocol documentaion.
2)Here is how topic is shared between a client and the server
APNS certificate signed by apple will have a topic in it (in UID part of DN)
Your MDM server should extract it from APNS certificate and put it in MDM payload.
This payload will be delievered to a device and OS will send it to buil-it client
Now, both your server and built-in client know the shared topic.
In the docs for the Google Channel API it says:
"A channel is a one-way communication path through which the server sends updates to a specific JavaScript client identified by its Client ID."
In their diagrams they show a client sending its state with a POST. This seems like it would be slow. Can the client communicate with the Channel API through a socket? Or must it send via POST?
POST is a message type indicator and message format.
Major edit after more research!
See Google API doc
Looks like messages from the browser to the server do indeed open new HTTP-level connections to send a POST message. Whether a new TCP/IP connection is needed or not depends on the browser's management of TCP connections--new browsers do a better job of this. See wikipedia HTTP persistent connection
Re: This seems like it would be slow. Usually the browser traffic is asymmetrical--with most of the data from the server to the browser. Comet will help that use case.
Re: Can the client communicate with the Channel API through a socket? Do you mean IP socket? Browsers don't have an api for that. Do you mean "web socket?" I'm 98% sure it wouldn't work to combine the two techniques. But you could try...