Cache credentials so they don't need to be input every run

[edmundmok]

Cache credentials so they don't need to be input every run

[ipwnponies]

If we need to store the user's credentials to relogin, we can store in the OS keystore using keyring package. Seems like this is the correct approach that avoids rolling our own solution.

[ipwnponies]

The session cookie has a TTL of 24 hours. This feature would be useful for reinvoking adhoc.

But as a scheduled task, the current logic of login every time scheduler goes off (to get fresh session cookie) would be necessary

Edit: But how does a browser keep indefinitely logged in? Maybe stale session in cookie still works to get a refreshed one, we're set. If not, we can try periodically querying site to keep session alive.

[ipwnponies]

From #16 (comment), a possible different solution for this issue:

There are three cookies returned on login: __cfduid, tt_visitor_id and _mealpal_session. The first two expire in 2020 (exactly 1 year from now), and the last one doesn't have an expiry. Whichever it is, it looks like we won't have to worry about cookies expiring. You can inspect MealPal(...).cookies after login to check the cookies, or use Chrome Dev tools.

We might be able to persist the cookie, in place of credentials. If we store it in config.yaml or keyring, this will persist for a year, for both adhoc runs and scheduled batch.

[edmundmok]

The cookies are all contained in .cookies of a MealPal object after .login is successful, which is of type requests.cookies.RequestsCookieJar. Not too sure about the security aspect of this but we can just pickle the cookie jar object to be stored as a binary file locally, and unpickle it again when we need it. With this, I don't think we will need keyring anymore?

[ipwnponies]

I agree, with persisted cookies we can avoid using keyring altogether.

It looks to be FileCookieJar, from stdlib, is passed to the requests session and that is has support for serializing to disk.