[ASP.NET] PrincipalPermission Exceptions

[Verwijderd]

Met behulp van PrincipalPermission attributen ben ik een webapplicatie aan het beveiligen, bijvoorbeeld:

code:

[PrincipalPermission(SecurityAction.Demand, Authenticated = true)]
public partial class somepage : ExtendedPage
{

   [PrincipalPermission(SecurityAction.Demand, Role="Administrator")]
   protected void restrictedAction()
   { }

}

Dat werkt naar behoren en als de gebruiker niet is ingelogd klapt de pagina eruit met de foutmelding:

code:

Server Error in '/' Application.
--------------------------------------------------------------------------------

Security Exception

Nou wil ik graag in het geval van dergelijke security exceptions de gebruiker forwarden naar de inlogpagina, terwijl overige application errors wel gewoon worden weergegeven. Hoe kan ik dat het beste aanpakken?

[ Voor 5% gewijzigd door Verwijderd op 25-01-2006 21:31 ]

[GrimaceODespair]

Ik heb er zelf nog nooit actief mee gewerkt, maar kan je niet gewoon die SecurityException afvangen met een try..catch-blok rond het aanroeppunt? De redirect doe je in de catch, de normale code na de try..catch-clause.

[Verwijderd]

Volgens mij is dat hier niet mogelijk

[GrimaceODespair]

Als je geen try..catch kunt doen omdat de fout optreedt buiten je eigen code, kun je in een webapplicatie wel altijd Application_Error afhandelen, en middel GetLastError (ofzo) de exceptie bekijken. Als het dan een SecurityException is, redirect je naar de inlogpagina.

[joopst]

je kan een web.config in de map van je aspx zetten met daarin ongeveer het volgende:

code:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    
  <system.web>

    <!--  AUTHORIZATION 
          This section sets the authorization policies of the application. You can allow or deny access
          to application resources by user or role. Wildcards: "*" mean everyone, "?" means anonymous 
          (unauthenticated) users.
    -->
    <authorization>
            <deny users="?" /> <!-- deny all unauthenticated users -->
                        
            <!--  <allow     users="[comma separated list of users]"
                             roles="[comma separated list of roles]"/>
                  <deny      users="[comma separated list of users]"
                             roles="[comma separated list of roles]"/>
            -->
    </authorization>
    
  </system.web>

</configuration>

en als je dan in je hoofd-web.config hetvolgende hebt:

code:

        <authentication mode="Forms">
            <forms loginUrl="~/Default.aspx" name="myCookieName" timeout="60" path="/" />
        </authentication>

dan doet ie wat jij wilt.

met als bijkomend voordeel dat je niet elke aspx hoeft te p1mpen met zo'n geil attribuutje.

[whoami]

Wat Joopst zegt...
Als je gebruik maakt van forms authentication, dan wordt een niet ge-authenticeerde zowiezo geredirect naar de inlog pagina die jij instelt.
Daarbij zou ik die Permission attributes enkel gebruiken voor authorizatie. Die attributes zorgen nl voor een exceptie als er niet aan voldaan is.
Wat ik dus zou doen, is zowiezo checken of een gebruiker dan het recht heeft om iets te doen. Heeft ie dat niet, dan verberg / disable, whatever je iets zodanig dat hij het niet kan doen. Slipt hij er toch door, dan krijgt hij een exceptie.

[Verwijderd]

Oh, stom van me, die web.config was ik even helemaal vergeten, terwijl ik er al wel ruimte voor had gemaakt "<!-- add all pages that need to be secured here -->".

[Woy]

Idd die PrincipalPermission moet je eigenlijk alleen als extra stok achter de deur gebruiken. Je moet er voor zorgen dat de code in principe al niet eens aan geroepen wordt als de gebruiker er geen rechten op heeft. Gebeurt het dan toch per ongeluk dan is het terecht dat er een exception optreedt. Deze exception kan je dan eventueel afhandelen in je Exception page of je Application_Error.

[Verwijderd]

Als je gebruik maakt van forms authentication, dan wordt een niet ge-authenticeerde zowiezo geredirect naar de inlog pagina die jij instelt.
Daarbij zou ik die Permission attributes enkel gebruiken voor authorizatie.

Klopt, maar dat kon ik niet zomaar doen omdat bepaalde pagina's zowel voor ingelogde als anonieme gebruikers bereikbaar zijn.

Wel een mooie framework-feature, die attributes. Scheelt echt een hoop code.

[ Voor 80% gewijzigd door Verwijderd op 26-01-2006 11:30 ]

[whoami]

Verwijderd schreef op donderdag 26 januari 2006 @ 11:26:
[...]


Klopt, maar dat kon ik niet zomaar doen omdat bepaalde pagina's zowel voor ingelogde als anonieme gebruikers bereikbaar zijn.

Als dit zo is, dan moet je toch ook geen exceptie gooien als een niet ingelogde gebruiker die pagina bezoekt ?
Je moet 'm enkel de mogelijkheid geven om in te loggen, en bepaalde features onmogelijk maken.