Allow send() on Cordova/non-same-origin

[s-ol]

This PR enables cookies.send() on Cordova (iOS/Android), where it was before unusable because Cookies never reached the non-origin domain $ROOT_URL, regardless of whether .send() was called or not since document.cookie referred only to the localhost:12008 "proxy" domain and the .send() request was also sent there and was unanswered.

Some notable changes:

• this.cookies now stores the cookieString; not the sanitized Value. This is necessary because after setting attributes like Path=/ in document.cookie, these attributes are not accessible by the client anymore, i.e. they do not show up in document.cookie, and therefore need to be tracked independently.
• send() passes the Cookies by URI-string because they otherwise couldn't reach the server
• if Meteor.isCordova send() reaches out to Meteor.absoluteUrl() instead of the default, which is localhost:12008 in these cases, where the server cannot reply and instead index.html is served.
• Access-Control-Allow-Origin: http://localhost:12008 and Access-Control-Allow-Credentials: true are set on the ___cookie___/set route.

The overall API remains consistent and as far as I could tell meteor test-packages agrees that nothing got hurt.

[dr-dimitru]

Hey @s-ol ,

I'd love to merge it, but I'm getting errors:

Any ideas on what may went wrong?

[s-ol]

@dr-dimitru hm, it looks like some values are being urlEncoded where they shouldn't be - or hadn't been (or they are not being urlDecoded, where they used to be).
I'm not quite sure how those test-cases work and when it occurs, I guess the changes in serialize triggered this?

[s-ol]

@dr-dimitru i just pushed a blind fix, since apparently the way i was running the tests the last time didn't work. Could you please let me know whether this passes the tests?

[dr-dimitru]

Added info about running tests to docs.

I still experiencing issues:

[dr-dimitru]

Hello @s-ol ,

I've got to reject this PR due to failed test and major (seems like unnecessary) changes in core codebase. I'm going manually implement Access-Control-Allow-Origin headers and other necessaries for Cordova.

[s-ol]

@dr-dimitru you can try implementing it yourself of course, but i think you will find out why it is necessary to change some of the internals for implementing proper cookie setting for cordova. The important thing is that cookies need to be transmitted using an XHR with xhr.withCredentials = true; and Access-Control-Allow-Credentials: true. Also the cookies need to be passed (at least on cordova) by URI string because they cannot reach the server otherwise.

[dr-dimitru]

@s-ol if we are going to send "cookies" as query string, it isn't really "cookies".
For this case you may simply setup middleware to accept query string in request and respond with Set-Cookie header. wdyt?

[dr-dimitru]

@s-ol our goal — keep this library RFC 6265 compatible

[s-ol]

For this case you may simply setup middleware to accept query string in request and respond with Set-Cookie header. wdyt?

isn't that exactly what the middleware in this PR does?

following only RFC6265 will not lead very far because the cordova-plugin-meteor-webapp completely circumvents any regular cookie behavior with its same-origin violation.
This PR is still "compatible" - nothing changed, except for the middleware you just described, that is only used where necessary (on Cordova).

[dr-dimitru]

isn't that exactly what the middleware in this PR does?

Why this should be part of this library, when it can be simply implemented on demand?
This is very "edgy" case, isn't it?

/CC @jankapunkt

[s-ol]

@dr-dimitru: no, it is the case whenever cookies are used on Cordova - i would not call this an edge case, it is one of the main intended use cases of meteor and this library: right now your package does not support all the platforms that meteor supports - and this is not mentioned in ths README. If any package includes the fix that makes cookies work on cordova - shouldn't it be the one that provides "isomorphic bulletproof cookies"?

[dr-dimitru]

Hello @s-ol please take a look on v2.4.0, curious if we accomplished everything you've requested

[s-ol]

As outlined in veliovgroup/Meteor-Files#656 (comment), there is still open issues / fixes that were part of this PR. @menelike is currently working on rebasing the missing changes onto your v2.4.0 in risetechnologies/Meteor-Files (wip/testing in progress).