-
Type:
Defect
-
Resolution: Won't Do
-
Priority:
Critical
-
Affects Version/s: 1.0.0-RC5
-
Component/s: Administration, Codebase, Security, User Account
-
None
It seems as though our User object is stored between user requests. It might be stored in the HttpSession.
This is a security risk. If the user is an administrator there is only way to stop that user from performing malicious actions if they decide to ruin the website is to kill the server.
If the user is loaded for every request we could update the database to remove all their permissions (hopefully via a web interface) and that user would instantly lose all permissions.
Storing the User between requests in memory also has the side effect of possibly causing optimistic locking exceptions.
Example:
User1 requests access to the CCSM group. User1's version attribute in the database is updated from 1 to 2 with this action and the user object in memory is updated.
Admin1 receives the request from User1 and grants permission for User1 to access the CCSM group. User1's version attribute in the database is updated from 2 to 3, but the in memory user object is NOT updated for User1.
User 1 then goes to update their email address information and receives an exception page. The exception is caused by an optimistic locking issue where the in memory object of the user is 2, but the database has been updated to 3 by Admin1 and hibernate is unable to handle the difference.
This is a security risk. If the user is an administrator there is only way to stop that user from performing malicious actions if they decide to ruin the website is to kill the server.
If the user is loaded for every request we could update the database to remove all their permissions (hopefully via a web interface) and that user would instantly lose all permissions.
Storing the User between requests in memory also has the side effect of possibly causing optimistic locking exceptions.
Example:
User1 requests access to the CCSM group. User1's version attribute in the database is updated from 1 to 2 with this action and the user object in memory is updated.
Admin1 receives the request from User1 and grants permission for User1 to access the CCSM group. User1's version attribute in the database is updated from 2 to 3, but the in memory user object is NOT updated for User1.
User 1 then goes to update their email address information and receives an exception page. The exception is caused by an optimistic locking issue where the in memory object of the user is 2, but the database has been updated to 3 by Admin1 and hibernate is unable to handle the difference.