title: PrincipalPermission vs. web.config for page access controls
body: <p>I currently have my access permissions in <code>web.config</code>:</p>
  
  <pre><code> &lt;location path="Account"&gt;
      &lt;system.web&gt;
        &lt;authorization&gt;
          &lt;allow users="?"/&gt;
        &lt;/authorization&gt;
      &lt;/system.web&gt;
   &lt;/location&gt;
   ...
  </code></pre>
  
  <p>I don't like this for two reasons:</p>
  
  <ol>
  <li><code>web.config</code> becomes a mess as my website builds up</li>
  <li>I'm not sure it's good security to keep the web page access rule so separated from the page itself. After all, I edit aspx/c# files most of the day and not web.config, so things tend to slip.</li>
  <li>This is a very weird one... I just added ASP.NET4 routing, which changes the URLs. So, all of a sudden my web.config permissions are no longer valid! Similar to point #2 above.</li>
  </ol>
  
  <p>I was thinking it would be better to just use PrincipalPermission as security attributes for the classes/c# files involved in each aspx. My question:</p>
  
  <ul>
  <li>Is this done by anyone, or is it a bad ideas?</li>
  <li>More importantly... My PrincipalPermission attribute generates an exception (good) but does not redirect users back to the logon page (bad). Can this be fixed?</li>
  </ul>