SharePoint Access Checker and DeliverPoint</h1> <article> <h1>SharePoint Access Checker and DeliverPoint</h1> <p>Paul Schaeflein — Wed, 24 Sep 2008 19:21:00 GMT</p> <P>One of Microsoft's field engineers <A href="http://sharepoint.microsoft.com/blogs/fromthefield/Lists/Posts/Post.aspx?ID=57">posted about a community project, the Access Checker</A>. The project will show a site collection's hierarchy with an overlay showing if a specific user account has the specified permission. For an administrator, it is a very helpful tool.</P> <P>The blog post references DeliverPoint, and in fact we do help discover <A href="http://www.deliverpoint.com/PRODUCTINFO/DISCOVERACCOUNTPERMISSIONS/tabid/71/Default.aspx">the permissions of a security principal</A> (user or group) as well as the <A href="http://www.deliverpoint.com/PRODUCTINFO/DISCOVEROBJECTPERMISSIONS/tabid/72/Default.aspx">assignments on a securable object</A> (site collection, site, list, list item). I want to point out a few key differences:</P> <UL> <LI>DeliverPoint has a cache of your SharePoint farm, so we do not need to catch all the Access Denied exceptions</LI> <LI>This cache provides for much better performance</LI> <LI>DeliverPoint is security trimmed (just like SharePoint), so sites to which the target user does not have access are not shown. In addition, the permissions of the current user are considered as well. In other words, sites that the current user does not have the View Permissions right are not displayed.</LI> <LI>However, DeliverPoint has an "operator" feature that will override the current users permissions</LI></UL> <P>The Access Checker project has a very intriguing interface. Would you like to see this added to DeliverPoint?</P> </article> <article> <h1>SharePoint Best Practices Conference - site is up</h1> <p>Paul Schaeflein — Thu, 26 Jun 2008 10:12:00 GMT</p> <P>The website for the <A href="https://www.sharepointbestpractices.com/home">SharePoint Best Practices conference</A> is now up. Visit the site to see the agenda and register.</P> <P> </P> <P><A href="https://www.sharepointbestpractices.com/home"></A> </P> </article> <article> <h1>RunWithElevatedPrivilege recommendation</h1> <p>Paul Schaeflein — Thu, 05 Jun 2008 17:26:00 GMT</p> <P>Daniel Larson has been <A href="http://daniellarson.spaces.live.com/blog/cns!D3543C5837291E93!1919.entry">sending</A> <A href="http://daniellarson.spaces.live.com/blog/cns!D3543C5837291E93!1977.entry">smoke</A> <A href="http://daniellarson.spaces.live.com/blog/cns!D3543C5837291E93!1986.entry">signals</A> for the last week about using the RunWithElevatedPrivilege (RWEP) method. He finally goes into further detail today with his cautionary tale and a recommended <A href="http://daniellarson.spaces.live.com/blog/cns!D3543C5837291E93!1993.entry">SPUserToken work-around</A>.</P> <P>I have seen several programs that use RWEP to accomplish updates on behalf of a user. (In fact, I use the method in the <A href="http://www.codeplex.com/ImageUpload">Image Upload Web Part</A>.) In this circumstance Daniel is advocating using impersonation via the SPUserToken for the "System Account." I believe this to be sound advice and will be updating my code accordingly.</P> </article> </main></body></html>