I'm working with an ASP.net MVC3.0 application and I keep Current User information in the Session of Current HttpContext.
As I know HttpContext.Current is for per current request.Therefore, my Session data should clear after the new request.However, I can receive Current User session data from request to request by storing HttpContext.Current. I did this sample for testing purpose to understand the session management in MVC 3.0.
My question: How I receive session data after current request ? I really appreciate your help.
public static UserAccountDto CurrentUser
{
get
{
if (HttpContext.Current == null)
return null;
if (HttpContext.Current.Session[CurrentUserSessionVariable] != null)
return HttpContext.Current.Session[CurrentUserSessionVariable] as UserAccountDto;
return null;
}
private set { HttpContext.Current.Session[CurrentUserSessionVariable] = value; }
}
HttpContext.Current is not the same as:
HttpContext.Current.Request
the last one is different at every request, the first one contains members like User, Session, Server etc that are in many (but not all) cases the same request after request.
what you have done is correct the session variable you have create will be available for all the request following the one that creates it.
The HttpContext is one of the largest object you will find in web development and behind the scene is does lots of stuff. The reason why you don’t lose the session between the requests is because the server will keep it alive. You will be surprised to know that behind the scene the session uses the particular section of the cache
Related
In spring boot application only one user should be using the certain page at a time (let's call it home.jsp). Another users should be redirected to different page(let's call it another_home.jsp) if they appear when accessing that same url. User doesn't login and just uses the application as it is. Any policy can be used for home.jsp could be first-come-first-serve or any other.
If more than one users are using application at a time only one user should be using home.html and all rest of the others should be using another_home.jsp.
As no login is needed in the application I believe I need anonymous sessions. Also, session needs to be expired after some time of inactivity. I've searched spring security but couldn't find anything.
I think that you don't even need spring security. Simple http session will work too. As far as I can see you just want to allocate the stream to one user and for that you need first user's session id which you can compare against whenever the requests come again. So store session id and expire after some timeout with some Time object or Date object.
In properties
server.servlet.session.timeout = 600 // 10 minutes
Something like this
private String currSessionId = null;
private Date lastDate = new Date();
private Integer TIMEOUT = 600000; // 10 minutes
public String loadHomePage(Model model) {
if(currSessionId!=null && new Date().getTime()- lastDate.getTime()>TIMEOUT){
currSessionId = null;
}
if(currSessionId==null){
currSessionId = session.getId();
lastDate = new Date();
return "home";
}else{
if(session.getId().equals(currSessionId)){
return "home";
}else{
return "another_home";
}
}
}
This is as simple as it gets when you don't have logged in users to manage and also don't need to remember previous state where user left off. Let me know if it helps.
You need to create a serverside state that is either empty or stores the identifier of the visitor that is currently claiming /home.jsp.
This could be a field on a singleton Bean, or an entity in the database.
It has to expire automatically, or it will prevent new visitors forever to make a claim.
As long as the state is empty, the first visitors identifier will be stored in this state.
And from that moment on, you will redirect all other visitors to another_home.jsp
So the Controllers Code would be something like this
if(visitorHoldsTheClaim()) {
return "home.jsp"
} else if (noClaimActive()) {
createClaimForVisitor();
return "home.jsp"
} else {
return "redirect:/another_home.jsp"
}
Depending on your implementation, these methods will do different things.
I'd usually recommend against serverside session state (more about this in Roy Fieldings Dissertation),
but for your use case, you need a way to identify a visitor over many requests.
A session would certainly be a very simple way to achieve this.
You can at least minimize session usage by only creating one session at a time - the one for the visitor that holds the claim.
In this case you'd never have more than one open session, and the visitor that owns the session is the visitor that holds the claim.
So in this case, the implementation would be be something like this:
if(currentUserHasASession()) { // checks if the current user has a session, but !!!does not create a new session if it does not exist!!! careful, HttpServletRequest.getSession(true) would create it!
return "home.jsp"
} else if (serverHasNoSessions()) { // https://stackoverflow.com/questions/49539076/how-can-i-get-a-list-of-all-sessions-in-spring
createSessionForUser(); // HttpServletRequest.getSession(true)
return "home.jsp"
} else {
return "redirect:/another_home.jsp"
}
Keep in mind that this only works if you do not create Sessions in another place.
So you have to configure Spring Boot/Spring Security to not create Sessions. How to make spring boot never issue session cookie?
Also keep concurrency in mind. For example, if you had only one server instance, you could put this code into a synchronized method to avoid two visitors creating a claim at the same time.
So... first of all, this sounds like a bad idea. I would be curious why you would need such an unusual behavior. There might be more sensible approaches for it.
Like Gregor said, the redirect code part is rather straightforward:
if(pageLock.getUser() == null) {
pageLock.setUser(user);
}
if(user.equals(pageLock.getUser())) {
return "home.jsp"
} else {
return "redirect:/another_home.jsp"
}
What is actually more tricky is the part when "expiring" the lock. It's likely the user will simply close the browser and not click on "logout" (or whatever), leaving the lock forever. On the other extreme, the user might be gone for a lunch break but its browser still has the page open for hours.
So that's the first thing you wanna add: some keep-alive mechanism on the page, regularly prolonging the lock, and some expiration checker, releasing the lock if nothing was received for a while.
...but like I said in the beginning, the whole thing sounds fishy.
I've been working on implementing Punchout in my eCommerce Application. My implementation works as follows.
Everything was working fine till yesterday, then the session started to getting dropped when the redirection to store front took place.
My Observation:
The HttpServletRequest object is RequestFacade before the redirection takes place, but after I redirect, it becomes ApplicationHttpRequest. I can find the RequestFacade wrapped in ApplicationHttpRequest but I cannot find the object I put in the session. Below is the function I am using to put the object in session.
/**
* Creates an object of {#link PunchoutSessionDTO} and puts it in
* the session, making it a punchout session.
*
* #param punchoutTransaction
* The {#link PunchoutTransaction} object passed from the
* {#link PunchoutStoreEntryController}.
* #param session
* The {#link HttpSession}.
*/
public void createPunchoutSession(PunchoutTransaction punchoutTransaction, HttpSession session) {
// Create a PunchoutSessionDTO object.
PunchoutSessionDTO state = new PunchoutSessionDTO();
// Initialize it with the variables from the PunchoutTransaction
// object passed to it.
state.setBrowserFormPost(punchoutTransaction.getCallbackURL());
state.setBuyerCookie(punchoutTransaction.getBuyerCookie());
state.setFromId(punchoutTransaction.getFromId());
state.setToId(punchoutTransaction.getToId());
state.setPoTransId(punchoutTransaction.getTransactionId());
state.setOciPunchout(punchoutTransaction.getTransactionType() == PunchoutTransaction.TYPE_OCI);
// And put it in the session, so that the session could be
// identified as a punchout session.
session.setAttribute("PunchoutState", state);
// Set the max inactive interval of the session to the value
// provided in the store property. If such store property is
// not found, a default of 5 minutes is used.
/*String vid = punchoutTransaction.getVendorId();
Integer timeout = PunchoutStorePropertyFactory.getTimeoutPeriod(vid);
session.setMaxInactiveInterval( (timeout == null ? 5 : timeout) * 60); */
logger.info("Punchout Session Created for " + punchoutTransaction.getBuyerCookie());
}
Everything was working fine till I decided that I should set a timeout value for the session. After this point, problem started to occur. At first, I thought that I am messing it up by passing the incorrect value for setMaxInactiveInterval(), so I commented it. To my surprise, the session was getting dropped anyway.
Please Note:
We are using Apache Tomcat on Windows 8.1.
Server version: Apache Tomcat/7.0.54
Server built: May 19 2014 10:26:15
Server number: 7.0.54.0
OS Name: Windows 8
OS Version: 6.2
Architecture: amd64
JVM Version: 1.7.0_51-b13
JVM Vendor: Oracle Corporation
We are using Spring 2.5. Yes! And we cannot migrate since this application is very huge (Over 10,000 source files).
The URL patterns *.po and *.html are mapping to the same servlet, so the redirection occurs within the same servlet.
Google Searches:
Why does HttpServletRequest object changes.
HttpServletRequest changes to ApplicationHttpRequest
HttpServletRequest to ApplicationHttpRequest
Spring ServletRequest object changing
HttpServletRequest changes after redirection
This silly mistake is pissing us off since last 3 days. Any help would be appreciated! Please point out any silly mistake I have made, and some good tips related to session handling/management are the most welcome ones. If you think that I have not included enough information, please point it out as well. Thanks :)
Yes, I am answering my own question. I wish to go in details so that future comers may find their answers.
Turns out I am an idiot who is redirecting to absolute path.
Redirection is the key.
No matter whether the servlet you are redirecting to resides on the same application server, is within the same application or it even shares the same servlet. Any request redirected to absolute paths has their own context! So the request object created for them are completely new and has their separate sessions. A session is only maintained if the redirection is being sent on the same port, host and webapp. If redirection is done within the same application, use relative paths using relative paths is the best practice.
Redirecting from https://localhost/servlet1.html to http://localhost/servlet2.html are very different, even though the URLs map to the same servlet (Please notice the difference).
Redirecting from https://localhost/servlet1.html to https://192.168.x.x/servlet2.html or https://127.0.0.1/servlet2.html would bear the same results.
The best practice here would be redirecting to paths relative to your application. This would share the session object in the most efficient way.
Using response.sendRedirect("servlet2.html"); is best thing do here (in my opinion).
Understanding the Cookies
A session is identified by the JSESSIONID cookie. If the browser forwards this cookie, then the session is forwarded to the other servlet or controller (or whatever). HTTP and HTTPs are different protocols and hence, different cookies are used. Similarly, localhost and IP addresses are different hosts for a browser, hence different cookies are used. The JSESSIONID cookie is forwarded if the protocol, host and webapp context remains the same, which however, has the same meaning as using relative paths in the redirection. Redirecting to the relative addresses could be thought of as a safe way to redirect on the same host, protocol and application context. It is the browser that decides if it is going to forward your JSESSIONID cookie or not
This is how it works, It first checks whether relative redirect available or not then it else construct absolute path.
// Generate a temporary redirect to the specified location
try {
String locationUri;
// Relative redirects require HTTP/1.1
if (getRequest().getCoyoteRequest().getSupportsRelativeRedirects() &&
getContext().getUseRelativeRedirects()) {
locationUri = location;
} else {
locationUri = toAbsolute(location);
}
setStatus(status);
setHeader("Location", locationUri);
if (getContext().getSendRedirectBody()) {
PrintWriter writer = getWriter();
writer.print(sm.getString("coyoteResponse.sendRedirect.note",
Escape.htmlElementContent(locationUri)));
flushBuffer();
}
} catch (IllegalArgumentException e) {
log.warn(sm.getString("response.sendRedirectFail", location), e);
setStatus(SC_NOT_FOUND);
}
I have the need to cache a collection of objects that is mostly static (might have changes 1x per day) that is avaliable in my ASP.NET Web API OData service. This result set is used across calls (meaning not client call specific) so it needs to be cached at the application level.
I did a bunch of searching on 'caching in Web API' but all of the results were about 'output caching'. That is not what I'm looking for here. I want to cache a 'People' collection to be reused on subsequent calls (might have a sliding expiration).
My question is, since this is still just ASP.NET, do I use traditional Application caching techniques for persisting this collection in memory, or is there something else I need to do? This collection is not directly returned to the user, but rather used as the source behind the scenes for OData queries via API calls. There is no reason for me to go out to the database on every call to get the exact same information on every call. Expiring it hourly should suffice.
Any one know how to properly cache the data in this scenario?
The solution I ended up using involved MemoryCache in the System.Runtime.Caching namespace. Here is the code that ended up working for caching my collection:
//If the data exists in cache, pull it from there, otherwise make a call to database to get the data
ObjectCache cache = MemoryCache.Default;
var peopleData = cache.Get("PeopleData") as List<People>;
if (peopleData != null)
return peopleData ;
peopleData = GetAllPeople();
CacheItemPolicy policy = new CacheItemPolicy {AbsoluteExpiration = DateTimeOffset.Now.AddMinutes(30)};
cache.Add("PeopleData", peopleData, policy);
return peopleData;
Here is another way I found using Lazy<T> to take into account locking and concurrency. Total credit goes to this post: How to deal with costly building operations using MemoryCache?
private IEnumerable<TEntity> GetFromCache<TEntity>(string key, Func<IEnumerable<TEntity>> valueFactory) where TEntity : class
{
ObjectCache cache = MemoryCache.Default;
var newValue = new Lazy<IEnumerable<TEntity>>(valueFactory);
CacheItemPolicy policy = new CacheItemPolicy { AbsoluteExpiration = DateTimeOffset.Now.AddMinutes(30) };
//The line below returns existing item or adds the new value if it doesn't exist
var value = cache.AddOrGetExisting(key, newValue, policy) as Lazy<IEnumerable<TEntity>>;
return (value ?? newValue).Value; // Lazy<T> handles the locking itself
}
Yes, output caching is not what you are looking for. You can cache the data in memory with MemoryCache for example, http://msdn.microsoft.com/en-us/library/system.runtime.caching.memorycache.aspx . However, you will lose that data if the application pool gets recycled. Another option is to use a distributed cache like AppFabric Cache or MemCache to name a few.
In the latest Meteor release (version 0.5.8), Session has been removed from the server-side code.
Previously I've used Session to store client-specific variables for the server; what is the replacement for this functionality?
Example case: User One opens a browser, User Two opens a browser. One calls a method on the server setting some token, the other calls a method on the server doing the same. I then need to access this when the client requests something. How do I differentiate between the two?
You'll want to save your tokens to a collection in the database.
You could use a Session on the server if you wanted to simply by copying the session package into your application's packages directory and changing its package.js to also load on the server. But a Session is an in-memory data structure, and so won't work if you have multiple server instances; and you wouldn't be able to restart the server without losing your user's tokens.
If you store your tokens in the database they'll persist across server restarts, and will work with a future version of Meteor which is able to scale an application by adding more server instances when needed.
If you need to expire your tokens (so that your collection doesn't grow without bound), you could add a "lastUsed" Date field to your token collection, and periodically remove tokens that haven't been used for longer than your chosen expiration period.
You can use each one's session id which is unique to the tab too. Not too sure how to get the current session id but it should be there somewhere (you can see it in Meteor.default_server.sessions, so there is still a way:
Client js
Meteor.call("test", Meteor.default_connection._lastSessionId, function(err,result) {
console.log(result);
});
Server side Js
Session = {
set : function(key, value, sessionid) {
console.log(Meteor.default_server.sessions[sessionid]);
if(!Meteor.default_server.sessions[sessionid].session_hash) Meteor.default_server.sessions[sessionid].session_hash = {};
Meteor.default_server.sessions[sessionid].session_hash.key = value;
},
get : function(key, sessionid) {
if(Meteor.default_server.sessions[sessionid].session_hash)
return Meteor.default_server.sessions[sessionid].session_hash.key;
},
equals: function(key, value, sessionid) {
return (this.get(key, sessionid) == value)
},
listAllSessionids: function() {
return _.pluck(Meteor.default_server.sessions, "id");
}
};
Meteor.methods({
test:function(sessionid) {
if(!Session.get("initial_load", sessionid)) Session.set("initial_load", new Date().getTime(), sessionid);
return Session.get("initial_load", sessionid);
}
});
I hook into Meteor.default_connection._sessions to store the values so that theres some type of garbage collection involved when the session isn't valid anymore (i.e the user has closed his tabs) to prevent memory being wasted. In livedata_server.js these old sessions get destroyed after 1 minute of no activity on the DDP wire (like the heartbeat).
Because the server can see everyone's session you can use the sessionid to access another user's session data. and listAllSessionids to give out an array of all the sessionids currently active.
Automatically set session like this.userId in a Method without using a param in a call
It looks like there is functionality for this this but its not fully hooked up. The session id would be stored in this.sessionData but its likely still unfinished. Its there to be called in method but theres nowhere that its being set yet (in livedata_connection.js & livedata_server.js)
I am using Rotativa in my MVC3 app to generate pdfs into a memory stream which is then emailed out as an email attachment. This works fine but it is quite slow (~5-7 seconds with just 1 user) so I've been trying to put it into a separate thread so the user doesn't get stuck with a huge delay.
The problem I've been facing is that Rotativa requires the Controller Context to generate the data into the memory stream, which means that if you try to put it in a separate thread and return a notification to the user then the context is disposed and the pdf generation will fail.
Unfortunately I do an email validation check on the server-side and return a true/false where appropriate, false will prompt the user to fix it and try again. This means I can't just assume that the email is always valid (I could do it by jquery, but if they turn it off and try to submit they won't get an error message).
So far I have tried:
Creating a new thread and passing the context in
Duplicating the context by copying it to a new variable
Serializing the context, passing the stream to the new thread and de-serializing (unfortunately the context is not serializable)
Has anyone got any other ideas?
Here is what I do to run a long process in the background with context. I'm using custom sessions backed by a database. You'll need to pass whatever values you need into the "background" action.
using (var client = new WebClient())
{
var values = new NameValueCollection
{
{ "sessionid", DataSession.Id.ExtractSid() }
};
client.UploadValuesAsync(new Uri(Url.AbsoluteAction("ResultsCallback", "Quote")), values);
}