If I'm scaling the web app server horizontally with trying to avoid using sessions, but I need to use TempData with RedirectToAction. TempData uses sessions for 1 round trip. Does the RedirectToAction go to the browser then back to the server or it redirects internally?
Reason for question, I may loose the session if the redirect hits another server instead of the original server the session was created on.
The RedirectToAction just issues a response redirect to the browser so yes it does do a round trip so you do risk losing your session (unless you use a session aware load balancer).
Related
given the nature of the project, I need to store a simple object (with 3/4 properties) in TempData. It is a read once write once so that's fine but does need to be passed between a few core methods/actions.
question is: How can I make it work with webfarms? What things are needed to be configured to allow TempData to work with a webfarm?
using MVC 4 Razor.
thank you
By default, TempData is implemented using Sessions, so this would be a problem on a farm.
The easiest solution would be to use the CookieTempDataProvider
TempData is stored in the session. This means that the only reliable way to use it in a web farm would be to have a state server of some sort.
Changing the ApplicationId (MachineKey) on all the servers to make them match does nothing for session. That only means that each server can decode the cookies left by the others. Session lives on the individual web server in memory.
If you don't have sticky sessions on your load balancer, the request that populates TempData on server 1, will likely redirect to a server different than itself and TempData will not be populated (or not with the same data that was just put in on server 1).
How can i expire a session when the system sits idle for some time. After completing that time it should be redirected to login page. I need to do this controller side. I am using asp.net mvc3 application.
The session will expire on the server when it times out.
If you want the browser to redirect at the same time you'd have to have a counter on the client, in JavaScript, which on 0 would do a redirect to your login page.
The controller cannot force the redirect of a browser without some action from the client. You could also look at having some kind of persistant connection like SignalR but that might be more than you need.
Another solution would be to have a refresh header like in this answer
ASP.NET Push Redirect on Session Timeout
I have a single ASP.NET MVC app which uses areas to deliver different functionality depending which url is hit. For example
www.domain.com - Website Area
app.domain.com - Application Area
*.domain.com - Client Area
So, the point is that depending on the incoming url, we route you to a different MVC Area. This is all done using Routing with some extensions and works great.
Now, if I enable outputcache on the Index() Action for my www default route, the next time i hit app.domain.com, i get the cached version of the www domain. I checked using fiddler and the response is a 200 OK so it's definately hitting the server. However, the logging in my custom routing tells me it's not hitting that code.
So, does OutputCache not work based off the uri and instead uses some other algorithm?
Thanks
[OutputCache(VaryByHeader="Host")] should help.
The behavior will depend on where you decided to store the cache (Location property). Ifv you stored the cache on the server (OutputCacheLocation.Server) then the result from the execution of the action will be stored on the server and when a subsequent request is made to this action, the server will be hit and it will directly return the cached version without executing the controller action which is the behavior you describe.
If you store the cache on the client (OutputCacheLocation.Client), then the cache will be kept on the client browser. In this case if a subsequent request is made to the same action, the client will no longer hit the server but will directly serve the page from its cache. And remember that if you hit F5 in your browser you will expire the cache for the given page, so the server will be hit.
I have an ASP.NET MVC 3 application. The site involves people writing lengthy responses using a textarea in a web form. Occasionally, users are complaining that they are getting redirected to the log in form after they post their data. I am not sure exactly why they are getting logged out because the users do not typically provide enough information on their errors. I believe it is due either to a session time out or the application has been restarted for some reason. This is on a shared web hosting site and it does not have its own app pool.
In any case, regardless of the reason, I would like to capture that post data and save it to a db or text file. How can I get the post data and save it while the controller redirects the user to the login screen.
I know the long term plan would be to identify why the timeout is occurring. But for now I want to be able to grab the post data and recover it at a later time.
First, in order to avoid timeouts, I would recommend using client-side heartbeat solution (like http://plugins.jquery.com/project/Heartbeat)
Second, assuming that you are using forms authentication, in order to save posted data, when Forms Authorization Module is redirecting your users, you will need to intercept redirects in EndRequest HttpApplication event handler in Global.asax or your own module.
The way to intercept those requests is not that straightforward, since on "EndRequest" pipeline step you will see 302 HTTP status code (redirect instruction), not 401 (Unauthorized error). So you may check if request is not authenticated (HttpContext.User.Identity.IsAuthenticated) and request is redirected - in this case you may save what you see in the request.
Otherwise you would need to disable forms authentication and use some solution, which is closer to ASP.NET MVC.
one solution can be to put a javasscript timer which keeps on hitting the server after specified interval to keep session alive until u figure out the cause of session time out (only i its the session timeout problem)
If you want to stop the session from timing out, you can add a hidden iframe on the page. For example, create a new page called KeepSessionAlive and do this:
<meta http-equiv="refresh" content="600">
where content = seconds.
I don't know about MVC 3, but the way you can get and store the post values is to catch them before redirecting the user to the Login page.
I'm an old hand at C but a raw newbie at Java/Tomcat.
I'm fine with Tomcat session management in http alone. Its when I've come to look at switching to https that I've had problems.
I gather for Tomcat that you have to start with an http session if you want to maintain a session as you switch from http to https and back to http. This works fine for me when the browser is enabled for cookies.
But when the browser is disabled for cookies (and URL rewriting is being used) then switching http to https or back again causes a fresh session to be started each time. I'm assuming this is a security thing.
Q1 - Is it possible/desirable to maintain a session between http and https using URL rewriting?
Q2 - If it isnt possible then what do e-commerce developers do about non-cookie users?
I dont want to prevent non-cookie people using my site. I do want some flexibility switching between http and https.
thanks for any help,
Steven.
It doesn't seem desirable to maintain session between HTTP and HTTPS using the same cookie or URL token.
Imagine the case where you're user is logged on, with a given cookie (or URL token) passed back and forth for every request/response in an e-commerce website. If someone in the middle is able to read that cookie, he can then log on to the HTTP or HTTPS variant of the site with it. Even if whatever the legitimate user is then doing is over HTTPS, the attacker will still be able to access that session (because he too will have the legitimate cookie). He could see pages like the cart, the payment method, perhaps change the delivery address.
It makes sense to pass some form of token between the HTTP session and the HTTPS session (if you're using sessions), but treating them as one and the same would cause some vulnerability. Creating a one-off token in the query parameter just the transition could be a solution. You should however treat them as two separate authenticated sessions.
This vulnerability can happen sometimes with websites that use mixed HTTP and HTTPS content (certain browsers such as Firefox will give you a warning when that happens, although most people tend to disable it the first time it pops up). You could have your HTTPS session cookie for the main page, but that page contains images for the company logo, over plain HTTP. Unfortunately, the browser would send the cookie for both (so the attacker would be able the cookie then). I've seen it happen, even if the image in question wasn't even there (the browser would send the request with the cookie to the server, even if it returned a 404 not found).