[.NET] Authorization, profile app. block in ASP.NET

[LoekD]

Er wordt hier in een project gebruik gemaakt van het 'Authorization, profile app. building block'.
Daarin wordt voor iedere webmethod-call een security check gedaan.

Dat ziet er ongeveer zo uit

De webmethod maakt een business object aan, deze heeft een “zoek iets method”:

Daarin staat dan het volgende (pseudo)

code:

Zoekiets()
{
            if (  authoriseUser( Context.User) )     
}

De authoriseUser method ziet er zo uit:

code:

authoriseUser( IPrincipal pr ) 
{
              ExtendedPrinicpal expr =  ExtendedPrinicpal.Create ( pr )
            Thread.CurrentPrincipal  = expr;
            //heeft gebruikersrol toegang?
            return IsInRole( Thread.CurrentPrincipal  )
}

Maar, volgens mij hebben we het over een workerthread die meerdere requests tegelijk uitvoert.

Dus stel, gebruiker A wil iets, en B ook. (gelijktijdig)
A heeft rechten om de method uit te voeren, B niet.


Er wordt een stukje van het Request van A uitgevoerd:
A zet de Thread.CurrentPrinicpal op zijn geautoriseerde ExtendedPrinicpal,

Nu wordt een deel van het Request van B uitgevoerd:
B schrijft hem direct over met zijn eigen ExtendedPrinicpal. (niet geautoriseerd)

Nu wordt er weer een stukje A uitgevoerd:
(Nu staat de CurrentPrincipal van de Thread dus op de principal van B ( het is een static property ) )
---> IsInRole() voor A geeft 'false'.


Is dat nu een denkfout van mij, of is het block niet bruikbaar in web-omgevingen?

[ Voor 2% gewijzigd door LoekD op 29-07-2004 10:40 . Reden: context.user ip context.user.identity ]

[Infinitive]

Volgens mij ga je er in je redenering vanuit dat een workerthread nu eens een stukje van de ene request doet en dan weer een stukje van de andere request en dan weer een stukje van de eerste, etc. Echter, een workerthread handelt complete request af (dat ZoekIets() bijv) voordat het een andere request kan doen.

[ Voor 4% gewijzigd door Infinitive op 29-07-2004 10:50 ]

[LoekD]

Hmm..
Da's een goeie,
als een request inderdaad een atomaire actie is, dan zijn er geen problemen.
Ik zal het eens uitzoeken.

[eghie]

Hij zal nooit van beide gebruikers dingen doorelkaar gaan halen. De beide gebruikers handelt hij apart af. Dus ik denk dat hij gewoon voor IsInRole() voor A 'True' terug geeft.

[LoekD]

Ik heb besloten dat ik het toch geen mooie oplossing vind.
Nu zit ik aan de volgende oplossing te denken.

Het block mag blijven, maar er komt een HTTPmodule, die de authenticatie en autorisatie gaat doen.
Dit wordt dan een GenericPrincipal, die aan de Context.User wordt gehangen.

Dat lijkt me een nettere oplossing. Beter dan in je code steeds hetzelfde te moeten schrijven. En als het nog eens veranderen moet, sloop de de module eruit en klaar.

Maargoed, da's dus een plan. Wie is het er (niet) mee eens? En waarom wel/niet?

[eghie]

LoekD schreef op 29 juli 2004 @ 20:41:
Ik heb besloten dat ik het toch geen mooie oplossing vind.
Nu zit ik aan de volgende oplossing te denken.

Het block mag blijven, maar er komt een HTTPmodule, die de authenticatie en autorisatie gaat doen.
Dit wordt dan een GenericPrincipal, die aan de Context.User wordt gehangen.

Dat lijkt me een nettere oplossing. Beter dan in je code steeds hetzelfde te moeten schrijven. En als het nog eens veranderen moet, sloop de de module eruit en klaar.

Maargoed, da's dus een plan. Wie is het er (niet) mee eens? En waarom wel/niet?

Ik vind dat zelf ook een mooiere oplossing, omdat je maar 1 keer je code hoeft in te typen en je beheert je authorisatie vanaf 1 plek. Wil je iets toevoegen gaat dat een stuk sneller/makkelijker. Ik ben het er dus wel mee eens.