Q:

Authorize tag not redirecting to correct controller

I have a Controller with two actions, Logon without any decorators and LogOn with [HttpPost] decorator.
Code:
        public ActionResult LogOn()
        {
            return View();
        }

        [HttpPost]
        public ActionResult LogOn(string username, string password, 
            bool? rememberMe, string returnUrl)
        {
            AccountService client = new AccountService();

            if (client.IsUserAllowedIn(username, password))
                FormsAuthentication.SetAuthCookie(username, rememberMe ?? false);

            return Redirect(returnUrl);
        }

The problem I'm facing is: when I try to access a method with the [Authorize] decorator ASP.NET MVC is not redirecting to my LogOn action with the [HttpPost] decorator.
For testing purposes I created a form that called LogOn using Post and it worked. So I guess the problem lays in the way I'm using the decorators. 
My web.config:
    <authentication mode="Forms">
      <forms loginUrl="~/Account/LogOn" timeout="2880" />
    </authentication>

Any ideas of what am I doing wrong?

A:

The problem I'm facing is: when I try to access a method with the
  [Authorize] decorator ASP.NET MVC is not redirecting to my LogOn
  action with the [HttpPost] decorator.

Of course that it won't. By the very base definition a redirect means a GET request. You cannot possibly expect that you will be able to redirect to a controller action that is accessible only with the POST verb. That's impossible.
In addition to that why would you want a protected resource to redirect you to a controller action that is supposed to verify your credentials. What people normally expect is that when someone attempts to access a protected resource he gets redirected to a controller action that will render a LogOn form where the user could input his credentials, submit this form to the corresponding POST action for verification and if his credentials are valid the POST action would emit a forms authentication cookie and redirect him back to the return url which is pointing to the protected resource he was initially requesting.

