Aspnetcore: Session OnStart and Session OnEnd

[aspnet-hello]

_From @Tratcher on Sunday, January 7, 2018 2:41:54 PM_

_From @ErcinDedeoglu on January 7, 2018 20:59_

I came here from https://github.com/aspnet/Session/issues/20

@Tratcher @davidfowl @muratg
If you are not going to implement session onend; why we're setting the sessiontimeout?
I read all of above, but not implementing sesion onend is really strange decision. Every application uses session events. Also @Tratcher adviced that we can store data on sql not session. This is also not acceptable...

My issue is I need session start event to recognize user from its cookie to auto login. But I cant handle session start atm...

_Copied from original issue: dotnet/corefx#26212_

_Copied from original issue: aspnet/Session#206_

[aspnet-hello]

_From @Tratcher on Sunday, January 7, 2018 2:41:55 PM_

_From @karelz on January 7, 2018 21:15_

@ErcinDedeoglu what exactly do you need in CoreFX? What kind of API on which type?
AFAIK Session is ASP.NET API, not in CoreFX ...

[aspnet-hello]

_From @Tratcher on Sunday, January 7, 2018 2:46:07 PM_

The timeout is a setting provided to the cache. Because it's a distributed cache there's no observable event when the timeout expires.

Auto login? Session and authentication should not be mixed. Session is a browser session, not a user session. Can you be more specific about what you're trying to achieve?

[aspnet-hello]

_From @ErcinDedeoglu on Monday, January 8, 2018 4:13:08 AM_

Dear @Tratcher,
Migrating MVC4(old) to AspNetCore MVC.
Old system is local and not really cloud. And it'll stay as local.

Old system recognize user from Cookie (aka remember me feature) on Global.asax => Session_Start()
And assing UserID from database to System.Web.HttpContext.Current.Session["UserID"]
Later code can understand and recognize the "Browser" User from Session["UserID"].

Could you help me to solve this scenario please?

[aspnet-hello]

_From @Tratcher on Monday, January 8, 2018 10:09:28 AM_

And by local you mean it's on a single machine? We avoid features that only work on a single machine, you get locked in and can't scale.

You can do this with the auth cookie, you don't need the session cookie.
https://docs.microsoft.com/en-us/aspnet/core/security/authentication/cookie?tabs=aspnetcore2x
Not that the 'remember me' feature maps to IsPersistent
https://docs.microsoft.com/en-us/aspnet/core/security/authentication/cookie?tabs=aspnetcore2x#persistent-cookies

[aspnet-hello]

_From @ErcinDedeoglu on Tuesday, January 9, 2018 12:38:26 AM_

Thank you very much @Tratcher
Most of time you dont need to scale it. We're not programming dedicated/cloud server-side applications only.

By the way i solved it by writing code in middleware. I'm checking session on middleware and try to get cookie on it.

Also I don't want to use authentication things provided by Microsoft. In my opinion you should give free world to coder. :) Coder can solve it when needs to scale.
*By the way, before came and create issue, I searched a lot over internet about session_start/end on net core.
Ppl want it.

Thanks again 👍

[aspnet-hello]

_From @leak on Wednesday, February 7, 2018 2:00:01 PM_

I do have a use case for this: Licensing

Basically there is a floating license pool and licenses are handed out on per session basis. It cannot be done on Identity user basis otherwise customers might just use the same user everywhere. Doing this by session
allows decent user comfort, e.g. opening multiple tabs without consuming multiple user licenses, etc.

The tricky part is returning licenses back to the pool when a user just closes the browser without logging out properly and this is where Session OnEnd in conjunction with its timeout would help a lot.

This used to be part of the session system and now it isn't anymore. To me this is a step backwards.

[aspnet-hello]

_From @Tratcher on Wednesday, February 7, 2018 2:05:16 PM_

The old system's OnEnd was quite unreliable in a distributed environment, and even it couldn't detect browser close, only cache expiration. For a scenario like this you'd be better off tracking the license expiration directly. E.g. return the license if it's not used for x minutes, where x is greater than your default session timeout.

[aspnet-hello]

We periodically close 'discussion' issues that have not been updated in a long period of time.

We apologize if this causes any inconvenience. We ask that if you are still encountering an issue, please log a new issue with updated information and we will investigate.

[huazhenhz]

I could not understand why this issue was closed without any solutions?
As I know, "Sping Session" does not have the similiar problem.

The "SessionCreatedEvent" and "SessionDestroyedEvent" ("SessionDestroyedEvent" includes "SessionDeletedEvent" and "SessionExpiredEvent".) can meet the demand completely.

The reference web sites below:

https://docs.spring.io/spring-session/docs/1.3.0.RELEASE/reference/html5/#api-redisoperationssessionrepository-sessioncreatedevent

https://docs.spring.io/spring-session/docs/1.3.0.RELEASE/reference/html5/#api-redisoperationssessionrepository-sessiondestroyedevent

So I think the Same Mechanism is important for .NET developers, and it should also be provided in ASP.NET Core.

Thanks a lot!

[ErcinDedeoglu]

Please reopen the issue!

[huazhenhz]

I've reopened this issue as #3331 ...
I'll be waiting for the replies.
Many thanks.

[Tratcher]

It was closed because we do not plan on implementing this functionality.

OnStart is can easily be replaced with application code that is writing to Session.

OnEnd cannot be implemented with the current infrastructure and would not work reliably even if we tried. The first bottleneck is that Session depends on IDistributedCache for storage which has expiration but not notification. Adding notification would be a significant amount of work and may not be practical for some implementations (SQL?), not to mention it would require breaking changes we could only make in a major version.

Assuming we were able to add expiration notification to the caches, it wouldn't work very well. E.g. the event would need to fire on all nodes and would not have access to any state from an active HttpContext. Would those nodes all do the same thing and try to make the same changes to some shared resource like cleaning up a reserved resource? How would you know who the user was without the HttpContext? Do you need to provide the contents of the expired session to the event in order to facilitate cleanup? What if one node restarted and lost it's notification registration? What if all the nodes restarted?

Also note that this notification would still be based on the expiration only, you have no idea if/when the client closed their browser or otherwise lost their session cookie. They could create a whole new session long before the current one expires.

Trying to provide this functionality would be setting you up for failure.

[ErcinDedeoglu]

@Tratcher Why do you always answer? Do not you have a Microsoft developer here who can defend this thought? While session_events is used in such programming and scripting language, it is a historic mistake that it is not in .NET Core. All other language developers are stupid, are you smart?

This is unacceptable.

[Tratcher]

I am the Microsoft developer that wrote the Session implementation.

[huazhenhz]

It was closed because we do not plan on implementing this functionality.

OnStart is can easily be replaced with application code that is writing to Session.

OnEnd cannot be implemented with the current infrastructure and would not work reliably even if we tried. The first bottleneck is that Session depends on IDistributedCache for storage which has expiration but not notification. Adding notification would be a significant amount of work and may not be practical for some implementations (SQL?), not to mention it would require breaking changes we could only make in a major version.

Assuming we were able to add expiration notification to the caches, it wouldn't work very well. E.g. the event would need to fire on all nodes and would not have access to any state from an active HttpContext. Would those nodes all do the same thing and try to make the same changes to some shared resource like cleaning up a reserved resource? How would you know who the user was without the HttpContext? Do you need to provide the contents of the expired session to the event in order to facilitate cleanup? What if one node restarted and lost it's notification registration? What if all the nodes restarted?

Also note that this notification would still be based on the expiration only, you have no idea if/when the client closed their browser or otherwise lost their session cookie. They could create a whole new session long before the current one expires.

Trying to provide this functionality would be setting you up for failure.

@Tratcher
Why can Spring Session implement the mechanism very well?
Can you help to explain it?

[davidfowl]

@Tratcher I took a look at the spring docs. They basically have an abstraction that supports these events and they just don't work on certain providers.

• Redis - supports firing events (uses redis keyspace notifications https://redis.io/topics/notifications)
• JDBC (ADO.NET equivalent) - doesn't support the events
• In memory - supports firing the events

[Tratcher]

@davidfowl any interest in adding such a feature to IDistributedCache (breaking)? Otherwise we'd need to re-implement Session directly on Redis, MemoryCache, etc..

In the distributed case which node does the notification fire on? Whichever node touched the session last? And if that node is gone? Even if we did all the work to implement it, the feature would be unreliable.

[davidfowl]

@davidfowl any interest in adding such a feature to IDistributedCache (breaking)? Otherwise we'd need to re-implement Session directly on Redis, MemoryCache, etc..

Not sure yet. We could do it in a non breaking way by adding another interface for change notifications that session would use to check.

In the distributed case which node does the notification fire on? Whichever node touched the session last? And if that node is gone? Even if we did all the work to implement it, the feature would be unreliable.

I'm still trying to figure this part out. It seems like it fires on all nodes when using redis (https://github.com/spring-projects/spring-session/issues/238#issuecomment-122402529) but the feature seems to generally be unreliable across implementations. Everything I've seen about this "working" has been around redis specifically.

[lp7ishere]

I hate to harp too much on a discussed subject, and I'm new to GitHub so sorry if this is the wrong location, but I've got a use case I was previously implementing with the session end event that I'd like advice on how to implement now. I'm building a site that allows anonymous (with a session) users to upload images. However, saving the images to the server starts to take up space, so once their session expires, I'd like to trash all the images they uploaded since they're not saved long term to a user login. @Tratcher, what would be the preferred way of doing this? Timestamping last session used time to the DB and running a scheduled process to eliminate images tied to expired sessions?

[Tratcher]

@lp7ishere the correlation with Session seems unnecessary. How about letting your cleanup script delete any images more than 12 hours old, or whichever grace period you prefer?

[lp7ishere]

@Tratcher I could hypothetically clean up all images after being so old, but the idea is as long as you're willing to continue visiting the site (therefore keeping the session alive) we'll be willing to continue hosting your image.

[Tratcher]

@lp7ishere what do you set your session timeouts to?

[lp7ishere]

@lp7ishere what do you set your session timeouts to?

Currently, 24 hours, though I've considered extending it to 48.

[QuickWire]

As @leak pointed out, an OnEnd event for the session is required when returning licenses back for a session related resource. I'm fine with an in-memory session cache implementation.
Now I'm going to need to run a background task or something.