sessionauthenticationcoldfusionsession-scopeuserinfo

Updating session variables kick user to login page or not?


I'm developing new application and using session variables to store some of the users information like email, permission level, etc. I'm wondering once user decide to update lets say email or permissions for themselves that won't affect right away. Session variables will be updated only if they logout and then login again. I know that one way to avoid this would be to update existing session variables. Here is my code example of what I'm setting in session variables upon users login:

<cfset local.appStruct = structNew()>
<cfset structInsert(local.appStruct, "SysAdmin", checkUser.SystemAdmin, true)>
<cfset structInsert(local.appStruct, "UserName", checkUser.UserName, true)>
<cfset structInsert(local.appStruct, "AccountID", checkUser.AccountID, true)>
<cfset structInsert(local.appStruct, "Email", checkUser.Email, true)>
<cfset structInsert(local.appStruct, "TempPW", checkUser.TempPassword, true)>
<cfset structInsert(local.appStruct, "AccessType", permissionType, true)>
<cfset structInsert(local.appStruct, "AccessLevel", permissionLevel, true)>
<cfset structInsert(local.appStruct, "AccessList", permissionList, true)>
<cfset SESSION.AccountInfo = appStruct> 

Above I just showed fields that are saved in session scope. All values are pulled from query that I did not show. For example TempPW is storing temporary password and I do not need to update that since user will be automatically moved to login page once they set their new password. In other situations where they update email or access type I'm not sure if I should log out user or try to update session scope? Is there any security risk doing it one way or the other? I'm just trying to implement the best practice in my application. Thank you.


Solution

  • From a user's perspective, having to logout and login again sounds less than ideal.

    I suggest updating the session scope when the user updates their email or other values. There should be no difference in security in that, vs requiring a user to logout and login again.

    On the page the user updates their email, after you update the values in the database simply override the session variables, for example:

    <cfset SESSION.AccountInfo.Email = form.email>
    <cfset SESSION.AccessLevel = "SOME_NEW_ACCESS_LEVEL">
    etc...
    

    As a side recommendation, I would stop using structInsert, you can simply set the variable and avoid the (extremely small) performance overhead of calling a function. Your same code above could be rewrote as:

    <cfset local.appStruct = structNew()>
    <cfset local.appStruct.SysAdmin = checkUser.SystemAdmin>
    <cfset local.appStruct.UserName = checkUser.UserName>
    <cfset local.appStruct.AccountID = checkUser.AccountID>
    <cfset local.appStruct.Email = checkUser.Email>
    <cfset local.appStruct.TempPW = checkUser.TempPassword>
    <cfset local.appStruct.AccessType = permissionType>
    <cfset local.appStruct.AccessLevel = permissionLevel>
    <cfset local.appStruct.AccessList = permissionList>
    <cfset SESSION.AccountInfo = appStruct> 
    

    If, for some reason, you need to preserve the case of the struct keys, you can use array style syntax such as:

    <cfset local.appStruct = structNew()>
    <cfset local.appStruct["SysAdmin"] = checkUser.SystemAdmin>
    <cfset local.appStruct["UserName"] = checkUser.UserName>
    <cfset local.appStruct["AccountID"] = checkUser.AccountID>
    <cfset local.appStruct["Email"] = checkUser.Email>
    <cfset local.appStruct["TempPW"] = checkUser.TempPassword>
    <cfset local.appStruct["AccessType"] = permissionType>
    <cfset local.appStruct["AccessLevel"] = permissionLevel>
    <cfset local.appStruct["AccessList"] = permissionList>
    <cfset SESSION.AccountInfo = appStruct> 
    

    You can use <cfdump to see the differences between the two structs and how the keys are either all lower case in the first example, or their upper/lower case is preserved in th esecond example.

    <cfdump var="#local.appStruct#" />
    

    Sorry I may be getting off topic, hope it helps.