Wednesday, November 7, 2012

Hijinks with security trimming links

My company has two main web applications, one that is our main collaboration space, and one that is just a playground for HR, more or less. We don't use Publishing on our main site, but HR makes heavy use of publishing on their web application, so that they can circulate and approve draft announcements and the like.

I was charged with making several "benefits portals" for the different territories our employees work within. We already had one for the US, so cloning this out to the other territories was no problem at all. I got a list from HR of what employees were full-time and in which territories, so I set up matching AD groups and SharePoint groups, and the security was all taken care of.

One wrinkle - a new hire browsing the HR site found the benefits portals (which apparently were not ready to be launched yet), and was able to see more than one. I duped her account and sure enough, there it is plain as day, but when I click on the link, I get denied access. That's good, but it's still weird that the link even shows up.

It turns out that the reason why the link is present is because the target had never been published, so there was never a target URL to check for security access. Thus, the security trimming check fails, and so SharePoint treats the link like an external URL and displays it. I assume this also applies to documents with no checked-in version.

So, be aware - if security is the name of the game and even revealing the existence of a document is of issue, then make sure you don't run afoul of this little issue.

No comments:

Post a Comment