Sometimes I’m guilty of not stopping to think about things while I’m working on them in Sitecore. A while ago I realized that I’ve worked extensively with Sitecore security but have never taken the proper time to examine the basics of how it functions.
When I think about Sitecore security, I immediately think of the Core database because I’ve always been told that security and .NET membership related data is stored in that location. I never thought much of it until I recently had a client mention that they were not immediately able to see security changes take effect on their Sitecore instance. I unknowingly assured the client that they did not need to initiate a site publish after making security changes since that data is stored in the Core database. Sure enough I was able to quickly reproduce what the client was reporting and it dawned on me that I was definitely wrong on this one. D’oh.
While the Core database is heavily used to store security information, Sitecore security is applied on a page-by-page basis. So if I want to grant or deny a user/role permission for an item, that security change is stored in the Security section of the item’s data template. This also means that an item must be re-published after making any changes to its access rights.
I know this is probably fairly obvious for many but sometimes it’s scary to realize how much you still don’t know about Sitecore. At least I will now be able to properly advise clients on how to make changes to security access rights!