Is this possible to set different timeout for different session in ASP.Net?
Edited
I mean that in the same page i have 2 session variable Session["ss1"] and Session["ss2"], is there possible to set timeout for each session? Or is there anyway to do the same like save session to cookie and set expire?
Sry im just new to ASP.Net
I wrote a very simple extender class that does that. You can find the source code here
Usage:
//store and expire after 5 minutes
Session.AddWithTimeout("key", "value", TimeSpan.FromMinutes(5));
Set any timeout at login time, you can set different timeout for different users...
HttpContext.Current.Session.Timeout = 540;
If you are talking about session timeout for different users then
You can use Global.asax in this you can use Session_Start event and in this event you can set session timeout differently for different users
The answer is no the session timeout applies to ALL session variables per user. You can however use the cache or a cookie which both support timeout on an individua(per key) level.
But hang on those solutions don't come without some major drawbacks. If you use the cache you lose the privacy the session provides and if you use the cookie you are constrained with file size and serialization issues.
One workaround for this is to use the cache and make sure you include the user's session id in every key you use. This way you'll end up with a cache storage that mimics the session itself.
If you want further functionality and don't want to bother about implementing this however you can use the API from this little project on CodePlex:
http://www.univar.codeplex.com
The version 2.0 offers many storage type options out of the box including a session bound cache.
/// <summary>
/// this class saves something to the Session object
/// but with an EXPIRATION TIMEOUT
/// (just like the ASP.NET Cache)
/// (c) Jitbit 2011. MIT license
/// usage sample:
/// Session.AddWithTimeout(
/// "key",
/// "value",
/// TimeSpan.FromMinutes(5));
/// </summary>
public static class SessionExtender
{
public static void AddWithTimeout(
this HttpSessionState session,
string name,
object value,
TimeSpan expireAfter)
{
session[name] = value;
session[name + "ExpDate"] = DateTime.Now.Add(expireAfter);
}
public static object GetWithTimeout(
this HttpSessionState session,
string name)
{
object value = session[name];
if (value == null) return null;
DateTime? expDate = session[name + "ExpDate"] as DateTime?;
if (expDate == null) return null;
if (expDate < DateTime.Now)
{
session.Remove(name);
session.Remove(name + "ExpDate");
return null;
}
return value;
}
}
Usage:
//store and expire after 5 minutes
Session.AddWithTimeout("key", "value", TimeSpan.FromMinutes(5));
//get the stored value
Session.GetWithTimeout("key");
by Alex. CEO, founder https://www.jitbit.com/alexblog/196-aspnet-session-caching-expiring-values/
Related
I'm building an ASP.NET MVC3 Website with EF and DB First Approach. I need to come up with a reliable mechanism for database context switching in runtime for users. I've got several databases (same schema) that are used in remote "workshops" and application users in company headquaters need to have the ability to switch between databases at any time.
First I have implemented a base controller, that had ChangeDbContext(string dbname). It was persisting selected dbName to Session, and then I was retrieving from Session in OnActionExecuting method. However it turned out to be not reliable because session behaved unpredicatble (random expiration etc.) So I'm looking a smart way to replace Session with something else.
I could use advices on :
- where to put EntityFramework object initialization (BaseController Constructor ?)
- are there any additional changes that I should do to utilize Impersonation with WindowsAuth for DB connection ?
First, you need to insure your application session can survive restarts and app pool recycles. See this
Second, you need to inject the connection string for your DBContext based on the authenticated user request.
I assume you’ve got a database full of users so what you need to do is save a list of possible connection strings in a SQL table and relate them back to their associated user accounts. Once you’ve authenticated the user you need to retrieve the connection string associated with the user account. You don't want to store your connection string in a session or any other mechanism that could potentially expose sensitive data to a web client. So in summary this what you need to do.
You will want to retrieve your connection string for each request base on the authenticated user.
Inject the connection string into your DBContext.
Make your database calls as necessary.
Money!
Injecting strings into entity is easy.
If you're using EF 4.1 Code first your DBContext would look something like this.
EF 4.1 accepts normal ADO.NET connection strings.
public class ExampleProvider : DbContext, IExampleProvider
{
private readonly string _nameOrStringConnection;
public ExampleProvider()
{
}
public ExampleProvider(string nameOrStringConnection)
: base(nameOrStringConnection)
{
_nameOrStringConnection = nameOrStringConnection;
}
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
base.OnModelCreating(modelBuilder);
modelBuilder.Entity<Example>().ToTable("example");
modelBuilder.Entity<Example>().HasKey(x => x.ExampleId);
}
public DbSet<Example> Examples { get; set; }
}
If you're using EF.edmx you will need to make sure that your injected connection string includes the edmx metadata files info like this...
..."metadata=res:///ExampleModel.csdl|res:///ExampleModel.ssdl|res://*/ExampleModel.msl;...
If you look in the edmx designer file you will see your DBContext has several constructor overloads. Use the second or third overload per your needs.
#region Contexts
/// <summary>
/// No Metadata Documentation available.
/// </summary>
public partial class Entities : ObjectContext
{
#region Constructors
/// <summary>
/// Initializes a new Entities object using the connection string found in the 'Entities' section of the application configuration file.
/// </summary>
public Entities() : base("name=Entities", "Entities")
{
this.ContextOptions.LazyLoadingEnabled = true;
OnContextCreated();
}
/// <summary>
/// Initialize a new Entities object.
/// </summary>
public Entities(string connectionString) : base(connectionString, "Entities")
{
this.ContextOptions.LazyLoadingEnabled = true;
OnContextCreated();
}
/// <summary>
/// Initialize a new Entities object.
/// </summary>
public Entities(EntityConnection connection) : base(connection, "Entities")
{
this.ContextOptions.LazyLoadingEnabled = true;
OnContextCreated();
}
#endregion
/// incomplete file
Good luck!
Cookies can be persisted for a long expiry, well longer than a session anyway. You could also look at a hidden page variable or mangled URL.
1) Sessions doesn't expire randomply...but after the time you set in the we.config...default is 10 min. Seesion MUST expire because there is no way to know that an user left our web site...so if they stop accessing pages for, say 10 min, we ASSUME, they went away...You can increase this time but the problem remain.
2) Tou can store directly the information in a cookie. Now since the cookie only waste resources on the browser (very little space), you can make the cookie persistent...so that it never expire
3) As an alternative to cookies you can store this information together with the credential information of users (login name etc.) You can use the Profile provider to define a property DBChosen.
I'm still relatively new to .NET and ASP.NET MVC, and I have had a few occasions where it would be nice to store information retrieved from the DB temporarily so it can be used on a subsequent server request from the client. I have begun using the .NET Session to store this information, keyed off of a timestamp, and then retrieve the information using the timestamp when I hit the server again.
So a basic use case:
User clicks 'Query' button to gather information from the system.
In JS, generate a timestamp of the current time, and pass this to the server with request
On server, gather information from DB
On server, use unique timestamp from client as a key into the Session to store the response object.
Return response object to client
User clicks 'Generate Report' button (will format query results into Excel doc)
Pass same timestamp from #2 down to server again, and use to gather query results from #4.
Generate report w/o additional DB hit.
This is the scheme that I have begun to use in any case where I use the Session as temporary storage. But generating a timestamp in JS isn't necessarily secure, and the whole things feels a little... unstructured. Is there an existing design pattern I can use for this, or a more streamlined/secure approach? Any help would be appreciated.
Thanks.
You may take a look at TempData which stores the data in Session.When you pull something out of TempData it will be removed after the Action is done executing.
So, if you put something in TempData in an Action, it will live in TempData across all other actions until its requested TempDatafrom TempData again.
You can also call TempData.Peek("key") which will keep it in memory until you call TempData["key"] or TempData.Remove("key")
Ok, I'm not sure I understand you correctly as the JS timestamp step seems superfluous.
But this is what I would do.
public static string SessionReportKey = "Reports";
public static string ReportIDString = "ReportID";
public Dictionary<string, object> SessionReportData
{
get
{
return Session[SessionReportKey] == null ?
new Dictionary<string, object>() :
(Dictionary<string, object>) Session[SessionReportKey];
}
set
{
Session[SessionReportKey] = value;
}
}
public ActionResult PreviewReport()
{
//retrive your data
object reportData = GetData();
//get identifier
string myGUID = new GUID().ToString();
//might only need [SessionReportData.Add(myGUID, reportData);] here
SessionReportData = SessionReportData.Add(myGUID, reportData);
//in your view make a hyperlink to PrintReport action with a
//query string of [?ReportID=<guidvalue>]
ViewBag[ReportIDString] = myGUID;
return View(reportData);
}
public FileContentResult PrintReport()
{
if(SessionReportData[QueryString[ReportIDString]] == null)
{
//error no report in session
return null;
}
return GenerateFileFromData(SessionReportData[QueryString[ReportIDString]]);
}
I'm trying to create a Caching Class to cache some objects from my pages. The purpose is to use the Caching system of the ASP.NET framework but to abstract it to separate class.
It seems that the caching doesn't persist.
Any ideas what I'm doing wrong here? Is it possible at all to cache object out side the Page it self?
EDIT: added the code:
Insert to cache
Cache c = new Cache();
c.Insert(userid.ToString(), DateTime.Now.AddSeconds(length), null, DateTime.Now.AddSeconds(length), Cache.NoSlidingExpiration,CacheItemPriority.High,null);
Get from the cache
DateTime expDeath = (DateTime)c.Get(userid.ToString())
I get null on the c.Get, even after I did have the key.
The code is in a different class than the page itself (the page uses it)
Thanks.
There are numerous ways you can store objects in ASP.NET
Page-level items -> Properties/Fields on the page which can live for the lifetime of the page lifecycle in the request.
ViewState -> Store items in serialised Base64 format which is persisted through requests using PostBack. Controls (including the page itself - it is a control) can preserve their previous state by loading it from ViewState. This gives the idea of ASP.NET pages as stateful.
HttpContext.Items -> A dictionary of items to store for the lifetime of the request.
Session -> Provides caching over multiple requests through session. The session cache mechanism actually supports multiple different modes.
InProc - Items are stored by the current process, which means should the process terminate/recycle, the session data is lost.
SqlServer - Items are serialised and stored in a SQL server database. Items must be serialisable.
StateServer - Items are serialised and stored in a separate process, the StateServer process. As with SqlServer, items must be serialisable.
Runtime - Items stored in the runtime cache will remain for the lifetime of the current application. Should the applciation get recycled/stop, the items will be lost.
What type of data are you trying to store, and how do you believe it must be persisted?
Right at the beginning of last year I wrote a blog post on a caching framework I had been writing, which allows me to do stuff like:
// Get the user.
public IUser GetUser(string username)
{
// Check the cache to find the appropriate user, if the user hasn't been loaded
// then call GetUserInternal to load the user and store in the cache for future requests.
return Cache<IUser>.Fetch(username, GetUserInternal);
}
// Get the actual implementation of the user.
private IUser GetUserInternal(string username)
{
return new User(username);
}
That was nearly a year ago, and it has been evolved a bit since then, you can read my blog post about it, let me know if thats of any use.
Your cache reference needs to be accessible to all items in your code - the same reference.
If you are newing up the Cache class every time, you are doing it wrong.
I have done almost the same things, but with a different code (and it work for me) :
(CacheKeys is an enum)
using System;
using System.Configuration;
using System.Web;
using System.IO;
public static void SetCacheValue<T>(CacheKeys key, T value)
{
RemoveCacheItem(key);
HttpRuntime.Cache.Insert(key.ToString(), value, null,
DateTime.UtcNow.AddYears(1),
System.Web.Caching.Cache.NoSlidingExpiration);
}
public static void SetCacheValue<T>(CacheKeys key, T value, DateTime expiration)
{
HttpRuntime.Cache.Insert(key.ToString(), value, null,
expiration,
System.Web.Caching.Cache.NoSlidingExpiration);
}
public static void SetCacheValue<T>(CacheKeys key, T value, TimeSpan slidingExpiration)
{
HttpRuntime.Cache.Insert(key.ToString(), value, null,
System.Web.Caching.Cache.NoAbsoluteExpiration,
slidingExpiration);
}
public static T GetCacheValue<T>(CacheKeys key)
{
try
{
T value = (T)HttpRuntime.Cache.Get(key.ToString());
if (value == null)
return default(T);
else
return value;
}
catch (NullReferenceException)
{
return default(T);
}
}
I'm using WindowsTokenRoleProvider to determine Active Directory group membership in an ASP.NET web application.
My problem is that performance is not good, especially when a user is in many groups. As an example, I am in 253(!) groups, and WindowsTokenRoleProvider is taking around 150 seconds to determine what groups I am in.
I know I can use caching so that this isn't done on subsequent requests for a user, but obviously it isn't acceptable to take that long on the first hit.
What are my options? Can I force WindowsTokenRoleProvider to only consider certain groups? (I'm only interested in 5).
Some testing has revealed that my problem is that calling:
Roles.IsUserInRole(groupName)
is accessing the method GetRolesForUser in the RoleProvider - which is retrieving details of every role the user is a member of.
But calling:
Roles.Provider.IsUserInRole(groupName)
determines whether or not the user is in the group - without retrieving the details of every role the user is in.
Weird, but it looks like using Roles.Provider.IsUserInRole will solve my problem.
* UPDATE *
It turns out that this is just a partial workaround; if I use imperative permission checks, or 'allow' and 'deny' in web.comfig, then WindowsTokenRoleProvider still goes and slowly gets details of every group the user is a member of :o(
So my question still stands...
* UPDATE *
I solved this by creating a class that extends from WindowsTokenRoleProvider and overriding GetRolesForUser so it only checks for membership of roles specified in the configuration. It includes caching too:
/// <summary>
/// Retrieve the list of roles (Windows Groups) that a user is a member of
/// </summary>
/// <remarks>
/// Note that we are checking only against each system role because calling:
/// base.GetRolesForUser(username);
/// Is _very_ slow if the user is in a lot of AD groups
/// </remarks>
/// <param name="username">The user to check membership for</param>
/// <returns>String array containing the names of the roles the user is a member of</returns>
public override string[] GetRolesForUser(string username)
{
// Will contain the list of roles that the user is a member of
List<string> roles = null;
// Create unique cache key for the user
string key = String.Concat(username, ":", base.ApplicationName);
// Get cache for current session
Cache cache = HttpContext.Current.Cache;
// Obtain cached roles for the user
if (cache[key] != null)
{
roles = new List<string>(cache[key] as string[]);
}
// Was the list of roles for the user in the cache?
if (roles == null)
{
roles = new List<string>();
// For each system role, determine if the user is a member of that role
foreach (SystemRoleElement role in WebConfigSection.Settings.SystemRoles)
{
if (base.IsUserInRole(username, role.Name))
{
roles.Add(role.Name);
}
}
// Cache the roles for 1 hour
cache.Insert(key, roles.ToArray(), null, DateTime.Now.AddHours(1), Cache.NoSlidingExpiration);
}
// Return list of roles for the user
return roles.ToArray();
}
I am wondering how the HttpContext is maintained given that the request-response nature of the web is essentially stateless.
Is an identifier being for the HttpContext object being sent as part of the __EVENTTarget / __EVENTARGUMENTS hidden fields so that the HttpRuntime class can create the HttpContext class by reading this section from the request (HttpWorkerRequest)? I don't think
Please let me know as I am trying to fill some holes in my understanding of the http pipeline and I was unable to find any information about this.
I understand something like
HttpContext.Current.Session["myKey"] = Value;
just works but if I had to do something similar in a different language (say perl), I would have to use hidden fields for the same, wouldn't I?
Thanks
-Venu
The HttpContext is recreated for each request. The HttpSession, however, is stored on the server across requests. Basically, HttpSession is a Dictionary<string, Dictionary<string, object>>. The initial key, the session id, is provided by either a cookie or a query string parameter (if using cookie-less sessions). If you use Fiddler, you'll see the ASP.NET_SessionId cookie that contains the key for that user's session.
In code:
class HttpSessionState {
private static readonly Sessions =
new Dictionary<string, Dictionary<string, object>>();
public object this(string key) {
get {
return GetCurrentUserSession()[key]
}
set {
GetCurrentUserSession()[key] = value;
}
}
private Dictionary<string, object> GetCurrentUserSession() {
var id = GetCurrentUserSessionId[]
var d = Sessions[id];
if (d == null) {
d = new Dictionary<string, object>();
Sessions[id] = d;
}
return d;
}
private string GetCurrentUserSessionId() {
return HttpContext.Current.Request.Cookies["ASP.NET_SessionId"].Value;
}
}
The real implementation also handles session timeouts, abandons, and cookieless sessions - but the basic idea is the same.
I don't think there is one answer to your question, because I don't think everything under the HttpContext umbrella works the same way. In the example you chose, session state, both the key and value are stored on the server side. The way it knows how to hook up future requests to that session state is by using a cookie that has a (totally different) key in it. When the browser makes another request, it sends this cookie with the request and the server uses it to figure out which session to map to. Once it figures it out, you've again got access to your dictionary, across responses.
So, to do it in perl, you'd want to manually create a cookie and store a unique key in it, have a server-side mapping of those unique keys to session state dictionaries, and pretty much do what I described above.