Cordova / Login credentials aren't persistent

[nkoren]

Every time I re-launch a Cordova app, I have to log in again. I'm serving Meteor locally to ensure a stable port, so that's not the issue. How does one stay logged in on a mobile device?

(Tested in on Android on several devices -- haven't been able to check on iOS yet)

[jperl]

👍

[andrewreedy]

👍 Same issue on iOS

[zeroasterisk]

I'm also interested in the official recommendation on this need.

The `` Accounts.config shows a default of 90 days, but it doesn't seem to be working:

• http://docs.meteor.com/#accounts_config
• https://github.com/meteor/meteor/blob/master/packages/accounts-base/accounts_common.js#L168-171

Perhaps it needs to be stored someplace other than in localStorage?

Also, as discussed here:
https://meteorhacks.com/extending-meteor-accounts.html

you can setup your own login functionality and create tokens in your own way... but doesn't really help you much.

  // on the server...
  var stampedToken = Accounts._generateStampedLoginToken();
  var hashStampedToken = Accounts._hashStampedToken(stampedToken);

  Meteor.users.update(userId, 
    {$push: {'services.resume.loginTokens': hashStampedToken}}
  );

You can create a resume token, but I don't see how to specify where to store the token locally

[emgee3]

Just an FYI, the meteorhacks article was written for pre-0.7.2 versions of Meteor. If you look at the Meteor changelog the stamped tokens are automatically managed as of 0.7.2.

[estark37]

Meteor Phonegap apps include an embedded web server that serves the application's static files, because if they were served from disk, the application would run on a file:// origin which messes up all sorts of things (notably routing). So the port of your development server isn't what matters here; it's the port of the embedded server that is server the app's static files.

@Slava Every time you launch the app, the embedded server picks a random port, right? So we should probably save that port somewhere and always use the same one. Also, do we have logic to retry if we can't listen on the port that we choose? Maybe we should do that too.

[smari]

Hi! I've been looking at the Cordova code (specifically in the Android build folder) in search of this server, but couldn't find it anywhere. I found a few things that look like they're hitting file:// but that was in the optional plugins bit (related to Camera and such), so I figure that isn't important.

Any hints?

[Slava]

@estark37 is correct. Right now we are choosing a random port on every application start for serving files from the device. There is some retry logic in case of port collisions.

It is important to note that this design is not finalized and may change in the future. For instance, we don't know if iOS sandboxing isolates ports used by applications or not. Also we have a different design for Android in works.

In any case, the original post is a bug and it should be fixed either by patching the current mechanism or incorporating "same host and port origin" logic in the new one.

[zeroasterisk]

@smari who says that plugins isn't important?

It's the Cordova recommended way of interacting with a Cordova plugin and verifying which ones are installed... I reported that I can't find window.plugins inside my Cordova wrapped Meteor application in issue #2645.

sorry for tangenting this very important Issue's topic re: login / resume token persistence

[smari]

@zeroasterisk I didn't mean it was actually unimportant, but rather that the fact that it was plugins implied that it might not be central to the deployment, in the way that a built in HTTP server that provides all the content might be. Although tbh that assumption would get people into trouble in one of my projects. ;)

[zeroasterisk]

In more research on this, I've heard that localStorage may be un-reliable on cordova (the OS can clear localStorage) and it looks like many people complain about localStorage in general.

But it's certainly the only way (currently) that Meteor stores the login token... see here:
https://github.com/meteor/meteor/blob/611298fb50554b81a1889314ce8745b0b12b2f9d/packages/accounts-base/localstorage_token.js#L66-68

I'm now looking at localForage
Offline storage, improved. Wraps IndexedDB, WebSQL, or localStorage using a simple but powerful API.
Already packaged by good ole' @raix here:
https://github.com/raix/Meteor-localforage

Now, I wonder if I can override Meteor._localStorage...

[raix]

@zeroasterisk look at ground:store instead, its tailored meteor, localforage is the inspiration, but the groud:store is more meteor like. (Im using this in ground:db since neither meteor.localstorage nor localforage felt/worked ) it allows local async storage adapters. At the moment ive only written the localstorage adapter, but an adapter for cordova filesystem is to come (we also need this stuff on the CollectionFS project for client side storage)

[Slava]

Starting with the upcoming release 0.9.4 we use a new rewrite of the on-device server. It doesn't use a randomized port anymore and always has the same origin. Thus this is no longer an issue. Closing. Feel free to open if this is not true in the 0.9.4 world.