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).
Related
Need to be able to continuously receive calls when a Chrome webpage is open. How do I do that even for users who are inside a strict enterprise network?
WebSockets? (but there's the proxy problems that doesn't know what wss:// is)
HTTP? (but will I have to poll?)
Other?
Since you included the "vLine" tag, I'll reply with some information on how our WebRTC platform will behave in an enterprise network. vline.js will use a secure WebSocket by default if the browser supports it and fall back to HTTPS long polling. As described here, the secure WebSocket may work depending on the exact proxy configuration. Feel free to test it out by using GitTogether or creating your own vLine service for testing.
When I connect to signalR hosted in same virtual directory, I get data via websocket transport. But in case of cross domain, long polling is getting used as a transport.
Here browser compatibility is not an issue as I am trying in Chrome browser.
What I can do to use websocket as a transport in case of cross domain.
I have tried every possible solution available on net, including available at signalR wiki.
https://github.com/SignalR/SignalR/wiki/SignalR-JS-Client-Hubs
Thanks David for answering my question in the comments:
Because only IIS8 supports websockets and neither SSE or ForeverFrame works cross domain so you're stuck with long polling –
I have an app, and it makes an https connection to a server. Is it possible to use something like wireshark or charlesproxy to just see the useragent that it's connecting with? I don't want to see any of the actual data, just the useragent - but I'm not sure if that is encrypted as well? (and if it's worth trying)
Thanks
Is it possible to...
No. Browser first establishes secure connection with server, then use it for transfer all data including requests' data, various headers etc.
Too late for the original inquirer, but the answer is that it may be possible in some cases, depending on application implementation.
You can use fiddler, and by turning on the 'decrypt https traffic' you also have visibility to the HTTPS content in some cases.
What fiddler does (on windows at least) is register itself within the wininet as system proxy. It can also add certificates (requires your approval when you select to decrypt https traffic) and generates on the fly certificates for the accessed domains, thus being MitM.
Applications using this infrastructure will be 'exposed' to this MitM. I ran fiddler and ran a few applications and was able to view https traffic related to office products (winword, powerpoint, outlook) other MS executables (Searchprotocolhost.exe) but also to some non-microsoft products such as apple software update, cisco jabber)
This might sound really naive but I would really find a descriptive answer helpful.
So, my question is this:
I can use Firebug to look at AJAX requests made from any website I visit. So, am I right in saying that I wouldn't be able to examine the same communication between the client and the server if the website choses to use Websockets? In other words, does this make it more secure?
No. Not at all. Just because the browser does not (yet) have a tool to show WebSocket traffic, doesn't make it any more secure. You can always run a packet sniffer to monitor the traffic, for example.
No, because there will be other ways beside the browser-build in tools to read your traffic.
Have a try: Install and run Wireshark and you will be able to see all packets you send and receive via Websockets.
Depends on the application. If you are fully Ajax without reloading the document for data then I would think websockets would provide a better authentication for data requests then a cookie session in regards to connection hijack. Given that you are using SSL of course.
Never rely on secrecy of algorithm cause it only gives you false sense of security. Wiki: Security by obscurity
Remember that browser is a program on my computer and I am the one who have a full control over what is send to you, not my browser.
I guess it's only matter of time (up to few months IMO) when developer tools such as Firebug will provide some fancy tool for browsing data send/received by WebSockets.
WebSockets has both an unencrypted (ws://) and encrypted mode (wss://). This is analogous to HTTP and HTTPS. WebSockets protocol payload is simply UTF-8 encoded. From a network sniffing perspective there is no advantage to using WebSockets (use wss and HTTPS for everything at all sensitive). From the browser perspective there is no benefit to using WebSockets for security. Anything running in the browser can be examined (and modified) by a sufficiently knowledgeable user. The tools for examining HTTP/AJAX requests just happen to be better right now.
I'm trying to port a win32 application to Windows Mobile 6 / 6.1 / 6.5. It uses winhttp which doesn't appear to be available on the mobile platforms.
My initial thought was to replace it with WinInet - but I wondered if anyone had a better idea?
WinInet is actually a more appropriate HTTP client library for client nodes.
Here's some things I like about WinInet voer WinHttp:
If your client app needs to make lots of requests from the same server, WinInet will implicitly queue the requests up so as not to flood the server. (But is transparent to the client app). In other words, it respects RFC 2616 guidelines on simultaneous connections. This is great when your app is pulling down a lot of images (or files) from the same server simultanously.
Will the use the IE cache for fetching content. (Which I assume an equivalent cache exists on Mobile platforms).
Proxy server auto-detected from IE settings. Probably less of an issue with mobile since the IP network is a bit more open. But if you had to support proxy servers with WinHttp, you'd have to use other API calls to specify the server directly.
I've used Wininet and it works. But it's not ideal as its timeouts are broken. And developing a complete asynchronous design with it required a ton of code.
So instead, I'm trying libcurl.
So far though, I still haven't managed to get it compile properly and link. Porting stuff is such a pain sometimes. But I digress. ;)