Delen via

Basisbeginselen van beveiliging en ASP.NET Ondersteuning (C#)

door Scott Mitchell

Opmerking

Sinds dit artikel is geschreven, zijn de ASP.NET Lidmaatschapsproviders vervangen door ASP.NET Identity. We raden u ten zeerste aan om apps bij te werken om gebruik te maken van het ASP.NET Identity-platform in plaats van de Membership-providers die op het moment van schrijven in dit artikel werden aanbevolen. ASP.NET Identity heeft een aantal voordelen ten opzichte van het ASP.NET Lidmaatschapssysteem, waaronder:

  • Betere prestaties
  • Verbeterde uitbreidbaarheid en testbaarheid
  • Ondersteuning voor OAuth, OpenID Connect en tweeledige verificatie
  • Ondersteuning voor claim-gebaseerde identiteit
  • Betere interoperabiliteit met ASP.Net Core

PDF downloaden

Dit is de eerste zelfstudie in een reeks zelfstudies die technieken verkennen voor het verifiëren van bezoekers via een webformulier, het autoriseren van toegang tot bepaalde pagina's en functionaliteit en het beheren van gebruikersaccounts in een ASP.NET toepassing.

Introductie

Wat is het ene ding dat forums, e-commercewebsites, online e-mailwebsites, portalwebsites en sociale netwerksites allemaal gemeen hebben? Ze bieden allemaal gebruikersaccounts. Sites die gebruikersaccounts aanbieden, moeten een aantal services bieden. Nieuwe bezoekers moeten minimaal een account kunnen maken en terugkerende bezoekers moeten zich kunnen aanmelden. Dergelijke webtoepassingen kunnen beslissingen nemen op basis van de aangemelde gebruiker: sommige pagina's of acties kunnen worden beperkt tot alleen aangemelde gebruikers of tot een bepaalde subset van gebruikers; andere pagina's kunnen informatie weergeven die specifiek is voor de aangemelde gebruiker of meer of minder informatie weergeven, afhankelijk van de gebruiker die de pagina bekijkt.

Dit is de eerste zelfstudie in een reeks zelfstudies die technieken verkennen voor het verifiëren van bezoekers via een webformulier, het autoriseren van toegang tot bepaalde pagina's en functionaliteit en het beheren van gebruikersaccounts in een ASP.NET toepassing. In de loop van deze zelfstudies bekijken we het volgende:

  • Gebruikers identificeren en aanmelden bij een website
  • Gebruik het Membership-framework van ASP.NET om gebruikersaccounts te beheren
  • Gebruikersaccounts maken, bijwerken en verwijderen
  • Toegang tot een webpagina, map of specifieke functionaliteit beperken op basis van de aangemelde gebruiker
  • Gebruik het ASP.NET-rollenframework om gebruikersaccounts te koppelen aan rollen.
  • Gebruikersrollen beheren
  • Toegang tot een webpagina, map of specifieke functionaliteit beperken op basis van de rol van aangemelde gebruiker
  • Pas de beveiligingswebbesturingselementen van ASP.NET aan en breid ze uit

Deze zelfstudies zijn gericht op beknoptheid en bieden stapsgewijze instructies met tal van schermopnamen om u visueel door het proces te begeleiden. Elke zelfstudie is beschikbaar in C# en Visual Basic-versies en bevat een download van de volledige code die wordt gebruikt. (Deze eerste zelfstudie richt zich op beveiligingsconcepten op hoog niveau en bevat daarom geen bijbehorende code.)

In deze zelfstudie bespreken we belangrijke beveiligingsconcepten en welke faciliteiten beschikbaar zijn in ASP.NET om te helpen bij het implementeren van formulierverificatie, autorisatie, gebruikersaccounts en rollen. Laten we aan de slag gaan.

Opmerking

Beveiliging is een belangrijk aspect van elke toepassing die fysieke, technologische en beleidsbeslissingen omvat en een hoge mate van planning en domeinkennis vereist. Deze reeks zelfstudies is niet bedoeld als richtlijn voor het ontwikkelen van beveiligde webtoepassingen. In plaats daarvan richt het zich specifiek op formulierverificatie, autorisatie, gebruikersaccounts en rollen. Hoewel sommige beveiligingsconcepten rond deze problemen in deze reeks worden besproken, blijven andere onbesproken.

Verificatie, autorisatie, gebruikersaccounts en rollen

Verificatie, autorisatie, gebruikersaccounts en rollen zijn vier termen die heel vaak in deze reeks zelfstudies worden gebruikt. Daarom wil ik even de tijd nemen om deze termen te definiëren binnen de context van webbeveiliging. In een client-servermodel, zoals internet, zijn er veel scenario's waarin de server de client moet identificeren die de aanvraag indient. Verificatie is het proces van het vaststellen van de identiteit van de client. Een cliënt die met succes is geïdentificeerd, wordt geacht te zijn geauthenticeerd. Een niet-geïdentificeerde cliënt wordt geacht niet-geverifieerd of anoniem te zijn.

Veilige verificatiesystemen hebben ten minste één van de volgende drie facetten: iets dat u weet, iets wat u hebt of iets wat u bent. De meeste webtoepassingen zijn afhankelijk van iets wat de client weet, zoals een wachtwoord of een pincode. De informatie die wordt gebruikt om een gebruiker te identificeren , bijvoorbeeld haar gebruikersnaam en wachtwoord, wordt aangeduid als referenties. Deze reeks zelfstudies richt zich op formulierverificatie. Dit is een verificatiemodel waarbij gebruikers zich aanmelden bij de site door hun referenties op te geven in een webpaginaformulier. We hebben dit type verificatie al eerder ervaren. Ga naar een e-commercesite. Wanneer u klaar bent om te uitchecken, wordt u gevraagd u aan te melden door uw gebruikersnaam en wachtwoord in te voeren in tekstvakken op een webpagina.

Naast het identificeren van clients moet een server mogelijk beperken welke resources of functionaliteiten toegankelijk zijn, afhankelijk van de client die de aanvraag indient. Autorisatie is het proces om te bepalen of een bepaalde gebruiker de bevoegdheid heeft om toegang te krijgen tot een specifieke resource of functionaliteit.

Een gebruikersaccount is een archief voor persistente informatie over een bepaalde gebruiker. Gebruikersaccounts moeten minimaal informatie bevatten die de gebruiker uniek identificeert, zoals de aanmeldingsnaam en het wachtwoord van de gebruiker. Naast deze essentiële informatie kunnen gebruikersaccounts zaken bevatten als: het e-mailadres van de gebruiker; de datum en tijd waarop het account is gemaakt; de datum en tijd waarop ze zich het laatst hebben aangemeld; voor- en achternaam; telefoonnummer; en postadres. Wanneer u formulierverificatie gebruikt, worden gebruikersaccountgegevens doorgaans opgeslagen in een relationele database zoals Microsoft SQL Server.

Webtoepassingen die gebruikersaccounts ondersteunen, kunnen gebruikers desgewenst groeperen in rollen. Een rol is gewoon een label dat wordt toegepast op een gebruiker en biedt een abstractie voor het definiëren van autorisatieregels en functionaliteit op paginaniveau. Een website kan bijvoorbeeld een beheerdersrol bevatten met autorisatieregels die uitsluitend een beheerder toestaan om toegang te krijgen tot een bepaalde set webpagina's. Bovendien kan een groot aantal pagina's die toegankelijk zijn voor alle gebruikers (inclusief niet-beheerders) aanvullende gegevens weergeven of extra functionaliteit bieden wanneer ze worden bezocht door gebruikers in de rol Administrators. Met behulp van rollen kunnen we deze autorisatieregels definiëren op rollenbasis in plaats van per gebruiker.

Gebruikers verifiëren in een ASP.NET-toepassing

Wanneer een gebruiker een URL invoert in het adresvenster van de browser of op een koppeling klikt, maakt de browser een HTTP-aanvraag (Hypertext Transfer Protocol) naar de webserver voor de opgegeven inhoud, of het nu een ASP.NET pagina, een afbeelding, een JavaScript-bestand of een ander type inhoud. De webserver wordt belast met het retourneren van de aangevraagde inhoud. Hierbij moet het een aantal dingen over de aanvraag bepalen, waaronder wie de aanvraag heeft ingediend en of de identiteit is gemachtigd om de aangevraagde inhoud op te halen.

Standaard verzenden browsers HTTP-aanvragen die geen enkele vorm van identificatiegegevens bevatten. Maar als de browser wel verificatiegegevens bevat, start de webserver de verificatiewerkstroom, waarmee wordt geprobeerd de client te identificeren die de aanvraag doet. De stappen van de verificatiewerkstroom zijn afhankelijk van het type verificatie dat wordt gebruikt door de webtoepassing. ASP.NET ondersteunt drie typen verificatie: Windows, Passport en formulieren. Deze reeks zelfstudies is gericht op formulierverificatie, maar laten we even de tijd nemen om de gebruikersarchieven en werkstroom van Windows-verificatie te vergelijken en te contrasteren.

Verificatie via Windows-verificatie

De Werkstroom voor Windows-verificatie maakt gebruik van een van de volgende verificatietechnieken:

  • Basisverificatie
  • Digest-authenticatie
  • Geïntegreerde Windows-verificatie

Alle drie de technieken werken op ongeveer dezelfde manier: wanneer een niet-geautoriseerde, anonieme aanvraag binnenkomt, stuurt de webserver een HTTP-antwoord terug dat aangeeft dat autorisatie is vereist om door te gaan. De browser geeft vervolgens een modaal dialoogvenster weer waarin de gebruiker wordt gevraagd om zijn gebruikersnaam en wachtwoord (zie afbeelding 1). Deze informatie wordt vervolgens via een HTTP-header teruggestuurd naar de webserver.

In een modaal dialoogvenster wordt de gebruiker gevraagd om zijn referenties

Afbeelding 1: In een modaal dialoogvenster wordt de gebruiker gevraagd om zijn referenties

De opgegeven inloggegevens worden gevalideerd tegenover de Windows User Store van de webserver. Dit betekent dat elke geverifieerde gebruiker in uw webtoepassing een Windows-account in uw organisatie moet hebben. Dit is gebruikelijk in intranetscenario's. Sterker nog, wanneer u geïntegreerde Windows-verificatie gebruikt in een intranetinstelling, levert de browser automatisch de referenties die worden gebruikt om op het netwerk in te loggen aan de webserver, waardoor het dialoogvenster in afbeelding 1 onderdrukt wordt. Hoewel Windows-verificatie ideaal is voor intranettoepassingen, is het meestal onbereikbaar voor internettoepassingen, omdat u geen Windows-accounts wilt maken voor elke gebruiker die zich aanmeldt op uw site.

Verificatie via formulierverificatie

Formulierverificatie is daarentegen ideaal voor internetwebtoepassingen. Zoals u weet, identificeert formulierverificatie de gebruiker door hen te vragen hun referenties via een webformulier in te voeren. Wanneer een gebruiker toegang probeert te krijgen tot een niet-geautoriseerde resource, worden ze automatisch omgeleid naar de aanmeldingspagina waar ze hun referenties kunnen invoeren. De ingediende referenties worden vervolgens gevalideerd op basis van een aangepast gebruikersarchief, meestal een database.

Nadat de ingediende referenties zijn geverifieerd, wordt er een formulierverificatieticket voor de gebruiker gemaakt. Dit ticket geeft aan dat de gebruiker is geverifieerd en identificatiegegevens bevat, zoals de gebruikersnaam. Het formulierverificatieticket wordt (meestal) opgeslagen als een cookie op de clientcomputer. Daarom bevatten volgende bezoeken aan de website het formulierverificatieticket in de HTTP-aanvraag, waardoor de webtoepassing de gebruiker kan identificeren zodra deze zich heeft aangemeld.

Afbeelding 2 illustreert de werkstroom voor formulierverificatie vanaf een hoog uitkijkpunt. U ziet hoe de verificatie- en autorisatieonderdelen in ASP.NET fungeren als twee afzonderlijke entiteiten. Het formulierverificatiesysteem identificeert de gebruiker (of rapporteert dat ze anoniem zijn). Het autorisatiesysteem bepaalt of de gebruiker toegang heeft tot de aangevraagde resource. Als de gebruiker niet gemachtigd is (zoals in afbeelding 2 wanneer de gebruiker anoniem ProtectedPage.aspx probeert te bezoeken), meldt het autorisatiesysteem dat de gebruiker wordt geweigerd, waardoor het formulierverificatiesysteem de gebruiker automatisch omleidt naar de aanmeldingspagina.

Zodra de gebruiker zich heeft aangemeld, bevatten volgende HTTP-aanvragen het formulierverificatieticket. Het formulierverificatiesysteem identificeert alleen de gebruiker. Het is het autorisatiesysteem dat bepaalt of de gebruiker toegang heeft tot de aangevraagde resource.

De werkstroom voor formulierverificatie

Afbeelding 2: De werkstroom voor formulierverificatie

In de volgende zelfstudie, Een overzicht van formulierverificatie, gaan we dieper in op formulierverificatie. Voor meer informatie over de authenticatieopties van ASP.NET, zie ASP.NET Authenticatie.

De toegang tot webpagina's, mappen en paginafunctionaliteit beperken

ASP.NET bevat twee manieren om te bepalen of een bepaalde gebruiker gemachtigd is om toegang te krijgen tot een specifiek bestand of een specifieke map:

  • Bestandsautorisatie : omdat ASP.NET pagina's en webservices worden geïmplementeerd als bestanden die zich in het bestandssysteem van de webserver bevinden, kan toegang tot deze bestanden worden opgegeven via ACL's (Access Control Lists). Bestandsautorisatie wordt meestal gebruikt met Windows-verificatie, omdat ACL's machtigingen zijn die van toepassing zijn op Windows-accounts. Wanneer u formulierverificatie gebruikt, worden alle aanvragen op besturingssysteem- en bestandssysteemniveau uitgevoerd door hetzelfde Windows-account, ongeacht de gebruiker die de site bezoekt.
  • URL-autorisatie: met URL-autorisatie geeft de paginaontwikkelaar autorisatieregels op in Web.config. Deze autorisatieregels geven aan welke gebruikers of rollen toegang mogen krijgen of worden geweigerd voor toegang tot bepaalde pagina's of mappen in de toepassing.

Bestandsautorisatie en URL-autorisatie definiëren autorisatieregels voor toegang tot een bepaalde ASP.NET pagina of voor alle ASP.NET pagina's in een bepaalde map. Met deze technieken kunnen we ASP.NET instrueren aanvragen voor een bepaalde pagina voor een bepaalde gebruiker te weigeren of toegang tot een set gebruikers toe te staan en toegang tot iedereen te weigeren. Hoe zit het met scenario's waarbij alle gebruikers toegang hebben tot de pagina, maar de functionaliteit van de pagina afhankelijk is van de gebruiker? Veel sites die ondersteuning bieden voor gebruikersaccounts hebben bijvoorbeeld pagina's met verschillende inhoud of gegevens voor geverifieerde gebruikers versus anonieme gebruikers. Een anonieme gebruiker ziet mogelijk een koppeling om u aan te melden bij de site, terwijl een geverifieerde gebruiker in plaats daarvan een bericht ziet zoals Welkom terug, Gebruikersnaam en een koppeling om u af te melden. Een ander voorbeeld: wanneer u een item op een veilingsite bekijkt, ziet u verschillende informatie, afhankelijk van of u een bieder of degene bent die het item veilingt.

Dergelijke aanpassingen op paginaniveau kunnen declaratief of programmatisch worden uitgevoerd. Als u andere inhoud voor anoniem wilt weergeven dan geverifieerde gebruikers, sleept u een LoginView-besturingselement naar uw pagina en voert u de juiste inhoud in de sjablonen AnonymousTemplate en LoggedInTemplate in. U kunt ook programmatisch bepalen of de huidige aanvraag is geverifieerd, wie de gebruiker is en tot welke rollen ze behoren (indien van toepassing). U kunt deze informatie gebruiken om vervolgens kolommen in een raster of deelvensters op de pagina weer te geven of te verbergen.

Deze reeks bevat drie zelfstudies die zich richten op autorisatie. User-Based Autorisatieonderzoekt hoe de toegang tot een pagina of pagina's in een directory voor specifieke gebruikersaccounts kan worden beperkt; Role-Based Autorisatie kijkt naar het leveren van autorisatieregels op rolniveau; Ten slotte verkent de zelfstudie Over het weergeven van inhoud op basis van de zelfstudie Momenteel aangemelde gebruiker het wijzigen van de inhoud en functionaliteit van een bepaalde pagina op basis van de gebruiker die de pagina bezoekt. Voor meer informatie over de autorisatieopties van ASP.NET, zie ASP.NET Autorisatie.

Gebruikersaccounts en -rollen

De formulieren-authenticatie van ASP.NET biedt gebruikers een infrastructuur voor het inloggen op een website, zodat hun verificatiestatus wordt onthouden tijdens paginabezoeken. En URL-autorisatie biedt een framework voor het beperken van de toegang tot specifieke bestanden of mappen in een ASP.NET toepassing. Geen van beide functies biedt echter een middel voor het opslaan van gebruikersaccountgegevens of het beheren van rollen.

Vóór ASP.NET 2.0 waren ontwikkelaars verantwoordelijk voor het maken van hun eigen gebruikers- en rolarchieven. Ze stonden ook aan de haak voor het ontwerpen van de gebruikersinterfaces en het schrijven van de code voor essentiële pagina's met betrekking tot gebruikersaccounts, zoals de aanmeldingspagina en de pagina om onder andere een nieuw account te maken. Zonder ingebouwd framework voor gebruikersaccounts in ASP.NET moest elke ontwikkelaar die gebruikersaccounts implementeert, bij zijn eigen ontwerpbeslissingen komen over vragen als: Hoe sla ik wachtwoorden of andere gevoelige informatie op? En welke richtlijnen moet ik opleggen met betrekking tot wachtwoordlengte en -sterkte?

Tegenwoordig is het implementeren van gebruikersaccounts in een ASP.NET-toepassing veel eenvoudiger dankzij het lidmaatschapsframework en de ingebouwde besturingselementen voor aanmeldingswebs. Het lidmaatschapsframework is een handvol klassen in de System.Web.Security-naamruimte die functionaliteit biedt voor het uitvoeren van essentiële taken met betrekking tot gebruikersaccounts. De belangrijkste klasse in het lidmaatschapsframework is de lidmaatschapsklasse, die methoden heeft zoals:

  • GebruikerMaken
  • Gebruiker verwijderen
  • GetAllGebruikers
  • GetUser
  • Gebruiker bijwerken
  • ValidateUser

Het lidmaatschapsframework maakt gebruik van het providermodel, dat de API van het lidmaatschapsframework op schone wijze scheidt van de implementatie. Hierdoor kunnen ontwikkelaars een gemeenschappelijke API gebruiken, maar kunnen ze een implementatie gebruiken die voldoet aan de aangepaste behoeften van hun toepassing. Kortom, de lidmaatschapsklasse definieert de essentiële functionaliteit van het framework (de methoden, eigenschappen en gebeurtenissen), maar levert geen implementatiedetails. In plaats daarvan roepen de methoden van de lidmaatschapsklasse de geconfigureerde provider aan. Dit is wat het werkelijke werk uitvoert. Wanneer de methode CreateUser van de lidmaatschapsklasse bijvoorbeeld wordt aangeroepen, weet de lidmaatschapsklasse niet de details van het gebruikersarchief. Het is niet bekend of gebruikers worden beheerd in een database, in een XML-bestand, of in een ander opslagmedium. De lidmaatschapsklasse onderzoekt de configuratie van de webtoepassing om te bepalen naar welke provider de aanroep moet worden gedelegeerd en die providerklasse is verantwoordelijk voor het daadwerkelijk maken van het nieuwe gebruikersaccount in het juiste gebruikersarchief. Deze interactie wordt geïllustreerd in afbeelding 3.

Microsoft verzendt twee lidmaatschapsproviderklassen in .NET Framework:

Deze reeks zelfstudies richt zich uitsluitend op sqlMembershipProvider.

Met het providermodel kunnen verschillende implementaties naadloos worden aangesloten op het framework</sterk>

Afbeelding 03: Met het providermodel kunnen verschillende implementaties naadloos worden aangesloten op het framework (klik om de volledige afbeelding weer te geven)

Het voordeel van het providermodel is dat alternatieve implementaties kunnen worden ontwikkeld door Microsoft, externe leveranciers of individuele ontwikkelaars en naadloos kunnen worden aangesloten op het lidmaatschapsframework. Microsoft heeft bijvoorbeeld een lidmaatschapsprovider uitgebracht voor Microsoft Access-databases. Raadpleeg de Provider Toolkit voor meer informatie over de lidmaatschapsproviders, waaronder een overzicht van de lidmaatschapsproviders, voorbeeld van aangepaste providers, meer dan 100 pagina's met documentatie over het providermodel en de volledige broncode voor de ingebouwde lidmaatschapsproviders (namelijk ActiveDirectoryMembershipProvider en SqlMembershipProvider).

ASP.NET 2.0 heeft ook het rollenframework geïntroduceerd. Net als het lidmaatschapsframework wordt het rollenframework gebouwd op het providermodel. De API wordt beschikbaar gesteld via de rollenklasse en het .NET Framework wordt geleverd met drie providerklassen:

  • AuthorizationStoreRoleProvider : beheert rolgegevens in een autorisatiebeheerbeleidsarchief, zoals Active Directory of ADAM.
  • SqlRoleProvider : implementeert rollen in een SQL Server-database.
  • WindowsTokenRoleProvider - koppelt rolgegevens op basis van de Windows-groep van de bezoeker. Deze methode wordt doorgaans gebruikt met Windows-verificatie.

Deze reeks zelfstudies richt zich uitsluitend op sqlRoleProvider.

Omdat het providermodel één forward-facing API (de klassen Lidmaatschap en rollen) bevat, is het mogelijk om functionaliteit rond die API te bouwen zonder dat u zich zorgen hoeft te maken over de implementatiedetails. Deze worden verwerkt door de providers die zijn geselecteerd door de paginaontwikkelaar. Met deze geïntegreerde API kunnen Microsoft- en externe leveranciers webbesturingselementen bouwen die interface hebben met de frameworks Lidmaatschap en Rollen. ASP.NET wordt geleverd met een aantal Login-webbesturingselementen voor het implementeren van algemene gebruikersinterfaces voor accounts. Het aanmeldingsbeheer vraagt bijvoorbeeld een gebruiker om zijn referenties, valideert deze en meldt deze vervolgens aan via formulierverificatie. Het besturingselement LoginView biedt sjablonen voor het weergeven van verschillende markeringen aan anonieme gebruikers versus geverifieerde gebruikers of verschillende markeringen op basis van de rol van de gebruiker. En het besturingselement CreateUserWizard biedt een stapsgewijze gebruikersinterface voor het maken van een nieuw gebruikersaccount.

Onder de motorkap interageren de verschillende inlogbesturingselementen met de frameworks Lidmaatschap en Rollen. De meeste besturingselementen voor aanmelding kunnen worden geïmplementeerd zonder dat u één regel code hoeft te schrijven. In toekomstige zelfstudies zullen we deze besturingselementen nader bekijken, waaronder technieken voor het uitbreiden en aanpassen van hun functionaliteit.

Samenvatting

Voor alle webtoepassingen die gebruikersaccounts ondersteunen, zijn vergelijkbare functies vereist, zoals: de mogelijkheid voor gebruikers om zich aan te melden en hun aanmeldingsstatus te laten onthouden tijdens paginabezoeken; een webpagina voor nieuwe bezoekers om een account te maken; en de mogelijkheid om de paginaontwikkelaar op te geven welke resource, gegevens en functionaliteit beschikbaar zijn voor welke gebruikers of rollen. De taken van het verifiëren en autoriseren van gebruikers en van het beheren van gebruikersaccounts en -rollen is opmerkelijk eenvoudig in ASP.NET toepassingen dankzij formulierenverificatie, URL-autorisatie en de frameworks Lidmaatschap en Rollen.

In de loop van de volgende zelfstudies zullen we deze aspecten onderzoeken door een werkende webtoepassing vanaf de basis te bouwen op een stapsgewijze manier. In de volgende twee tutorials gaan we de verificatie van formulieren in detail verkennen. We zien de werkstroom voor formulierverificatie in actie, het formulierverificatieticket ontleden, beveiligingsproblemen bespreken en zien hoe u het formulierverificatiesysteem configureert, allemaal terwijl u een webtoepassing bouwt waarmee bezoekers zich kunnen aanmelden en afmelden.

Veel plezier met programmeren!

Meer lezen

Raadpleeg de volgende bronnen voor meer informatie over de onderwerpen die in deze zelfstudie worden besproken:

Over de auteur

Scott Mitchell, auteur van zeven ASP/ASP.NET-boeken en oprichter van 4GuysFromRolla.com, werkt sinds 1998 met Microsoft-webtechnologieën. Scott werkt als onafhankelijk consultant, trainer en schrijver. Zijn laatste boek is Sams Teach Yourself ASP.NET 2.0 in 24 uur. Hij kan worden bereikt op mitchell@4GuysFromRolla.com.

Speciale dank aan

Deze tutorialreeks is beoordeeld door veel behulpzame beoordelers. De hoofdrevisor voor deze zelfstudie was. Deze reeks zelfstudies is beoordeeld door veel behulpzame revisoren. Hoofdrevisoren voor deze zelfstudie zijn Alicja Maziarz, John Suru en Teresa Murphy. Bent u geïnteresseerd in het bekijken van mijn aanstaande MSDN-artikelen? Zo ja, laat iets van je horen via mitchell@4GuysFromRolla.com.

Volgende

  • Last updated on