I currently have an application that is using the Pusher API to enable real time messaging and would like to remove my dependency on Pusher.
I am keen to keep my current application as it stands and connect over websockets to a channel on an Phoenix app that is a completely separate application on a separate instance. Reasoning for this is it will allow me to separately scale the phoenix app when there is a large number of messages.
Is this possible? I have experience of using Socket.IO and this supports this functionality by specifying the location of the Socket application when trying to connect.
Yeah it's possible, you can set the option :check_origin as explained in lib/phoenix/transports/long_poll.ex source code:
https://github.com/phoenixframework/phoenix/blob/master/lib/phoenix/transports/long_poll.ex#L26
:check_origin - if we should check the origin of requests when the
origin header is present. It defaults to true and, in such cases,
it will check against the host value in YourApp.Endpoint.config(:url)[:host].
It may be set to false (not recommended) or to a list of explicitly
allowed origins
Related
I'm working on a PoC of a system where a mobile app client needs to be connected on a server with communications going both ways : either for updating the server or being updated by it. There is no client-to-client communications for the moment.
The client logs in the server via an HTTPS/POST method and gets back a token if the credentials are OK. This token is to be used by any further communication in order to authenticate the user. The reason why I'm using HTTPS for logging in is that there also is a web interface for other purposes.
I could not find a tutorial or documentation that explains how to implement this use case with channels based on websocket transport. All I found so far are either partial and focus on some specific aspects (eg authentication, setting SSL/TLS, etc) and assume the reader already knows the rest or are the over simplified implementations of the chat app. I'm sure I'm not looking at the right place...
My questions are:
What would be the list of callback to implement this use case on
either side
On the server: how does a process send notifications to the
client
NB: I'm using Elixir 1.5.1 and Phoenix 1.3
From the Phoenix guide:
Each Channel will implement one or more clauses of each of these four callback functions — join/3, terminate/2, handle_in/3, and handle_out/3.
The page I linked contains also an MCVE of sockets running on Phoenix. In the bottom there are examples of how the server-client communication is done.
The only thing to apply this to your use-case would be to use one of authentication libraries (e.g. Überauth that comes with great examples) to handle token on each subsequent connection request.
I am working on a project which is basically a Customer Feedback Analysis Dashboard. There are few graphs on the dashboard and data for each graph is fetched from the server through API requests.
Right now the dashboard is updated every time the page is refreshed. I want it to be updated immediately when there is a new feedback in the system. I am confused, whether I use websockets to send data for each graph or just a flag and use that flag to fetch data through API requests.
Like, facebook/twitter does. They tell you about new posts/tweets and when you click that button your feed/wall gets updated.
If you want to "push" data from server to client and you want that data to show up in a timely fashion (e.g. within 10-20 seconds of when it was available on the server), then you will want to implement some sort of "push" solution where the server can efficiently push data to the client whenever there is new data to send.
There are several possible approaches:
webSockets
socket.io
Server-sent events
Mobile platform-specific push (Android and iOS)
For a general purpose solution that works within a browser, you will want to use one of the first three. socket.io is built on top of webSockets (it just adds more features) so architecturally, they are similar.
Server-sent events are fairly new (modern browsers only) and are only for one way communication (from server to client). webSockets can be used for communication either way.
I'd personally recommend socket.io because of the features it offers (such as automatic client reconnection) and a simplified messaging layer. You can see the feature difference between socket.io and webSockets here. With socket.io, the client makes a connection to the server when the web page is loaded and that connection is persistent. After the connection is established, then either client or server can send messages to the other at any time in a very efficient manner.
Other useful references:
Push notification | is websocket mandatory?
websocket vs rest API for real time data?
Why to use websocket and what is the advantage of using it?
What are the pitfalls of using Websockets in place of RESTful HTTP?
Ajax vs Socket.io
I'm new to ServiceStack and want some validation on a pattern we're thinking about using.
We want to use ServiceStack with Xamarin and Message Queues. While I understand how REST works under the covers, I'm not sure how the Message Queues on ServiceStack work and if its appropriate for mobile devices.
Specifically we know that all mobile devices are essentially behind a NAT firewall setup by the Telco. Meaning Clients can talk to servers, but servers cant talk directly to clients, without the client talking first.
While the concept of a ServiceBus is designed specifically to handle this case, i'm not sure if its "mobile network friendly".
I would assume that the client side implementation, would need to work in one of two ways: polling, blocking get.
Polling would have the client side frequently runing a Http GET to ask the server if anything is available on a queue. A Blocking Get would, perform a Http GET but have the server return nothing until data is ready. Or is there another technique that i'm missing?
If it is a poll, is there any way to control the Poll frequencies in service stack. If its a blocking get how is this configured..
What happens when the app goes to the background, do we need to cancel the connections manually. etc.etc.
We tool an old version of the ServiceStack client library and ported them to xamarin. We now see that the latest ServiceStack client side library is Xamarin compatible.
So, basically my question is: Had anyone used Message Queues from a Xamarin Mobile to ServiceStack with RedisMQ or other server side message queue.
I heard from somewhere WebSphere server can be configured to allow only a pre-defined set systems (IPs, domains) to access server contents such as WSDL.
Need help with following questions:
Is this supported?
What are the steps to do the same?
Prerequisites?
Thanks!!
Check this post Ban ip for deny access to an app. It describes various methods (configuring transport channels, http server, or developing custom filter). Although it talks about banning access, same technique can be applied to allow access.
Take notice however that using transport channel will apply to all applications and resources available via given port (not just wsdl). So the solution depends on level of granularity you require.
I'm developing a relatively simple PhoneGap application (iOS) that needs to make cross origin websocket requests to a Go server. I have set $.support.cors = true; $.mobile.allowCrossDomainPages = true; in my application before any network activity. The server serves a simple HTML/JavaScript page for testing / diagnostic purposes and everything works great there - the websocket connections work, the server delivers the correct data, it's all dandy.
This is not the case with the PhoneGapplication running on the iOS Simulator. In the Simulator, Safari can in fact reach my testing/diagnostic page. However, the PhoneGapplication times out.
I'm doing more investigations but my suspicion is that this is a simple server configuration issue and someone with more knowledge of Go and/or the blessed websockets package and I thought I'd ask here concurrent with my investigation.
CORS does not apply to WebSocket. With WebSocket, there is an "origin" header, which browser MUST fill with the origin of the HTML containing the JS that opens the WS connection. Non-browser clients may or may not fill that header (and can fill it with anything they like anyway). The WS server then is able to decide whether to accept the connection or not.
Further: I don't know if the WebView used by PhoneGap sets the origin header when the HTML comes from local filesystem. I would try wiretap the traffic and have a look.
There is no Cross Domain concern in PhoneGAP appliations (remember that this policy is enforced client side and that the server's header only give an indication).
The problem is probably in your handshake as PhoneGAP doesn't support natively the websocket handshake. There are open source projects introducing it in PhoneGAP/iOS as this one (not tested by me as I'm not an iOS developer).