How to implement websocket-based push service through Rails? - ruby-on-rails

I'm building a messaging app like WhatsApp. My goal is to expose only REST API through Rails and "push notifications" to connected clients via websockets. So clients communicate with server only with the REST API. Only the server sends data through the websocket. Clients can only receive data from it.
Currently I've built an eventmachine server listening for websocket connections and Unix domain socket connections. When a client performs a request on the REST API, Rails connects to the Unix domain socket to tell the eventmachine what connected client needs to be notified through the websocket.
My concern is about how it will behave in production (my server runs Apache Passenger). So I'm looking for some project to solve my problem. I had a look at Faye but I can't understand how to force it to send notifications to connected clients from an external process (that might be rails while is performing a request). Any ideas?

Have you looked at the sync gem I am doing something similar and that is what i use
https://github.com/chrismccord/sync
They have a really good video on integration and a example https://github.com/chrismccord/sync_example
and this fully supports Faye and Pusher.
I use Faye for dev and Pusher for production

Related

Send LoRaWAN downlink message through ThingPark Community Network Server

How can an Application Server send a downlink message to a LoRaWAN end device connected to Actility ThingPark Community platform?
ThingPark Community Platform offers a REST API to allow Application Servers sending a downlink message to an end-device. Every http request sent to that API need to be validated by a one-time token so that ThingPark can verify the integrity of the request.
The interface between ThingPark Enterprise Network Server and an external Application Server is described in the TPE LRC AS tunnel interface development guide.
For a quick test please check our simple javascript example.
Don't forget to update the constants at the beginning of the script.
The AS_KEY is the Tunnel Interface Authentication Key that you set on the
CREATE HTTP APPLICATION form.
The AS_ID is the Application ID that you can see once you have creeted the application.
If you prefer testing with curl see our curl test shell script.
Please note that this script does not calculate the one-time token. You need to calculate it yourself according to the Tunnel interface development guide or by studying the former javascript code.

What is socket hijacking?

I'm reading a great post on Rails 5 actioncable introduction. There it says: "Action Cable uses the Rack socket hijacking API to take over control of connections from the application server. ". What does the "socket hijacking" mean?
Socket Hijacking was implemented with rack 1.5.0 - a modular Ruby webserver interface.
Rack 1.5.0 basically provides a simple and adaptable interface for developing apps in rails. It does this by wrapping HTTP requests and their responses in a simply way. It also combines the API's for web servers, web frameworks, and middleware into a single method call.
So, in rack 1.5.0 socket hijacking is used to allow rails apps to overtake the client socket and perform other operations on it. These operations include:
Implementing WebSockets
Streaming data
Other interactivity between user's browser and server
WebSockets allows the user to send messages to a server and receive event driven responses without having to poll the server for a reply.
This is shown in this diagram - as you can see, once the WebSocket connection is opened, messages can be sent and received between the user and server.
Anyway, in the Rack Socket Hijacking API that you specified, it essentially provides two modes:
Full hijacking API
This gives the app complete control over what goes over the socket. The app server doesn’t send anything over the socket, and lets the app take care of it.
Partial hijacking API
This gives the app control over the socket after the app server has already sent out headers. This mode is basically used for streaming.
So - In the end, socket hijacking basically allows ruby/rails apps to override/overtake a client socket and carry out different functions on it, or as you wrote - take control of connections from the application server.

What approach to be used on application side in migrating web services to HTTPS from HTTP?

i have an app running on Apple app store with webservices from HTTP Server but now i want to migrate my webservices from HTTP Server to newly brought HTTPS Server. What is the best approach to achieve this without affecting older application users running application on HTTP Server?
P.S: After migrating to new server, older server will not work.
Edit: my older server domain is going to expire and also i have amazon server on which i am going to move my webservices. So the older and new server link are different.
Thanks

Web Server and App Server

I just want to know that how the web server call to app server code and pass the response to the client, Eg :-
Nginx web serve
Unicorn app server
Rails application
Our request sends to web server and how web server(nginx) pass that request to the app server(unicorn) and how app server runs the rails code or route and sends back the response.
To understand the collaboration of a web server to an app server you must study the architecture of the server first. I guess this link will give you a good idea about architecture and it's bonding.
Have a look here:

Security - Ejabberd - Validate Client

I have installed Ejabberd in our AWS Server
We are developing an iOS messenger app and we don't want other clients to access our messaging server other than our iOS app.
All the ejabberd services should be accessible only by our iOS app,
To register
To login
To send message and use any other service.
What are all the configurations and settings should I have to do to secure our server?
There is no 100% way to disable other clients from mimicking your own client. You may use different protocol, or one more layer of encryption or special marks that allow your server use to make sure that client is yours. But if someone will have desire to write his own client, he'll use your own client to understand what should be sent on the wire.
XMPP is build on the top of TCP so there is no good way of restricting access to the server socket. If you want to be compliant with XMPP you need to use encryption, otherwise use your own custom protocol (like Skype).

Resources