Persistent sessions

[Mai-Lapyst]

Is your feature request related to a problem? Please describe. It would be very helpfull if there are persistent sessions in drogon, so for example you dont need to re-login everytime the app restarts. It also would help with load-balancing application so sessions can get syncronized across app instances via the help of a database for example.

Describe the solution you'd like Ideally, there would be a system that let's a app react on each change of a session: create, update (insert & erase), destroy.

I think the best solution would be to implement #1853 in addition with being able to access the session object itself in AdviceStartSessionCallback and AdviceDestroySessionCallback, i.e. by adding a parameter to pass SessionPtr.

If #1853 is not implemented, all of Session's mutation methods would to be changed to allow to notify any custom logic about a changed session, this change notification then maybe could be reacted to with a drogon::app().registerSessionChangeAdvice() that also gets the SessionPtr as a parameter.

Describe alternatives you've considered Only alternative right now, would to be write an custom solution for this and thus ignoring drogon's session feature completly.

[albaropereyra22]

I agree, every time I restart Drogon I have to accept cookies on my website when in real life I only want the client to accept cookies once in their lifetime for the domain.

On Mon, Jun 17, 2024, 12:31 AM Mai-Lapyst @.***> wrote:

Is your feature request related to a problem? Please describe. It would be very helpfull if there are persistent sessions in drogon, so for example you dont need to re-login everytime the app restarts. It also would help with load-balancing application so sessions can get syncronized across app instances via the help of a database for example.

Describe the solution you'd like Ideally, there would be a system that let's a app react on each change of a session: create, update (insert & erase), destroy.

I think the best solution would be to implement #1853 https://github.com/drogonframework/drogon/issues/1853 in addition with being able to access the session object itself in AdviceStartSessionCallback and AdviceDestroySessionCallback, i.e. by adding a parameter to pass SessionPtr.

If #1853 https://github.com/drogonframework/drogon/issues/1853 is not implemented, all of Session's mutation methods would to be changed to allow to notify any custom logic about a changed session, this change notification then maybe could be reacted to with a drogon::app().registerSessionChangeAdvice() that also gets the SessionPtr as a parameter.

Describe alternatives you've considered Only alternative right now, would to be write an custom solution for this and thus ignoring drogon's session feature completly.

— Reply to this email directly, view it on GitHub https://github.com/drogonframework/drogon/issues/2071, or unsubscribe https://github.com/notifications/unsubscribe-auth/BBZFRV36522ZO6UU7SBYSVTZH2GDHAVCNFSM6AAAAABJNN4V6KVHI2DSMVQWIX3LMV43ASLTON2WKOZSGM2TMNRQGQ3DKNA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[Mis1eader-dev]

I have made a library for the purpose of identifying users, keeping their session IDs, and doing database manipulations on their sessions

There's drogon-user, for identifying users in a single dimensional flat way, for example in auth applications, game servers, ungrouped chatting applications, or as a wrapper for WebSockets in general

Then there's drogon-group, which is for grouping users into multiple groups, this can be used for chatting applications where groups are present, or real-time systems for organizations and groups. But this one is less modular and you have to know some of the APIs to get it to work

My plan is to make drogon-user be similar to Facebook's auth, we'll see where it goes

[Mai-Lapyst]

@Mis1eader-dev thats nice, but I want an solution inside drogon. I also do not want any authentication or similar things, as I want to roll / use my own technology and/or stack for it. All this issue should be kept about, is to create an way inside drogon to allow an developer to persist an session. If this is done by the way I layed out, or an extra adapter that by default is a null-adapter, a file-adapter (like php) or something entirly else is irrelevant to me. I just want a way to do it on my own. Thanks.

As it is now, I'm forced to implement an session handler on my own, which I also did in my drogon-powered apps, but it would be nicer for drogon to support such a case by itself.