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.
I am currently working with the umbraco cms. I notice in the web.config references to session state.
My site will be on a web farm without a state server. Is umbraco reliant on session state? And if so, is it needed for content authoring or is it needed for content serving?
The front end doesn't use any session variables at all unless you code it to do so, so that should be OK for the content serving side of things.
I'm not 100% on the back office, but I THINK it's all done with cookies, rather than sessions. The easiest way to check would be to disable sessions in the web.config file and try and use the back office. If it works, you're OK, otherwise it does need the session to work for content editing.
I'm having a weird issue that I can't find any reference to on SO
I deploy my app to staging server daily and it has stopped behaving properly
When I Log in the address in my browser looks like so
http://x.x.x.x/(F(W24RTn2OAE25WANV8wtnrAEVS4VWP7InzD7rCS3narKQgB3F6eqHe04BLLdK2uv2RCzfrwzW5AMPbOGoN99C9aq5WMWP0_brrNTy1HD0EH1nU2G_be9gz_jXYwkZlaQDIjv4NPD-LVr9j2h2teipwjV0yPtr25wEeDrheFNaKcaHqblTFXnNZCjfTJkEJxIN0))/Controller/Action/25
If I delete the junk in there manually so that I can navigate to /Controller/Action/25 I am forced to log in again ... upon doing so I am redirected to the correct page but all that junk is back again
http://x.x.x.x/(F(W24RTn2OAE25WANV8wtnrAEVS4VWP7InzD7rCS3narKQgB3F6eqHe04BLLdK2uv2RCzfrwzW5AMPbOGoN99C9aq5WMWP0_brrNTy1HD0EH1nU2G_be9gz_jXYwkZlaQDIjv4NPD-LVr9j2h2teipwjV0yPtr25wEeDrheFNaKcaHqblTFXnNZCjfTJkEJxIN0))/Controller/Action/25
Also, it seems to be a related issue, my autocomplete textboxes no longer work... the calls never hit the DB.
Both pieces of functionality work fine locally on my IIS Express when in debug mode of the source code so I'm thinking it's the staging server IIS... but am unsure where to look to clear up this issue.. an ideas?
Here is the only thing my web.config is doing with forms authentication
<authentication mode="Forms">
<forms loginUrl="~/Account/LogOn"
timeout="2880" />
</authentication>
At login the action method is the default
FormsAuthentication.SetAuthCookie(model.Username, model.RememberMe);
This is happening on every browser on my VM and local machine both, but not on another PC. I've refreshed all browsers, deleted all cached from each browser
This does appear to be a cookie thing. In Chrome I can see the cookie when I log in to the site in debug mode in the dev tools. Using the same browser if I log in to the site pointing at the staging server there is no cookie being set.
Why would there not be a cookie being set if I am not doing anything to prevent the cookie and have deleted cache, etc?
Is forms authentication configured to not use cookies? In this case it embeds this information in the URL. This would explain why when you delete it you have to log in again.
I need to clear the IIS cache on my server. The exact reason is detailed below; but the reason doesn't matter. I'm 100% sure that this is the solution I need; as detailed below, I have used the process of elimination to determine that this is, indeed, the problem I'm facing, and the solution I need.
I have an MVC3 app that's themeable (skinnable architecture). Think of it as Wordpress; users can develop a theme, download it, and activate it on their site. The theme controls exactly the final HTML output. This is an over-simplification, since I provide an API with useful functions to be consumed by themes.
Anyway, users can change the theme of the site. The theme is currently stored in a static variable. When a view page is rendered, the name of the theme determines the location of the layout file (which contains references to the CSS files, etc.) and the view files. The theme is a setting that persists in the DB.
For example, if I have a theme called "Foo", then when requesting the /Admin page, I might use /Themes/Foo/Admin.cshtml. If I have another theme called "Bar" which does not have that file, then for /Admin it might request /Themes/Bar/Generic.cshtml as the layout.
The problem is that changing a theme means that every single page on the site is outdated. This means that any sites cached on IIS7 will show the old theme; this is incorrect. I need them to show the new theme.
Anyway, IIS7 uses caching by default. I need essentially a way to clear the cache when a user changes the theme. Currently, this is not happening, and users continue to see the old theme until the cache (somehow) expires itself.
I am not using output caching, or any other form of explicit caching; this is a "vanilla" ASP.NET MVC3 application from a caching perspective (i.e. I didn't add/configure any caching). IIS7 has its own default caching. I know this, because if I disable output caching in IIS7 for my Site, I will always see the correct theme after a change.
How can I flush the cache? Other SO questions point to using Cache.blah, and I tried using HttpContext.Current but that is null during tests (using VS test tool) -- because the ASP.NET pipeline is not used in full.
To explain, in an integration test, I basically:
Go to localhost/Test/
Log in (submit values into the forms)
Change the theme by browsing to the right page and clicking the right link
Request another page
See if the theme changed (based on the layout/css file name).
This is all done by code; I use a C# port of HtmlUnit, and along with deploying my app to /Test in IIS, I can essentially browse it like an end user.
Currently, this test passes around 50% of the time. The problem is that IIS is caching the results, and I can't cleanly reliably reset the cache on the server-side.
Again, I'm not talking about clearing the session or the user-side cache; IIS itself is the culprit guilty of caching my application. Nor do I want to completely disable the cache via the IIS settings, a) because I can't force people who install my application to do that, and b) because caching is good.
So how can I force flushing the cache on the server?
For example, I tried programatically touching web.config; this works, but recycles my application pool, and so, kills my static variables; every request means reloading all the static vars from the DB, which kills my performance.
As you requested I have amended this post:
You can use output cache, you say that the selected theme is stored in the database ( like settings for the site ) Well I would add another column with say a GUID and then use this as the varybycustom value.
Your global.asax file will be able to run code:
void Page_Init() {
///code here to get the GUIDforthissitestheme
var outputCacheSettings = new OutputCacheParameters() {
Duration = Int32.MaxValue, //think its maxvalue
VaryByCustom = GUIDforthissitestheme
};
InitOutputCache(outputCacheSettings);
}
At least here you will have output cache, but also every change of theme, changes the GUID so therefore changes the cache and then your page should be new.
I did something like this on a site that listed products, and when the products database was updated the key would be changed, however I can't find what site I implemented it and I work on a hell of a lot of sites.
hope this helps
Set up 'Cache Rule' in 'Output caching' feature with 'File Cache Monitoring' set to 'Using file change notification'. Then 'touch' the files theme change affects, from .net code you could do:
System.IO.File.SetLastWriteTimeUtc(fileName, DateTime.UtcNow);
The issues you are describing sound a lot like a client side caching issue. Have you checked this with a HTTP Proxy like Fiddler to verify if this is getting cached on the client?
If you are seeing HTTP 304's after a template change you may want to try configuring IIS (or your site template) to disable client side caching.
I dont think the approach mentioned for themes is correct.
If we are using STATIC variables , then it will affect all the users and all the pages.(Which is certainly not required.)
We can think of two approaches,
Use theme name in url and make it as a prat if RouteData. So the url "http://myHost/BLUE/.." will return in BLUE theme and "http://myHost/RED/.." will return in RED theme. If user will change theme then url will be updated.
The problem with above approach is next time user browse, it will load default theme.
So better approach will be save theme as a part of user preference. Once user logged in read the theme from DB and set the RouteData value.
Just touch web.config. That's the easiest and most reliable way. Flushing the application pool programmatically is overkill.
If you have a problem finding out where web.config is in a test environment (since System.Web.HttpRequest.Current is null, and similar for Server), you can always use an app.config file to point out the location.
Again, there's no other easy way to do it; even disabling output caching, as mentioned in the question, is hard to do through web.config alone.
I am attempting to recreate a test done by HP's WebInspect to verify a possible attack vector. In this case it tacks CrazyWWWBoard.cgi to the end of any url. In my application, when I attempt this I get the IIS 404 page and not my custom error page. Further, in the IIS Express 404, I can tell the handler is referenced as StaticFile. No controller or even routing code (I tested this by placing a empty routeconstraint on each route whose match method immediately returns true and just set a breakpoint there.) is hit. The Web.Config is basically what comes from MVC3 (except some appsettings which should have no bearing on this). I tested this without the extension (cgi) and the code behaves as expected. I am using .NET 4 extensionless urls for the rest of the application and normal behaviour works. When I use cgi, it gives IIS's 404. Do I need to replace the StaticFileHandler via the web.config?
UPDATE: In doing some further testing, the .NET components starting at Application_BeginRequest are NEVER hit. Based on my experience, this means the error pages defined in the web.config are never called. I also went back and added a .aspx extension to my controller names (i.e. http:\localhost\myapp\controller.aspx\action\test.cgi) and the url then feeds into the .NET components even with the "cgi" extension. Is this a limitation on the ASP.NET 4/MVC/IIS6 extensionless url scenario? If so is there any workarounds? I would prefer to stay extensionless but if worse comes to worst I'll return to the .aspx in my controllers. Understand that I do NOT have control over server-side setup.
Add this to the RegisterRoutes section of Global.asax.cs
routes.IgnoreRoute("{resource}.axd/{*pathInfo}"); // This one is here by default
routes.IgnoreRoute("{resource}.cgi/{*pathInfo}"); // This is your new one
// Other routes go AFTER these two as before.
And make sure you have customErrors switched on in your web.config too, which I'm sure you've already done.
I just tried it and it works (i.e. appending anything with .cgi sent me to my standard error page, without changing anything on the web server itself).
As an aside, please don't change your URLs to include .aspx on the end as that would be against the spirit of MVC! And also an attacker could merely omit the .aspx and still get the 404 page unless you implement my tiny fix.
EDIT:
What happens if you put this into your <httpHandlers> section of the web.config?
<add verb="*" path="*.cgi" type="System.Web.Mvc.MvcHttpHandler, System.Web.Mvc, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
I experienced the same thing as you are experiencing now, and this article got me where I needed to be... from haacked.com
http://haacked.com/archive/2008/11/26/asp.net-mvc-on-iis-6-walkthrough.aspx