Tim Cartwright astonishes us yet again ...

A while ago I had a need to add some additional security to the application that I had inherited. This was for a second application that would be using the same database as the legacy application. Since it already had custom role based security in place I figured how hard could this be? So I went in search of where to add my new roles. I found the answer in the users table in a field that was a comma delimited list of roles per user. Ex:

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

Ok, I thought, this is not optimal, but I can deal with this, I added my new role as follows below and went about coding my changes in my new application.

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

Little did I know that as soon as I released to QA, it broke the existing security in the legacy application from top to bottom. Here is the code that was in place to check the users security, and it self explains why it broke.

Function GetUserPrivileges()
    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

PLEASE, PLEASE, someone defend this..........

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!