I am building web application and for push notification and messaging I am using leanplum . Leanplum provides with api keys like that
key='absc......'
app_id ='prod_abc.....'
Is it save to expose these two keys on client side javascript files which will be load on client browsers? What will be the possible impact of exposing these keys ?
Leanplum has Production Key and Development Key.
With Production Key, you can send API requests like Track. Assuming that attacker knows the User ID, attacker can send garbage to the server, but that's it.
With Development Key, you can connect to the socket and update In-app message template and other config stuff.
So always use the Production Key on production!
Related
I am having an API locally hosted in one of the servers (LAN). What I am looking to understand if it is feasible to enable push notification from the server in case of a record entry. Every time a post request is made to the local server, Is it possible to push a notification to a certain mobile device? Please note, I am not considering push notification from web services such as google, Azure, Firebase etc.
It is feasible.
As Sushi said, you can use WebSockets or other Sockets to keep connect between Apps and Server. When client connected to your server, server will record which app is connecting.
By the way, you can custom notification's url between server and app.Use some special characters to distinguish between your various parameters, such as &/[ ]. You are free to set the header and body style of the message. Also, when your message needs to be encrypted, some encryption methods can be used.
Here is a similar discussion about Building an Android notification server can be refer .
I'm trying to integrate an openFire XMPP server to my current company Spring server but have two major questions I cannot find the answer to -
I'll start with my current architecture first -
1. The xmpp server have a DB-server of it's own seperated from the Spring server DB, This is a dedicated machine to keep the users char history etc
2. The spring server have a DB of it's own where it keeps the user credentials (md5 encrypted) and also client applications data
3. The spring server is dedicated to serve HTTP requests (a dedicated REST server)
All in all I have 2 DB servers once chat server and one Rest server
Now for the questions -
1. Can I forbid registration to the xmpp server (i.e. whitelist the rest server ip and let it be the only one who can create users after a user registers on it)?
2.For security reasons the Rest server switch the session for a logged in user every 2 days the iOS and Android clients deal with session managment locally - How can I use those session with the XMPP server?
To clarify - I want the users to be able use the xmpp server only for chat purposes but only after they logged in to the application itself since the user session may expire the chat client will also have to re-authenticate against the REST server, how can I achieve this?
3. Won't it create an overload on the REST server? (i.e. the Rest server will now have to handle client requests and also XMPP server requests)
4. What is the best architecture to achieve this kind of a system (chat server, db server for chat server, rest server, db server for rest server) so that the system can scale horizontally?
I searched google for an article or something related to describe the general architecture but couldn't find nothing relevant, since I'm not "inveneting the wheel" here I would love to hear a good advice or be directed to an article that explains the How-To's
Thanks in advance.
The standard way in XMPP world for user authentication is SASL.
SASL have a very simple model: server sends to client some "challenge" string to client, and client sends "response" string to server, and they repeat this until server decides client send all required data. What data to send is defined in SASL "mechanism". There are number of well-known SASL mechanisms, e.g. SCRAM, and they are provided by most XMPP servers and clients "out of the box".
Your problem is - you already have authentication system and user database and want to reuse it for chat purposes. There are two ways:
Add your custom REST authentication as SASL module to your server. Google say it is already possible to write and add Openfire SASL plugin. Your SASL REST mechanism will do the same things as for browser, but required urls, tokens, etc. will be wrapped as "challenges" and "responses", e.g. server will send REST auth url as "challenge" for client, and client will open url, post credentials, get a token and send them as "response" back to server. Of course you need to add this SASL REST mechanism in client too.
Adopt your XMPP server to use your authentication database directly. In this case you only need to modify Openfire code to link it with your users/passwords tables (maybe there is already an admin tool for this). In this case clients will continue to use standard SASL mechanisms without modification. When this way may be easier than first one, remember your XMPP server should have access to plain-text passwords, which may be insecure.
You questions in order:
Yes, you can disable registration from XMPP client and point users to registration website.
You will see chat sessions in Openfire administration console and able to stop them, also you can write a module for do this by your schedule
If you will write SASL REST mechanism, there will no any difference between requests from chat clients and web clients for your REST backend, they will look the same.
As I described first, you no need separate DB for chat server and you able to setup multiple chat servers connected to your REST backend.
Firstly, here is state of my application:
I have a request coming in from a client (angularjs app) into my API (web api 2). This request is processed and a record is stored in a database. A response is then sent back to the client.
Currently, I have a windows service polling and processing this record(s).
Processing this record can be long running. As a side effect to processing this record, there might be notifications generated to be sent back to one or more clients.
My question is how do I architect this, such that I can utilise SignalR to be able to push the notifications back to the client.
My stumbling block:
I can register and store (in-memory backed by a db) the client's SignalR connectionid along with the application's own user identifier. This way I can match a generated notification with a signalr client.
At the moment, I'm hosting the SignalR hubs within the IIS process. So how do I get back from the Windows Service to IIS to notify the client when a notification is generated?
Furthermore, I should say I am already using SignalR elsewhere in the application and am using a SQL Server backplane.
The issue's with the current architecture:
Any processing is done in the same web request, and notifications are sent out via SignalR before a response to the client is returned. Luckily, the processing is minimal and very quick.
I think this is not very good in terms of performance or maintenance in the long run.
Potential solutions:
Remove SignalR hubs from IIS and host them somewhere else - windows service?
Expose an endpoint on the API to for the windows service to call to push the notification once a notification is generated?
Finally, to add more ingredients to the mix: Use a service bus to remove the polling component of the windows service, and move to a pub/sub architecture. Although this is more work than I want to chew off right now.
Any ideas/recommendations/constructive criticisms are welcome.
Thanks.
Take a look at this sample for starters
Another more advanced solution can be using a backplane to manage the communications between the front end and the backend...
HTH
Recently, I want to change my codes of pushing notifications to apple from basing on old binary API to new http2 API. The question is that should I use a different certificate for this http2 API when I connect to apple ? Because when I send a notification to apple with a valid token(the token is valid when I send notifications with old API) using http2 API, it returns "BadDeviceToken". So I'm wondering whether the token is really bad or the certificate that I use is not qualified .
We were also trying to break our heads with such an issue where we were trying to send push to production device tokens using the HTTP/2 API but were getting {"reason":"BadDeviceToken"} as the response and it was a clear mistake from our side, we were using the same code that we were using for test push notifications on dev environment to send push notifications on production, which was sending push to
https://api.development.push.apple.com/3/device/
rather for production it should be
https://api.push.apple.com/3/device
Hope it helps somebody but one issue with the new API is the distribution SSL certificate works for both the sandbox and production, not the other way round so be careful.
You can still use your old certificate with the new HTTP/2 API.
The BadDeviceToken is most commonly because you are trying to push through their production gateway wth a development token or vice versa.
Tokens are only valid for either development or production, and this is determined by the provisioning profile of your app.
I'm giving socket.io a whirl and I'm curious as to what I should and shouldn't be doing with websockets.
For example is there a way to authenticate a websocket (include id in every message perhaps?)? Let's say I'm creating a 'google docs' like app in which people can create new documents. Should I be using AJAX to create new documents instead of websockets? That way I can use the standard HTTP transport layer to do all of the user authorization (checking session, etc) and then simply ping back the page with a websocket event. Curious as to how people handle situations like this.
I would recommend using AJAX wherever you do not absolutely need web sockets. Web sockets end up creating more load on the server side (socket.io will take care of fallbacks in case web sockets & flash sockets are not available). In short, use web sockets where you need to maintain that state/connection to the client.
If you wish to use web sockets, using cookies with socket.io would be one approach that would allow you to keep track of your sessions. If not using socket.io right away, you can send req.sessionID (key) to the client, store the session information in Redis/Mongo etc. When the socket.io connection is attempted, read the cookie value & send it to the server - where you can get the session store information. There may be issues if you use flash sockets as one of the fallbacks.
Hope this helps.