Tim Cartwright nous étonne une fois de plus ...

Il y a quelques temps, je devais ajouter une couche de sécurité sur une application que l'on m'avait confiée. C'était pour une autre application qui allait utiliser la même base que l'application d'origine. Comme il y avait déjà des rôles de sécurité définis dans la première application , je me demandais quelle serait la difficulté de la tâche.

Ainsi , je me mis à chercher où ajouter les nouveaux rôles de sécurité. Je trouvais la réponse dans la table utilisateur avec un champ qui délimitait, par des virgules, la liste des rôles attribués à l'utilisateur. Ex :

UserId UserName Roles
1 Tim USER,SUPERVISOR,MANAGER
2 Mary USER
3 Joe USER,SUPERVISOR
Bon, c'est vrai, ce n'était pas optimal mais je pouvais m'en charger. J'ajoutais donc mes nouveaux rôles comme présentés ci-dessous et je m'apprêtais à coder mes changements dans l'application.

UserId UserName Roles
1 Tim USER,SUPERVISOR,MANAGER,DISTRIBUTION,IT
2 Mary USER,DISTRIBUTION
3 Joe USER,SUPERVISOR,ACCOUNTING

Dès que je mis à jour la table, le système de sécurité existant s'écroula comme un château de cartes. Ci-dessous le code qui était exécuté pour vérifier le rôle des utilisateurs. Il explique de lui même le pourquoi du plantage...

Function GetDroitUtilisateur()
    Dim UserPrivileges
    GetUserPrivileges = 0    'init the return
   
    UserPrivileges = UCase(Request.Cookies("CUR_USER_ROLE"))
   
    If UserPrivileges =  "USER,SUPERVISOR,MANAGER" Then
        GetUserPrivileges = 3
    ElseIf UserPrivileges =  "USER,SUPERVISOR" Then
        GetUserPrivileges = 2
    ElseIf UserPrivileges =  "USER" Then
        GetUserPrivileges = 1
    End If
End Function