U leest het goed, een autorisatiemodel voor het Leerplatform (Ook wel GiP-opdrachten genoemd) (En ja de spelling klopt, ik heb het opgezocht op google). Aangezien het Leerplatform een platform is voor docenten en studenten om zich op in te schrijven en op die manier lessen te maken en te volgen, moet natuurlijk niet zomaar iedereen op dat platform kunnen zitten. Want wat als eenderwie ineens een eigen planning kan aanmaken? Of nog sterker, wat als elke student ineens elk vak zou kunnen aanpassen of zelfs verwijderen, en eigen vakken zou kunnen aanmaken? Dat mag natuurlijk niet gebeuren, en daarom maak ik een autorisatiemodel in het Leerplatform. Het autorisatiemodel dat ik gebruik, is Identity van Asp.net Core. Het is een Role-based model dat niet voor gigantisch sterke veiligheid zorgt, maar goed genoeg is om voor onze applicatie te gebruiken. Ik hoor nu al dat het bij jullie in Keulen dondert. “Wat is Role-based?” zal waarschijnlijk de meest voorkomende vraag zijn. Daarom een korte uitleg. Role-based wil zeggen dat je gaat bepalen dat bepaalde acties alleen mogelijk zijn voor gebruikers met een bepaalde rol. Bijvoorbeeld kun je zo zeggen dat de actie van het aanmaken van een vak alleen beschikbaar is voor gebruikers met een docentenrol. Ben je een gebruiker met alleen een studentenrol? Jammer maar helaas, maar je zult vrede moeten nemen met wat er staat. Op die basis werk ik ook in het Leerproject. De acties die moeten beschermd worden van de buitenwereld, zet ik 1 of meer mogelijke rollen op, zodat ook binnen de applicatie niemand iets onrechtmatig kan doen. Alle acties waar data aan gekoppeld is (de home-pagina dus niet) zijn allemaal van autorisatie voorzien. Binnen de pagina-groepen (in vakstermen controllers genoemd), die gecentraliseerd zijn rond 1 soort van data, bijvoorbeeld vak of lokaal (planning en les zijn hier een uitzondering op) zijn er ook indien nodig andere of extra mogelijke rollen aan toegekend. Zo mag een student wel de vakken raadplegen om zich te kunnen inschrijven of uitschrijven voor dat vak, maar hij kan niet (nee zelfs niet via de URL) deze gegevens wijzigen, verwijderen of nieuwe gegevens maken. Een docent daarentegen moet ook de vakken kunnen raadplegen, maar heeft dan weer niet de nood (en dus ook niet het recht) om zich in- of uit te schrijven voor een vak. Een docent kan dan weer wel die inschrijvingsaanvragen goed- of afkeuren, en alle gegevens bewerken en nieuwe aanmaken. Ik heb voor deze aanpak gekozen, omdat eenerzijds dit zo was aangeboden, maar anderzijds ook zeer simpel, en toch handig en sterk in gebruik is. Je kunt niet zeggen met alleen de rollen dat iedere student zijn eigen gegevens over de vakken ziet, maar daar zijn andere oplossingen voor, ook binnen Identity.