TMC is an independent, primarily volunteer organization that relies on ad revenue to cover its operating costs. Please consider whitelisting TMC on your ad blocker or making a Paypal contribution here: paypal.me/SupportTMC

Cross-origin Websockets Disallowed in Tesla Model S Browser?

Discussion in 'Model S: User Interface' started by GeekLad, Jul 25, 2015.

  1. GeekLad

    GeekLad Member

    Joined:
    Apr 27, 2014
    Messages:
    63
    Location:
    Fort Lauderdale, FL
    The car's browser does allow websockets, and I confirmed via https://www.websocket.org/echo.html. I was messing around a bit with the Pushbullet API to try to send notifications to a page loaded in the car's browser. I was able to build a very simple HTML/JavaScript page that connects to the Pushbullet websocket stream via JavaScript, and receive Pushbullet mirror notifications. I didn't have to do anything on a server, and Chrome allows the cross-origin websockets connection with no issue. The page works great on a desktop browser.

    When I tried loading the page in the Model S web browser, it doesn't work. As you can imagine, it's a PITA to debug since there's no developer console in the car's browser and you can't see what's going on under the covers. After some "manual" debugging with code, it seems like it's not even ever making the websocket connection. It wouldn't fire any of the websocket events, except for the onclose event, and it fires with a readyState of 2.

    At this point, my only guess as to why it doesn't work is because the car's browser won't allow cross-origin websocket connections. Has anyone experimented with websockets on the Model S browser? If so, have you encountered similar issues?
     
  2. jerry33

    jerry33 S85 - VIN:P05130 - 3/2/13

    Joined:
    Mar 8, 2012
    Messages:
    12,763
    Location:
    Texas
    I haven't tried cross-origin websockets but Tesla's Webkit is very limited because it prevents any possibility of video being displayed. I understand that they will replace it with Chrome at some point, but I wouldn't be surprised if it also doesn't work for many items.
     
  3. cryptyk

    cryptyk Member

    Joined:
    Jul 8, 2015
    Messages:
    260
    Location:
    United States
    Next thing I would try is to setup an nginx server on an EC2 instance as a reverse websocket proxy, and serve your page from the same domain.

    Not sure what kind of traffic you're pushing through the proxy, but as long as it isn't massive, the cost of the EC2 instance should be pretty reasonable.
     
  4. GaryREM

    GaryREM Member

    Joined:
    Jul 16, 2013
    Messages:
    324
    Location:
    Fairfax, VA
    Whether or not they replace it with Chrome, why do you think they would implement all the functionality? The Webkit version is limited because of Tesla's implementation choices, not because of amy Webkit limitations (maybe I didn't understand what "I wouldn't be surprised if it also doesn't work for many items." applied to...).
     
  5. jerry33

    jerry33 S85 - VIN:P05130 - 3/2/13

    Joined:
    Mar 8, 2012
    Messages:
    12,763
    Location:
    Texas
    The "I wouldn't be surprised if it also doesn't work for many items." means just what you said. There will likely be the same limitations because Tesla needs to ensure that there will be no video visible by the driver. (It would be nice if it knew about "park" so you could watch when not driving, but I suspect that it would be very hard to ensure no video when not in park from web based content. The cars that do this are talking about DVD only, which is easy to program.)
     
  6. cryptyk

    cryptyk Member

    Joined:
    Jul 8, 2015
    Messages:
    260
    Location:
    United States
    Speculation from a software and firmware engineer:

    Shouldn't be any harder than doing it with a DVD in other cars. It's likely just not a priority for the dev teams.
    I'm hoping that part of the v7 UI overhaul will entail is a refactoring of the existing underlying architecture. It's a pretty common pattern that you write the first version and it's "good", but you learn a lot during the process.
    Second versions tend to lean more toward "overly" architected component systems that can communicate things over a bus, etc.

    In any case, they've already modified the browser, they already have access to other parts of the car from the browser, and they can make the video work while parked and turn it off when in drive. They've just chosen not to.
     
  7. cynix

    cynix Member

    Joined:
    Jul 7, 2014
    Messages:
    653
    Location:
    Sydney, Australia
    I certainly hope they add this functionality. Currently the browser is completely disabled on Australian Model Ss, even though by law it only needs to be disabled while driving.
     
  8. GeekLad

    GeekLad Member

    Joined:
    Apr 27, 2014
    Messages:
    63
    Location:
    Fort Lauderdale, FL
    Yeah, no traffic yet, I was just throwing something together as a proof of concept. I could even just try it on my desktop for now and pull the page up from the car via the LAN or do some port forwards outside the LAN for further testing. I'm a PHP guy, do you know if there are any good reverse websocket proxies for PHP? If not PHP, what other suggestions might you have for reverse websocket proxies?
     
  9. cryptyk

    cryptyk Member

    Joined:
    Jul 8, 2015
    Messages:
    260
    Location:
    United States
    You don't actually need to write any code for the reverse proxy. You basically just tell the web server that's serving up your PHP to accept requests on a certain path (e.g. /webproxy) and send those to a different host (e.g. http://pushbullet.com/websocketApi).

    This way the web browser gets server your php from "yourdomain.com", and it makes the websocket calls to "yourdomain.com/webproxy", so it's happy. Same domain.
    Your web server takes care of forwarding that to pushbullet.com (i.e. proxy), and also forwarding the replies from pushbullet.com back to the browser (i.e. reverse proxy).

    Most "real" web servers have configurations for reverse websocket proxies.
    Here's an example for Nginx: NGINX as a WebSocket Proxy - NGINX
    For Apache, check out: mod_proxy_wstunnel
     
  10. GeekLad

    GeekLad Member

    Joined:
    Apr 27, 2014
    Messages:
    63
    Location:
    Fort Lauderdale, FL
    I didn't realize it was as simple as that. I guess even if the target is SSL and my server/path is regular HTTP, it still shouldn't be a problem. However, I think keeping the connection open for any significant amount of time may be an issue, because a lot of hosts will terminate any long-running connections. I think Google App Engine will kill processes that run longer than a few seconds, but I may still experiment with it a bit there.
     
  11. cryptyk

    cryptyk Member

    Joined:
    Jul 8, 2015
    Messages:
    260
    Location:
    United States
    I would just spin up an EC2 instance and put the web server on it. Then you're in control of the box and it won't terminate the connections. One or two web servers is probably more than enough at any reasonable volume you'd generate.

    Also, you need to match protocols for same origin policy. You can't have https on the base page and http on the websocket, or vice-versa. Since it seems the Tesla browser isn't 100% compliant, it's worth trying, though.
     
  12. GeekLad

    GeekLad Member

    Joined:
    Apr 27, 2014
    Messages:
    63
    Location:
    Fort Lauderdale, FL
    I could connect to the remote wss://stream.pushbullet.com/websocket page via the server, but the serve up the page and websocket to the client via http. For instance, I serve up http://foo.bar/page.html that makes an unsecure websocket connection to ws://foo.bar/pushbullet (same origin). The server side code for ws://foo.bar/pushbullet proxies the connection to wss://stream.pushbullet.com/websocket.

    In the end, it'll be best to get an SSL certificate and go secure across the board. I'll probably go the route you recommended, with a small EC2 server. However, for testing I should be able to use a webhost I currently have where I don't have SSL, and use the setup described, correct?
     
  13. Rockster

    Rockster Active Member

    Joined:
    Oct 22, 2013
    Messages:
    1,005
    Location:
    McKinney, TX
    Reading this thread makes me feel like Ginger.

    image.jpg
     
  14. GeekLad

    GeekLad Member

    Joined:
    Apr 27, 2014
    Messages:
    63
    Location:
    Fort Lauderdale, FL
    Prepare for more blah blah blah blah :biggrin:

    Dealing with websockets in PHP seemed like it was going to be quite the hassle. A lot of info I was coming across about websockets seemed to be node.js implentations, so I figured I'd try it out. I've never tried node.js until now. It seems like a pretty cool platform for web development, I will probably tinker with it further.

    I set up an EC2 instance, installed node.js, and was able to set up the reverse websocket proxy without too much trouble. The page worked like a charm in the Model S browser, so it would indeed seem that the browser disallows cross-origin websockets.
     
  15. cryptyk

    cryptyk Member

    Joined:
    Jul 8, 2015
    Messages:
    260
    Location:
    United States
    Node is awesome. Do yourself a favor and learn Promises while you're learning node. It'll save you from callback hell and easier to learn the "right" way to handle callbacks early, rather than writing a bunch of callback code and refactoring it later to Promises.

    Also, use pm2 to manage the running node server. And Loggly for your logs. :)
     
  16. laurentb

    laurentb Model S Sig Perf. VIN2018

    Joined:
    Nov 9, 2012
    Messages:
    17
    Location:
    Waterloo, ON, Canada
    Thought you guys might be interested to hear that I have a Pushbullet integration up and running for my Tesla. It allows me to get all phone notifications displayed in the browser screen. It even allows me to respond to text messages and such. I've set up a few buttons with canned phrases. Works great!

    Technical details: A Google AppEngine server that monitors the Pushbullet stream via WebSocket and keeps notifications in a database until they are dismissed (on any device attached to Pushbullet). Then, a GWT interface that polls the database on the AppEngine server and displays the notification list in the browser. Dismiss or Reply events are sent to the AppEngine server and from there to the Pushbullet API. Use of the intermediate database allows me to capture notifications from the stream even when the webpage is not active.
     
  17. cytranic

    cytranic Member

    Joined:
    Aug 14, 2015
    Messages:
    74
    Location:
    FL

    Share! I would love to see notifications on my Tesla browser.
     
  18. laurentb

    laurentb Model S Sig Perf. VIN2018

    Joined:
    Nov 9, 2012
    Messages:
    17
    Location:
    Waterloo, ON, Canada
    I'd be happy to share but I'll have to think of a good way to do so. As is, the setup is a bit messy. You need an AppEngine instance with manual scaling to avoid the websocket connection timing out on you.
    Suggestions welcome...
     

Share This Page