Meteor-Files: Permission checks will fail on cordova because of wrong cookie domain

Service-side permission checks depending on cookies can not be used within cordova and will fail. Document.cookie can only access localhost as cordova connects to <content src="http://localhost:12008/"/> where the request for files with go along with the server set my meteor (--mobile-server) e.g. https://foo.bar/cdn/.... Might be wort mentioning that we use Crosswalk.

This may also be related to https://github.com/VeliovGroup/Meteor-Files/issues/97 and http://stackoverflow.com/a/36334857/1981426

Can someone reproduce this? Is this even possible to fix without a cordova plugin?

Update

On deeper inspection I can see that there is client/server handshake which deals with this issue. Still leaves https://github.com/VeliovGroup/Meteor-Files/issues/97#issuecomment-224867402 open.

Headers being sent (Chrome Browser):

Headers being sent (Cordova/Crosswalk) (Cookie is missing):

This can be reproduced if ROOT_URL !== the webpage URL e.g. ‘localhost’ !== ‘127.0.0.1’`

About this issue

Original URL
State: closed
Created 8 years ago
Comments: 62 (57 by maintainers)

Commits related to this issue

v1.7.0 - Fix memory leak caused by unsatisfied queue in `writeStream` class - New authentication model for `http` uploads based on more secure and frequently changed `connectionId` see [#159](https... — committed to veliovgroup/Meteor-Files by dr-dimitru 8 years ago
Merge pull request #193 from VeliovGroup/dev v1.7.0 - Compatibility with Meteor@1.4.1 - Fix memory leak caused by unsatisfied queue in `writeStream` class - New authentication model for `http` ... — committed to veliovgroup/Meteor-Files by dr-dimitru 8 years ago

Most upvoted comments

I think the time has come to close this issue. The proposed way to use xmtok has worked out great for us in the past and from our perspective, this issue has been fulfilled.

Thanks a lot to @dr-dimitru for all the efforts he put into this to provide a viable solution. 🚀❤️💯

menelike on Mar 28, 2018

@menelike thank you for update from your end. I’m glad we’ve found a solution to solve this issue 😃 I would like to thank everyone in this thread - ♥️ u 👨‍💻

dr-dimitru on Mar 28, 2018

@dr-dimitru to keep you in the loop; I’ve been investigating this issue the past few days. The main problem consists of these three points:

Files loaded via src attributes are losded out-of-band and therefore require seperate authentication from meteor in general. Local storage is not available for raw (GET) requests. Therefore ostrio:files falls back on cookie authentication (which is perfectly valid).
Meteor employs a caching mechanism in Cordova apps that bundles and updates the build, hosting it from localhost on a port around 12000 (hahsed from app identity). This makes offline apps easy but means that the origin host (window.location.hostname) is always localhost on Cordova. The ROOT_URL however remains the FQDN of the production server, since all assets that are not cached in the build need to be dynamically fetched from the production server. Therefore all Cookie and Set-Cookie headers are considered to be 3rd Party Cookies per definition. This is also a valid approach but flawed design IMO because it basically forces CORS issues that don’t need to exist.
The latest Cookie RFC (dont have the number handy but could provide it on request) specifies that “3rd party Cookies” may or may not be rejected by Clients and that the choice may or may not be up to the user. Before android Lollipop 3rd Party cookies had been enabled by default, but since then the policy has been changed. Cordova used to still allow 3rd party cookies up until version 5.0-ish but has dropped support in a bigger release. The underlying Android CookieManager interface [allows disabling of the cookie-stripping mechanism](https://developer.android.com/reference/android/webkit/CookieManager.html#setAcceptThirdPartyCookies(android.webkit.WebView, boolean%29) but is currently not available for configuration through Crosswalk. This is also valid, since the RFC allows it and blocking increases user privacy.

All of these together create this issue and adjusting one of the three can fix the problem.

I have created a report on the cordova JIRA but it might become a WONTFIX since the RFC doesn’t require the feature and it is arguably bad practice.

Alternatively the cordova-plugin-meteor-webapp may be modified to tunnel all requests through the local server thus unifying traffic on one host; or the cordova application can be configured to use a different caching method and talk to the production server directly.

Lastly, ostrio:files could incorporate a limited-time-token mechanism, which would complicate the package a lot. I guess it is your choice whether you want to do something to avoid this issue on your end, but I suppose it is not really in your scope for this package.

s-ol on Oct 10, 2016

@dr-dimitru sorry for the delay, I’m involved in a tough project with no spare time left

Isn’t download and display files same thing?

Display deals with transferring data and of course with permissions in this case Downloading on top of transferring tasks, this also needs to deal with filesystem restrictions which are different on cordova and browsers

It’s important to differentiate those two. After all, this project should aim on transferring/permission cases only. Therefore storing files persistently on a Cordova device should not be targeted.

https://crosswalk-project.org/apis/embeddingapidocs_v6/org/xwalk/core/XWalkCookieManager.html is not accessible from JS. I think that a simple pass trough plugin should be able to solve the cookie restrictions on Cordova/Crosswalk, though I’ve no experience with Java or Cordova plugins.

Something I’ll try as soon as I’ve some time.

menelike on Sep 5, 2016