Socket.io chat through apache server (also running php main site) - apache

I have been trying to come up with a solution for my website to play nicely with socket.io. Right now I have apache serving my website (mostly in php) and I am trying to implement a live chat support feature using socket.io (node). I am able to get the chat functionality working separately (using express and going to wundertutor.com:8000) but when I just go to wundertutor.com (where the chat functionality is included as well), I am getting issues with CORS (Cross-origin resource sharing). Here is my error (on the client side):
XMLHttpRequest cannot load http://chat.wundertutor.com/socket.io/1/?t=1356421805823. Origin http://wundertutor.com is not allowed by Access-Control-Allow-Origin.
OR
XMLHttpRequest cannot load http://chat.wundertutor.com/socket.io/1/?t=1356422229000. Cannot use wildcard in Access-Control-Allow-Origin when credentials flag is true.
depending on wether I include this line of code in my app.js
io.set("origins","http://wundertutor.com");
Basically, I just want my node app to be a suppliment to my main site, but I really don't know where to specify the CORS parameters. I have tried doing this in my .htaccess file, in app.js, as well as in the client javascript, none of which have proved successful.
(Also, another thing I find strange is that when I go to wundertutor.com:8000, my node app correctly opens up a websocket, but when I try to go to wundertutor.com, it tries to use XHR polling which ends up causing this CORS mess)
Any suggestions would really be appreciated!

I figured out my problem if anyone else is experiencing the same issue. While I still think that what I am trying to do is using CORS, I didn't have to do any specific setting of Access-Allow-Origin-Control on either the Apache or node.js side. What I did to fix my problem was to serve the socket.io javascript file from the node.js server as opposed to the apache server. This made the requests coming from the socket.io javascript file have the same origin as where the javascript file was loaded. Here is an example:
<script src="http://wundertutor.com:8000/socket.io/socket.io.js"> </script>
(node server - correct)
vs
<script src="/javascripts/socket.io.js"></script>
(apache server - wrong)

Related

How to secure streams from being embedded to unauthorised websites and domains with Ant Media Server?

I can easily watch and embedd any stream running on Ant Media Server with help of embedd URL but also it seems as other with the stream information can use the URL on their websites too.
I tried using CORS filter but it seems a little complicated and didn't work.
How can I easily prevent my streams from being embedded to unauthorized webistes/domains?
For workaround solutions in Ant Media server (v2.4.3 or older versions) please check here.
In v2.5.0 and above, you can allow selected domains through a single property file to let them embed the iframe code.
To allow only specific domains to embed the iframe code, edit the /usr/local/antmedia/webapps/app-name/WEB-INF/red5-web.properties file and add the below setting.
settings.contentSecurityPolicyHeaderValue=frame-ancestors 'self' https://allow-domain-name;
If you would like to allow multiple domains, then it should be like this.
settings.contentSecurityPolicyHeaderValue=frame-ancestors 'self' https://domain1 https://domain2;
​After making the changes, restart the server with sudo service antmedia restart.
'Self' is required to play the stream on the AMS dashboard panel itself. In this way, other than allowed domains, streams cannot be embedded using iframe code on other websites.

Disable retrying of POST request via AJAX if connection was dropped

Problem
Sometimes important HTTP POST requests sent with AJAX got duplicated so several entries of the same data got created in the production database, that is of course not supposed by users.
What is important is that users have a poor internet connection and this request is taking a long time (9-20 seconds). We can't reduce this time because it is the requirements of business logic.
Requests are sent with http, not https.
Details
We have Apache/2.4.18 (Ubuntu) with PHP module loaded and two frontends: one for desktop (AngularJS) and one for mobile (React) devices. AngularJS is sending requests with the $http service, and React is using whatwg-fetch (tried whatwg-fetch-timeout also).
We know from Apache access.log and PHP logs that the same request is coming from the client several times and PHP processes them without the errors. But! These requests have response with 200 status code, %b > 0, and %O = 0, that means request is aborted before a response is sent (Apache logging format docs).
Reproduce
So we tried to reproduce and the same happens sometimes. The following case is just a reproduced case, but this happens on mobile devices (iPhones and Android phones) with different browsers installed. Also, we have repeated it in the Firefox under Windows.
Environment: Windows; both Chrome and Firefox; React frontend version; no proxy used.
That's what we found out: Google Chrome identifies the request as "Stalled", but is internally trying to send the request multiple times (and it is received and processed on the server actually), because it got the network error (ERR_CONNECTION_CLOSED). Only when the browser succeeded to fetch the response, it stops sending the repeating requests.
Gathered info
URL_REQUEST event log from chrome://net-internals/help.html#events (headers are also available there)
Google Chrome dev tools request screenshots:
Headers tab
Timeline tab
I personally can't reproduce this even once and I suppose a good internet connection is a reason for this.
I have googled a lot and even found some similar Chromium bugs, but nothing exactly about this problem.
Thank you in advance for any useful information.
I am also not pretty sure which tags should I set for this question, so if I should add or remove some, please tell me.

Safari Localhost Permission Blocked

So ran into this issue today, where I have a website that needs the geolocation of the user. It was working fine when running locally on localhost, but now I get an error saying "Access to geolocation was blocked over insecure connection to http://localhost:4200". WTF Apple? I also tried 127.0.0.1 but got the same result. Am I missing something in the dev settings or did Apple just break everything?
Safari Version: 9.1.3 (11601.7.8)
Maybe it's possible to use https ( How to get angular-cli to ng serve over HTTPS ) and if not is possible directly for some reason maybe you can use a transparent proxy that offers https.
Many HTML5 new features like access to webcam, geolocation and others are now allowed only on pages served thru https scheme, so probably using https will work again. If not, maybe is possible to modify hosts file to workaround the problem.
I found a sort of solution but it is a bit tedious. I use ngrok to route my server and then the geolocation works fine. The only thing I don't like is that it has limits (if you are using free account), like you can't refresh a lot of times.
edit:
To Use ngrok download it first, then on terminal type
./ngrok http <port number>
ngrok example.
It will then show you the url routes. I used https. Go to to that address.
More ngrok instructions and download

Is cordova available in WL Webview where the url being loaded is a jsp or server side resource

I am loading a jsp or server side application using worklight webview (super.loadUrl("hostname:port/Myapplciation",false)). My question is will cordova related functionality work since its inside WL webview. If it doesn't work what is the actually reason because I had read that WL hybrid application runs inside a webview and cordova works there.
Thanks
yes, it will work.
(adding some more text to make answer at least 30 chars long so it can be submitted)
I don't have a working environment to try it out in, but my suspicion is that getting the JS files from either location should work, but that getting them from the device would be preferred because then you wouldn't have a cache miss and a remote download, and you wouldn't need to host them on the remote server.

Getting Orbited to work with my Twisted app

I can't seem to get Orbited working with my Twisted app. I have a page, served by Twisted (say localhost:8000/page) which includes Orbited.js from the orbited server (localhost:8001/static/Orbited.js). I then have a TCP chat server example running on port 7777. I try to use Orbited.TCPSocket to connect to the chat server:
conn=new Orbited.TCPSocket();
conn.open("localhost", 7777);
conn.send("test\r\n"); //error: bad readyState
It works fine when Orbited is serving the page, but not when twisted serves it from a different port. My orbited.cfg looks like this:
[listen]
http://:8001
[access]
* -> localhost:7777
And before (which worked) I had this in it as well:
[static]
test=index.html
Where index.html was another page grabbing localhost:8001/static/Orbited.js, and was accessed from localhost:8001/test.
How do I need to change my config file to work with requests from my twisted site on another port?
Update
I tried changing Orbited.settings.port to 8001 before trying to open the connection, but I got an error: "unsafe javascript attempt to access frame with url http://localhost:8000/page from frame with url http://localhost:8001/static/xsdrBridge.html#1. Domains, protocols and ports must match."
Hmm, also, I just looked at the orbited wiki, and apparently, setting Orbited.settings.port is exactly what I'm supposed to do. but I'm getting horrible errors
You can call send() only after the connection is in opened state.
Put a handler for .onopen() and do a .send() from there.
I have used Orbited in the past. It works in general but there are several quirks to get it set up and running smoothly. The project itself seems to be in a state of flux (it seems to be moving to node.js). Both of these points lead me to suggest that - if you can avoid it - not to use Orbited.
Are there alternatives that are cleaner? I would say, yes. You can pretty much emulate Orbited with Websockets on stock Twisted. This will clearly work for newer browsers. What about older ones? Well, there are open-source projects that wrap websockets and fall back to flash as a transport for older browsers. The setup works quite well, and actually feels cleaner than using a solution like orbited.
If you check out http://github.com/rlotun/txWebSocket you'll find the current state of Twisted's websocket implementation, as well as an example of how to fall back to flash on older browsers. Hopefully this will be useful enough for you to serve as a drop in replacement to Orbited.