This is indeed something that would be needed, but I’m not sure on how we would implement this within Wappler. I don’t want to include all possible stores directly, they should be optional and that is currently not possible. Also each store needs different code, we need to somehow make this dynamic, so that you can easily set it with some config options and do not need to code it yourself.
It is already possible to change the config for the sessions using the config.json, but the store needs an instance as value and this can not be set using json.
I believe you still need a persistent store(if you need persistence).
If not provided it defaults to memory store.
Yep, it’s actually a big deal for user experience.
I was just asking if it was a normal behavior to be logged out after a push.
+1 For a way to set this up or at least a guide (@JonL that test you’ve done for filesystem store, is that something that can be used with a DigitalOcean droplet?)
Btw to just handle the being logged out issue, just use a remember me options with the login so a cookie is used and next time the user is auto logged in.
Yes as DO has persistent storage.
As I normally use providers without persistent storage I had to go with a Postgres based session store.
@George When I set the ‘remember me’ with the login it indeed makes the cookie BUT when I deploy again it still forces me to log in again.
See video:
2020.09.29 23.03 - 521 - Bovine
Am I understanding you wrong George, or is it a bug?
Hello @JonL, making sessions persistent after a server restart sounds great!. Could you share a bit more on how you accomplished this to give it a try?
Thank you!
We already have the possibilities for using Redis as session store.
When you enable Redis - just as for caching, it will be used for session store as well:
Hello George, thank you for the response and the link.
I didn’t realize Redis Caching could help with session store as well.
Just to clarify, by
just as for caching, it will be used for session store as well
Are you referring to the action of -querying the db for a user’s data based on the SecurityProvider identity- being cached by Redis?
Or does “Using Redis as a session store” mean something different.
Best regards.
Hi George, pls correct me if im wrong, but I read that Redis can only be used with Docker, unfortunately I do not use docker in production since my hosting gives me Cpanel with the Nodejs implementation. I hope you can integrate it for those of us who work without docker.
What kind of session store would you prefer, what is possible with your host? Options could be using the file system or an existing database. We could perhaps also support an external redis server.
I saw you have already a half-baked knex and file store.
For now and for future I would always try to make any integration compatible with docker and externally if possible.
I am using a knex based store and I use an external database. Once redis is available externally I will swap from knex to redis. Also for the cache.
I use Docker/AWS and an external to Docker DB - am I reading the above right that the new red is cache feature will not work with this setup?
If you use Wappler’s docker deployment Redis cache should work without problems.
I don’t think I am qualified to weigh in on this, but with the recent HTML to PDF module I created, I found that the Puppeteer package cannot work on my shared hosting. So, a solution that does not require any specific packages to be present on the host, would be best.
Puppeteer is quite memory intensive that is why you probably can’t use it in a shared environment.
It makes it easy to export to pdf but it is a headless browser after all.
Nothing to do with the packages you use for session stores.
In my case, memory was not the issue. The shared hosting environment was missing packages which my hosting provider said they can’t install at this time.
I am not sure I follow. What I was trying to say is whatever approach is taken for session store, just check if it can be run on a shared hosting environment.
That would depend on the provider I guess. Not something Wappler team can anticipate by testing the myriad of shared hosting providers out there.
Did they give you a more detailed answer about why they couldn’t/wouldn’t install the package?