In my ASP.NET MVC 3 application, I have a timer which executes a controller action every period of time. This way my session is never timed out...
I don't want this action to reset the session timer every time it is executed. I tried to do this by creating a custom attribute [AllowAnonymous] like this link
http://blogs.msdn.com/b/rickandy/archive/2011/05/02/securing-your-asp-net-mvc-3-application.aspx
but this way, any user will be able to access this action without logging in, and that's not what I want.
Any ideas ?
You could disable sliding expiration for the session in your web.config:
<forms slidingExpiration="false" loginUrl="~/Account/LogOn" timeout="2800" />
This way the forms authentication cookie won't be renewed and the ticket will be valid only for a fixed amount of time.
And if you wanted to disable sliding expiration only for certain requests you may take a look at the following answer. It's a bit hacky because the ticket renewal code is buried deep into the FormsAuthenticationModule.
How about creating a different application that accessed through a subdomain? I think this is not only the easiest but also cleanest way to do this.
If you use any other way and another developer needs to support it later, the cost of doing it will probably be higher depending on the complexity of the solution if they need to change it somehow.
Related
I am using Spring-ROO as well as Spring security for my web application. I have set the session-timeout as 10. On closing the browser, the session is not getting closed automatically. Can anyone tell any method to close the session when the browser is closed?
Is there any configuration available to have this settings?
Please note that I cant use jquery/javascript.
I don't think this is possible, as no OnBrowserClosed event exists. The only thing that gets close is the non-standard window.onunload DOM event, which you could catch, but that would mean having custom logic run whenever you navigate from one page to another, and even then I don't think you can access the URL the user is going to next, which would be required to know that the user is actually going away from your site (something like null meaning that he goes to no site at all).
One think you could do is to set the timeout even shorter and have a JavaScript on every page that pings the server in regular short intervals using AJAX, but that's a dirty hack, and it would lock out anyone who has JS turned off. A clean solution is not possible IMHO.
So I have a framework we've built on codeigniter. It uses regular codeigniter sessions by default which allows up to 4kb storage encrypted on a cookie.
Its for general apps that require a registration process, which can vary in size as questions are generated dynamically through an admin panel. Registration process relies on session data as it redirects throughout process.
I have used db_sessions in the past when I knew this would be an issue on the framework, however, I'm now considering the possibility to always have registration process using db_session and the rest of the site use the 4kb cookie session.
Is this possible. It seems like it could be a really bad idea, but I don't really want to rework the dynamic registration process or really use db_session for whole site as it will eventually make the site run very slow if too many users are online at once.
so I'm think I can just set the variable in config to be true only when the registration controller is loaded(by checking the url via $_SERVER or the uri helper if I can load it in the config which I'm guessing I cant).
Does this seem plausible?
It seems like it could be a really bad idea
You answered your own question :) You'll have issues when the user switches from one page to another. What happens if they open multiple windows, press a 'back' button etc. You'll need to switch the cookie over when they start registration, and switch it back at the end. It will be very very messy for basically no gain.
but I don't really want to rework the dynamic registration process or
really use db_session for whole site as it will eventually make the
site run very slow if too many users are online at once.
The reality is; your website has to be huge to have ANY real performance issues by using a DB for your sessions. Any if you are not using the DB, then you are relying on the cookie stored on the users computer. Depending on your site, this means they might have the ability to edit that cookie and change "admin = true" or something.
Just use the DB session - I think you are overcomplicating the situation.
I am using rails 3.0 and ruby 1.8.7
How could detect if the user refresh the browser page?
I am coding a web wizard form, so I go to next step if all is valid. However if the user refresh the page i don't want go to next step.
Update
I put a hidden field (I know about session solution) which is updated when the user submit the form. My problem is that the form has many steps.
Any idea?. Excuse me
Thanks in advance
Actually server shouldn't know anything about client's state, that's what REST was designed for.
If you really need it, you can use the flash object in order to detect when user refresh page.
For this purpose you need that the entry point of the page will be a redirect_to, so it makes things a little bit complicated, but at least it will solve your problem.
I'm having trouble finding any info on this, which makes me think I'm doing something wrong. I've made an ashx that serves up secured images to our logged-in users. The problem is that a Sql Profiler trace reveals that TempResetTimeout is called in our Session State DB for every image served via this mechanism. This ashx was built to replace an aspx that used to do the same thing but was causing many session state db deadlocks due to many images and web garden usage, yada, yada. This is definitely an improvement, due to one less "Read Committed" call to session state db, but the fact that there's an update means we can still have some deadlocks. Basically, we want NO session interaction at all from the use of this ashx, but that doesn't seem to be happening.
I certainly don't have the IRequiresSessionState interface implemented, so I am led to believe that my ashx should not touch Session in any way. I see Global.asax hit for every occurrence however, and Global.asax references session in some of its code. This led me to try to exclude this particular page from any sort of authentication via the following in web.config...
<location path="ImageHandler.ashx">
<system.web>
<authentication mode="None" />
</system.web>
</location>
...but this causes the ashx to not fire at all (no image displayed and no breakpoint hit in ProcessRequest). I'm not sure why that is happening.
How can I get my ashx ImageHandler to not touch session AT ALL?
SessionState is set up on an Application level, so the only way to disable session for any ASP.NET request is to put it in its own Application in IIS and turn session state off.
<system.web>
<sessionState mode="Off" />
</system.web>
http://msdn.microsoft.com/en-us/library/h6bb9cz9.aspx
You could also create your own session state module (perhaps trying to wrap the existing one), but that also would either require IIS configuration to set up another folder as an Application, or replacing it on your root application.
http://msdn.microsoft.com/en-us/library/system.web.sessionstate.sessionstatemodule.aspx
Though that just seems like a lot more effort than just turning it off for one subfolder that's configured as an Application in IIS.
What is the requirement for the browser to show the ubiquitous "this page has expired" message when the user hits the back button?
What are some user-friendly ways to prevent the user from using the back button in a webapp?
Well, by default whenever you're dealing with a form POST, and then the user hits back and then refresh then they'll see the message indicating that the browser is resubmitting data. But if the page is set to expire immediately then they won't even have to hit refresh and they'll see the page has expired message when they hit back.
To avoid both messages there are a couple things to try:
1) Use a form GET instead. It depends on what you're doing but this isn't always a good solution as there are still size restrictions on a GET request. And the information is passed along in the querystring which isn't the most secure of options.
-- or --
2) Perform a server-side redirect to a different page after the form POST.
Looks like a similar question was answered here:
Redirect with a 303 after POST to avoid "Webpage has expired": Will it work if there are more bytes than a GET request can handle?
As a third option one could prevent a user from going back in their browser at all. The only time I've felt a need to do this was to prevent them from doing something stupid such as paying twice. Although there are better server-side methods to handle that. If your site uses sessions then you can prevent them from paying twice by first disabling cache on the checkout page and setting it expire immediately. And then you can utilize a flag of some sort stored in a session which will actually change the behavior of the page if you go back to it.
you need to set pragma-cache control option in HTTP headers:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9
However, from the usability point of view, this is discouraged approach to the matter. I strongly encourage you to look for other options.
ps: as proposed by Steve, redirection via GET is the proper way (or check page movement with JS).
Try using the following code in the Page_Load
Response.Cache.SetCacheability(HttpCacheability.Private)
use one of the following before session_start:
session_cache_expire(60); // in minutes
ini_set('session.cache_limiter', 'private');
/Note:
Language is PHP
I'm not sure if this is standard practice, but I typically solve this issue by not sending a Vary header for IE only. In Apache, you can put the following in httpd.conf:
BrowserMatch MSIE force-no-vary
According to the RFC:
The Vary field value indicates the set
of request-header fields that fully
determines, while the response is
fresh, whether a cache is permitted to
use the response to reply to a
subsequent request without
revalidation.
The practical effect is that when you go "back" to a POST, IE simply gets the page from the history cache. No request at all goes to the server side. I can see this clearly in HTTPWatch.
I would be interested to hear potential bad side-effects of this approach.