File based session storage

[krokite]

Hi, I see "iris" is back up with v8.x . Congratulation to team and @hiveminded

Does Iris / get-ion supports file based session ? Memory based session and database sessions are not optimal requirement for scaling up.

If it's not already there, is it hard to implement them ? Please share some light so that , i can try implementing them.

Thanks

Reference: get-ion/issues-v1#8

[corebreaker]

Hello @krokite.

It's a good idea.
No it's not hard to implement, you can do it easily if you.
I could also do it this Saturday.

[kataras]

@krokite Thanks, actually it's very easy to make a session database for our session manager. We already had an implementation of this at kataras/go-sessions, I pushed it here with some minor fixes but I didn't test it on different operating systems, I let this to you, upgrade with go get -u github.com/kataras/iris.

@corebreaker and @hiveminded Please test this and push any improvements if necessary.

[kataras]

Example: https://github.com/kataras/iris/blob/master/_examples/sessions/database/file/main.go (upgrade your local iris again, it should work now, please test it)

[corebreaker]

I tested with the example:

• Get: ok
• Set: ok
• Clear: ok in memory cache but not persisted in DB (file), a restart of the server, then a /get and we see the value again
• Destroy: ok in memory, a new session ID is sent to browser, but the file is not removed

[corebreaker]

Someone could confirm the result of my tests ?

[kataras]

Hello @corebreaker , on Destroy it shouldn't send a new session id to the browser, is this an expected behavior?

About the destroy, it doesn't work on any database because it doesn't update the database if len(store) == 0, I'll update the code and change the database interface a little, I will try to improve your last changes if that's ok with you.

[corebreaker]

Hello @kataras, it's ok for me.

Concerning the session ID, you are right the destroy doesn't send a new session ID, but i meant, in my test, after i done the destroy, then i refreshed the browser, a new session id wasn't sent. Maybe it's due to the file isn't removed after a destroy. I think your changes will make that the session will be invalidated by a destroy and so the browser refresh will order a new session ID.