SPSecurityTrimmedControl and Minimal Download Strategy in Sharepoint 2013
The SPSecurityTrimmedControl control (like ATM Machine, right?) is used in Sharepoint to conditionally show anything within the control to users based on the permissions the user has. You can limit child elements to only render for users with write permissions, or create list permissions, or any combination of the base permission masks Sharepoint provides.
The Minimal Download Strategy is some new functionality in Sharepoint 2013 that allows for a more dynamic and fluid browsing experience. This is a per-site (or per-web, to developers) feature that can be toggled on or off from the Site Features settings page. Basically what it does is the user actually sits on a page in the _layouts directory called start.aspx, with the page they’re viewing shown in the hash for the url (similar to jquery mobile’s navigation structure). When the user navigates to a different page, what’s actually happening is sharepoint determines what the differences between the first and second page are and only downloads and renders those differences. This saves bandwidth for the server and processing for the browser, especially for sites that have things like top and side navigation elements that don’t really change from page to page.
In my experience thus far, the SPSecurityTrimmedControl doesn’t work properly when used with the Minimal Download Strategy. It seems that because the user is really sitting on a page in the _layouts directory on sharepoint, the permissions for the user are incorrectly reported. In my scenario, I had a site collection that had anonymous access enabled and I only wanted to show the top ribbon to any user that is authenticated. This worked great in my development environment (in which I had disabled the MDS), but once moved to the test environment it stopped functioning. It reported EVERYONE as authenticated, whether they were logged into the site or not. After much frustration, simply turning off the MDS fixed the issue.
It’s my conjecture that because the start.aspx page lives in the _layouts directory, the SPSecurityTrimmedControl got confused since the user was ALWAYS residing within the _layouts directory, no matter what page the user was actually “on”. Either way, disabling the Minimal Download Strategy fixed the issue at just the cost of a little bit extra bandwidth.