Does somebody know a way of checking if the current request its URL is targeted to a controller its index page?
In my application I have about 30 controllers with each an index page. I have an ActionFilter which sets a cookie on each request in its OnActionExecuting event. However I want it to be set only when the user visits an index page. I'm aware that all of the following URL's will return the index;
http://xxxx/controllerName/index
http://xxxx/controllerName/
http://xxxx/controllerName
Anyone know the best way of checking this?
Before anyone asks, the ActionFilter I'm using is the following:
public class RefreshDetectFilter : IActionFilter
{
public void OnActionExecuting(ActionExecutingContext filterContext)
{
var cookie = filterContext.HttpContext.Request.Cookies["RefreshFilter"];
filterContext.RouteData.Values["IsRefreshed"] = cookie != null && cookie.Value == filterContext.HttpContext.Request.Url.ToString();
}
public void OnActionExecuted(ActionExecutedContext filterContext)
{
filterContext.HttpContext.Response.SetCookie(new HttpCookie("RefreshFilter", filterContext.HttpContext.Request.Url.ToString()));
}
}
Kind regards and thanks in advance,
Yannick
You can get the current Action like this, regardless of the URL containing the action name or not:
filterContext.RouteData.Values["action"]
Related
I am trying to create an ActionFilterAttribute that runs only once per request, so I am doing something like this.
public override void OnActionExecuting(ActionExecutingContext filterContext)
{
if (filterContext.IsChildAction)
return;
// More stuff here
}
I might need to check that filterContext.HttpContext.Request.IsAjaxRequest() is also false in some cases, but my real problem is how to tell that it is not a redirect. When action X redirects to action Y, then the filter runs twice once for X and once for Y (the IsChildAction is false for Y).
I tried to save some key on filterContext.HttpContext.Items, that will tell me that the filter has already run, but these items are not shared between X and Y.
Any ideas how I can tell from the ActionExecutingContext that this is a redirect?
I believe something like this is what you are looking for:
Using an MVC Action Filter to catch redirects in Ajax requests and return a JsonResult
You can check if it is a redirect result or a redirect to route result
var redirectResult = filterContext.Result as RedirectResult;
if (filterContext.Result is RedirectResult)
{
// It was a RedirectResult => do something
}
else if (filterContext.Result is RedirectToRouteResult)
{
// It was a RedirectToRouteResult => do something
}
On my controller I have it inherit a MainController and there I override the Initialize and the OnActionExecuting.
Here I see what is the URL and by that I can check what Client is it, but I learned that for every Method called, this is fired up again and again, even a simple redirectToAction will fire the Initialization of the same controller.
Is there a better technique to avoid this repetition of database call? I'm using Entity Framework, so it will take no time to call the DB as it has the result in cache already, but ... just to know if there is a better technique now in MVC3 rather that host the variables in a Session Variable
sample code
public class MyController : MainController
{
public ActionResult Index()
{
return View();
}
}
public class MainController : Controller
{
public OS_Clients currentClient { get; set; }
protected override void Initialize(System.Web.Routing.RequestContext requestContext)
{
// get URL Info
string url = requestContext.HttpContext.Request.Url.AbsoluteUri;
string action = requestContext.RouteData.GetRequiredString("action");
string controller = requestContext.RouteData.GetRequiredString("controller");
object _clientUrl = requestContext.RouteData.Values["cliurl"];
if (_clientUrl != null && _clientUrl.ToString() != "none")
{
// Fill up variables
this.currrentClient = db.FindClientById(_clientUrl.ToString());
}
base.Initialize(requestContext);
}
protected override void OnActionExecuting(ActionExecutingContext filterContext)
{
// based on client and other variables, redirect to Disable or Login Actions
// ... more code here like:
// filterContext.Result = RedirectToAction("Login", "My");
base.OnActionExecuting(filterContext);
}
}
is it still best to do as:
public OS_Clients currentClient {
get {
OS_Clients _currentClient = null;
if (Session["CurrentClient"] != null)
_currentClient = (OS_Clients)Session["CurrentClient"];
return _currentClient;
}
set {
Session["CurrentClient"] = value;
}
}
It seems that you dealing with application security in that case I would suggest to create Authorization filter, which comes much early into the action. You can put your permission checking code over there and the framework will automatically redirect the user to login page if the permission does not meet AuthorizeCore.
Next, if the user has permission you can use the HttpContext.Items as a request level cache. And then you can create another ActionFilter and in action executing or you can use the base controller to get the user from the Httpcontext.items and assign it to controller property.
If you are using asp.net mvc 3 then you can use the GlobalFilters to register the above mentioned filters instead of decorating each controller.
Hope that helps.
In your base controller, you need to cache the result of the first call in a Session variable.
This makes sure the back-end (DB) is not called unnecessarily, and that the data is bound to the user's Session instead of shared across users, as would be the case with the Application Cache.
I am implementing a CustomAuthorizeAttribute. I need to get the name of the action being executed. How can i get the name of current action name getting executed in the AuthorizeCore function which i am overriding ?
If you're using cache (or have plans to), then overriding AuthorizeCore, like Darin Dimitrov shows in this answer is a much safer bet:
protected override bool AuthorizeCore(HttpContextBase httpContext)
{
var routeData = httpContext.Request.RequestContext.RouteData;
var controller = routeData.GetRequiredString("controller");
var action = routeData.GetRequiredString("action");
...
}
The reason for this is documented in the MVC source code itself:
AuthorizeAttribute.cs (lines 72-101)
public virtual void OnAuthorization(AuthorizationContext filterContext) {
if (filterContext == null) {
throw new ArgumentNullException("filterContext");
}
if (OutputCacheAttribute.IsChildActionCacheActive(filterContext)) {
// If a child action cache block is active, we need to fail immediately, even if authorization
// would have succeeded. The reason is that there's no way to hook a callback to rerun
// authorization before the fragment is served from the cache, so we can't guarantee that this
// filter will be re-run on subsequent requests.
throw new InvalidOperationException(MvcResources.AuthorizeAttribute_CannotUseWithinChildActionCache);
}
if (AuthorizeCore(filterContext.HttpContext)) {
// ** IMPORTANT **
// Since we're performing authorization at the action level, the authorization code runs
// after the output caching module. In the worst case this could allow an authorized user
// to cause the page to be cached, then an unauthorized user would later be served the
// cached page. We work around this by telling proxies not to cache the sensitive page,
// then we hook our custom authorization code into the caching mechanism so that we have
// the final say on whether a page should be served from the cache.
HttpCachePolicyBase cachePolicy = filterContext.HttpContext.Response.Cache;
cachePolicy.SetProxyMaxAge(new TimeSpan(0));
cachePolicy.AddValidationCallback(CacheValidateHandler, null /* data */);
}
else {
HandleUnauthorizedRequest(filterContext);
}
}
Even if you didn't plan on using cache, those two magic strings seem a small price to pay for the peace of mind you get in return (and the potential headaches you save yourself.) If you still want to override OnAuthorization instead, you should at least make sure the request isn't cached. See this post by Levi for more context.
You can get the Action Name like this:
public class CustomAuthFilter : IAuthorizationFilter
{
public void OnAuthorization(AuthorizationContext filterContext)
{
filterContext.ActionDescriptor.ActionName;
}
}
EDIT:
If you want to inherit from the AuthorizationAttribute you'll need to override the OnAuthorization method.
public class CustomAuthAttribute : AuthorizeAttribute
{
public override void OnAuthorization(AuthorizationContext filterContext)
{
base.OnAuthorization(filterContext);
}
}
Title said it all.
Some context:
I got a search mechanism - search view, search results view and a details view (which represents one item of results, like a formview in webforms). I want a link in details view, which would return user to search results view.
Ideas:
Just read about TempData, but i guess that wouldn't help, cause user might call some actions before he wants to return.
Session might work, but I'm not sure how exactly i should handle it.
I don't want to use javascript to accomplish this.
Edit:
Seems that i'll stick with eu-ge-ne`s solution. Here's result:
#region usages
using System.Web.Mvc;
using CompanyName.UI.UIApp.Infrastructure.Enums;
#endregion
namespace CompanyName.UI.UIApp.Infrastructure.Filters
{
/// <summary>
/// Apply on action method to store URL of request in session
/// </summary>
public class RememberUrlAttribute : ActionFilterAttribute
{
public override void OnActionExecuting
(ActionExecutingContext filterContext)
{
var httpContext = filterContext.HttpContext;
if (httpContext.Request.RequestType == "GET"
&& !httpContext.Request.IsAjaxRequest())
{
SessionManager
.Save(SessionKey.PreviousUrl,
SessionManager.Get(SessionKey.CurrentUrl) ??
httpContext.Request.Url);
SessionManager
.Save(SessionKey.CurrentUrl,
httpContext.Request.Url);
}
}
}
}
Btw, how does .IsAjaxRequest() method works? It understands only MS AJAX or it's smarter than that?
I think you need something like this custom filter (not tested - have no VS at the moment):
public class PrevUrlAttribute : ActionFilterAttribute
{
public override void OnActionExecuting(ActionExecutingContext filterContext)
{
var httpContext = filterContext.HttpContext;
var session = filterContext.HttpContext.Session;
if (httpContext.Request.RequestType == "GET"
&& !httpContext.Request.IsAjaxRequest())
{
session["PrevUrl"] = session["CurUrl"] ?? httpContext.Request.Url;
session["CurUrl"] = httpContext.Request.Url;
}
}
}
You can examine the HTTP Referrer header to retrieve the previous URL.
Of course, you'll have to handle gracefully just in case the user does not pass in this value.
Yo
:)
I have some action methods behind an Authorize like:
[AcceptVerbs(HttpVerbs.Post), Authorize]
public ActionResult Create(int siteId, Comment comment) {
The problem I have is that I'm sending a request through AJAX to Comment/Create with
X-Requested-With=XMLHttpRequest
which helps identify the request as AJAX. When the user is not logged in and hits the Authorize wall it gets redirected to
/Account/LogOn?ReturnUrl=Comment%2fCreate
which breaks the AJAX workflow. I need to be redirected to
/Account/LogOn?X-Requested-With=XMLHttpRequest
Any ideas how that can be achieved? Any ways to gain more control over what happens when Authorization is requested?
Thanks to Lewis comments I was able to reach this solution (which is far from perfect, posted with my own comments, if you have the fixes feel free to edit and remove this phrase), but it works:
public class AjaxAuthorizeAttribute : AuthorizeAttribute {
override public void OnAuthorization(AuthorizationContext filterContext) {
base.OnAuthorization(filterContext);
// Only do something if we are about to give a HttpUnauthorizedResult and we are in AJAX mode.
if (filterContext.Result is HttpUnauthorizedResult && filterContext.HttpContext.Request.IsAjaxRequest()) {
// TODO: fix the URL building:
// 1- Use some class to build URLs just in case LoginUrl actually has some query already.
// 2- When leaving Result as a HttpUnauthorizedResult, ASP.Net actually does some nice automatic stuff, like adding a ReturnURL, when hardcodding the URL here, that is lost.
String url = System.Web.Security.FormsAuthentication.LoginUrl + "?X-Requested-With=XMLHttpRequest";
filterContext.Result = new RedirectResult(url);
}
}
}
Recently I ran into exactly the same problem and used the code posted by J. Pablo Fernández
with a modification to account for return URLs. Here it is:
public class AuthorizeAttribute : System.Web.Mvc.AuthorizeAttribute
{
override public void OnAuthorization(AuthorizationContext filterContext)
{
base.OnAuthorization(filterContext);
// Only do something if we are about to give a HttpUnauthorizedResult and we are in AJAX mode.
if (filterContext.Result is HttpUnauthorizedResult && filterContext.HttpContext.Request.IsAjaxRequest())
{
// TODO: fix the URL building:
// 1- Use some class to build URLs just in case LoginUrl actually has some query already.
HttpRequestBase request = filterContext.HttpContext.Request;
string returnUrl = request.Path;
bool queryStringPresent = request.QueryString.Count > 0;
if (queryStringPresent || request.Form.Count > 0)
returnUrl += '?' + request.QueryString.ToString();
if (queryStringPresent)
returnUrl += '&';
returnUrl += request.Form;
String url = System.Web.Security.FormsAuthentication.LoginUrl +
"?X-Requested-With=XMLHttpRequest&ReturnUrl=" +
HttpUtility.UrlEncode(returnUrl);
filterContext.Result = new RedirectResult(url);
}
}
}
Instead of using the authorize attribute, I've been doing something like the following.
public ActionResult SomeCall(string someData)
{
if (Request.IsAjaxRequest() == false)
{
// TODO: do the intended thing.
}
else
{
// This should only work with AJAX requests, so redirect
// the user to an appropriate location.
return RedirectToAction("Action", "Controller", new { id = ?? });
}
}
I think the right way to handle this would be in your Javascript making the AJAX call.
If the user needs to be authorized (or authenticated as your code implies) and isn't, you should inform them and maybe not allow them to try and comment in the first place.
However, if that doesn't suit your needs.
You could try and write your own authorize action filter, maybe inheriting from the one that comes with the MVC framework but redirects how you want it to. It's fairly straightforward.