Serving from localhost causes severe problems with Cookies

[s-ol]

In it's current state, this cordova plugin serves all static page content from localhost:12008, while leaving the meteor root URL configuration set to the live deployment server ($ROOT for short).

As I understand, this is done to enable high-level caching behaviors to be implemented in native code. However the way that meteor-webapp interacts with the clientside app causes severe problems with regards to Same Origin Policy, as we have been experiencing especially with Cookies.

Since the WebView is viewing a page on the localhost:12008 origin, the clientside app doesn't have access (neither read nor write) to the Cookies that are sent to $ROOT. This has been a long standing problem with the Meteor-Files package for example (VeliovGroup/Meteor-Files#159), and could only be incompletely solved by substituting URL tokens for authentication, which opens up a lot of other issues (difference between mobile and desktop handling, token expiry concerns, security concerns if URLs are shared...).

Cookies are also a very important tool in any professional deployment setup, for example as the key client identification method for Load Balancers. In fact it is the only method that e.g. the AWS Classic LoadBalancer supports for 'Sticky Sessions'. While these cookies can be set by the remote server using the Set-Cookie header, they will only be used by direct, browser-initiated requests (e.g. img tags...) and not for XHR requests, which would become relevant at the latest e.g. when a client or network connection doesn't support WebSockets (for example behind a TCP-only corporate firewall).

It is also in general quite complicated to set up things like the CORS policy, always having to account for Cordova apps sending requests from the wrong origin. For all of these reasons, it would be a major improvement to have Cordova apps running from $ROOT as their origin as well.

I see multiple ways of accomplishing this:

• Have the localhost server proxy all non-static requests to the actual $ROOT and make it 'MITM' the real application server.
• Replace the caching mechanism with a serviceWorker. The serviceWorker by design acts as a transparent proxy and doesn't require potentially tricky configuration to hide the original $ROOT and inject static files. Not only are caching and HCP perfectly centered on what serviceWorkers have been designed to accomplish, serviceWorkers also provide a cross-platform solution that would no-longer require maintaining to separate codebases in different native languages.

[s-ol]

The only way of authenticating img requests at the moment is by sending XHR requests with withCredentials and opening at least part of the app up using Access-Control-Allow-Origin: http://localhost:12008. An example of this approach is provided and documented in the following issues and PRs:

• VeliovGroup/Meteor-Files#656
• VeliovGroup/Meteor-Files#676
• VeliovGroup/Meteor-Cookies#11

Not only does this work-around still put a lot of problems in developers hands, as every XHR the application sends needs to be configured to set withCredentials = true (which can be quite complicated to ensure with external libraries), it also opens up a security vulnerability because a malicious piece of software could be very easily written that hosts a page at that location and extracts live credentials from there.

[s-ol]

@benjamn @martijnwalraven comments?