aspnetboilerplate session timeout & redis implementation - aspnetboilerplate

I am using ABP framework with MVC 5 and deployed into Azure. I have listed few session related questions below.
I used HttpContext.Current.Session in WebMpa project and AbpSession in Application services, but unable to get the data from AbpSession using HttpContext.Current.Session in WebMpa project, both are saving data in different place?
Am using static helper class and static property to Get/Set HttpContext.Current.Session value, if i want to remove the HttpContext.Current.Session any easiest way is available(with minimal code change), it could be better if we can get AbpSession from that static class?
I want to alert users 20 secs prior to session expired, is there any build in option available in ABP?
If I enable to Redis Cache implementation in my application, Cache, HttpContext.Current.Session, AbpSession and TempData will works without any issues and all should Get/Set values from Redis datasource?

AbpSession is not extending HttpContext.Current.Session. So the answer is yes you cannot share data btw AbpSession and Session.
Don't use static for injectable types. bad practise!
There's no built-in function for that. You can achieve this with a javascript function. When you finish a request, start timer. You know the session timeout duration. So when it reaches to 20secs, show an alert window to continue session. If answer is Yes then make a new request to slide session.
No! As i stated, Session and AbpSession is totally different things and you cannot share btw them.
PS: AbpSession stores claims. And it's extendable. So you can store any item in AbpSession. See the link to understand how to extend AbpSession https://gist.github.com/hikalkan/67469e05475c2d18cb88

Related

Session object not available in WebAPI

I've got a webAPI that uses Entity Framework. I'm trying to cache some data in the session variable following along in this article:
https://msdn.microsoft.com/en-us/library/system.web.httpcontext.session(v=vs.110).aspx
I can't seem to do it though. The Session object isn't available.
In my controller, I try this:
Session["mappings"] = mappings;
...but it doesn't recognize what Session is.
I also try this:
HttpContext.Current.Session["mappings"] = mappings;
...and this:
Page.Session["mappings"] = mappings;
...but it doesn't know what HttpContext or Page are.
I'm including System.Web in my project references. I'm also including this in my web.config:
...just like this article says:
https://msdn.microsoft.com/en-us/library/ms178581(v=vs.110).aspx
...but to no avail.
My work colleague suggests it's because our webAPI is RESTful which means it's stateless, so no session object. However, we know there are ways around this. What I need is simply some way of persisting data in some kind of cache that will survive across several requests.
I also need something that will be available inside EF entities (not just the webAPI controller) is that's possible.
Does anyone know how to solve this problem? Thanks.
As your colleagues correctly suggested, an API is stateless, each request is separate and needs to have all the data required to complete the request.
You can add a caching layer however, but that is not going to be done via the Session object. Session makes no sense in an API.
Have a look here for some ideas: Caching Data in Web API

MS Access: Way to maintain persistent session across multiple Form Events?

Hopefully this is a simple question, though the solution may not be. In MS Access, is it possible to instantiate a VBA class in the application or database scope?
What I want to do is persist a WinHttp instance with the same lifetime as the application or database so that as various Form Event handlers call a web service, they can do so using a persistent session object.
If not, it seems like I'll always need to grab and persist the session state, particularly the JSESSIONID, before the current instance goes out of scope and then quietly put it back on the next instantiation. This is coming up because I really can't afford the authentication overhead on the client or the server.
What would be the recommended way to maintain a physical or virtual persistent session across multiple Form Events?
Yes, this certainly is possible. Just dim it in a module outside of any sub or function (without the New keyword)
Public winHttpObj As Object
Public Sub CreateWinHttpObj
Set winHttpObj = CreateObject("WinHttp.WinHttpRequest.5.1")
End Sub
You can refer to it from the same module, or from any other module by using the ModuleName.Variablename notation
If it's desirable is a whole different question.

Sessions in Meteor

After a research it seems that Meteor Sessions are reset after refreshing page or opening the website in new tab, i.e. they are not usual server-side sessions but something like global javascript variables on client-side. Some people advice to use AmplifyJS, but I'm not sure that it will work like usual session in other frameworks/languages and also it is a third party library, so is there any normal way to use sessions in Meteor, i.e. keep user-specific data on server?
At this moment I'm handling that by using custom Collections, but it is not an ideal way of doing that because it is needed to remove expired values from Collection manually, which makes additional troubles.
Yes this is correct. Despite the name Session is nothing like a cookie, but just a reactive form of a variable stored in a hashmap
To keep data persistent across tabs you need to use a Collections (as this is the only way to reactively share data across tabs) - Cookies can't work because they can't be made reactive as data needs to be sent to the server to notify the client when there is a change. There really wouldn't be another way at the moment as the publish/subscribe methods can only send down data from collections at the moment.
You can use your setup you have now with your custom collection. You can use a server side cron job to remove expired data (either with Meteor.setInterval or Tom Coleman's cron.
There is a package developed just for that: https://atmospherejs.com/u2622/persistent-session
After installation you can use the following functions to set sessions which are persistent:
//store a persistent session variable which is stored across templates
Session.setPersistent(key, value);
//same as above, but automatically deletes session data when user logs out
Session.setAuth(key, value);
I've tried the package and it works like charm.

AppFabric Server cache returns dll object with null values

I'm new with AppFabric Server caching but after playing around with it everything has been working like a dream.
I can add for example datatables to my cache and get that back to use just fine.
I got exited about this functionality and tried to test this with one 3rd party vendors dll that includes login session data (session id, date's etc.)
I created WCF service with method where you consume this dll to login and I store that session to my cache.
This works just fine and I can verify this by looking at statistics of my cache with PowerShell.
Then I created another method that is supposed to pick up this cached session and use it to execute actions. This is where I'm running to the wall.
I can see that I have been able to get session from cache, but information within session object is null (session id, date's...)
I've been serching help for this from everywhere but nobody seams to face this issue.
So my question is
Can AppFabric server cache ALL field values of given object (Public/Non-public not having any role)?
Is there any way to see actual existing content of cache where you would see keys and cached objects with values?
Thanks for all possible comments!
Regards
Mikko
In AppFabric you can only cache objects that are serialisable (or serializable for US readers :-) ). The fact that you have been able to store your session objects in the cache suggests that they are indeed serialisable. But to figure out what's going on here we'll need to probe a little deeper.
By default with binary serialisation, all fields/properties of an object are serialised, public and private (whereas XML serialisation only picks up the public values). We aren't told which flavour of serialisation AppFabric uses, but binary serialisation tends to be more efficient so it's a reasonable assumption that that's what gets used under the covers. However, it's possible to override the serialisation behaviour using the NonSerialized attribute, so that items marked NonSerialized don't make it into the serialised version of the object. The MSDN page for Selective Serialisation specifically advises that security-sensitive information should be marked as nonserializable.
A session ID definitely comes under the heading of security-sensitive information as it's key for session hijacking, so I should say that's the problem you're facing. You could confirm this by having a look inside the 3rd party DLL with ILDasm or Reflector to see if the fields inside the session class are indeed marked as not serialised.
Can you get round this? Well there is, of course, nothing to stop you creating your own Session class that you populate from the 3rd party's object where you keep all the properties serialisable and caching that instead. Bear in mind, however, that you're then essentially doing the very thing they've tried to stop you doing...

Using Session Vars in a MVC Domain Model library

I have a IQueryable function. In that function, I need to store and retrieve data to Session; can you guys point me in the right direction.
I've looked at the HttpSessionStatBase where the session is usually taken from HttpContext.Current but this doesnt seem possible to do in the library. Am I missing something?
Thanks in advance.
I would avoid having a dependency on the static HttpContext. My preferred strategy would be to extract the information from the session in the controller and pass it as parameters (or set as properties) on your data access layer/repository. If you feel that you must use the Session directly, then I would provide it to the DAL/repository in the same manner -- as a property or as a parameter. Note, however, that you are increasing the coupling between your DAL/repository and the controller. This will make it much more difficult to re-use in a non-web setting, i.e., you'd have to create a fake session just to interact with the DAL/repository if you ever needed to work with it from a windows service or console app, for example.

Resources