Support for Rewrites and Redirects on SharePoint

If you use Microsoft SharePoint versions 2007, 2010 or 2013 and also use URL Rewriting techniques, you should review this Microsoft Knowledge Base article:

Supportability of Rewrite and Redirects with SharePoint 2007/2010/2013

According to the article, if you change the path of the URL (the part after the domain, e.g. /pages/home.aspx) received by IIS and send a different one to SharePoint (called asymmetrical URL rewriting in the article) you are unsupported.

If you send the same path of the URL received by IIS to SharePoint, then you run a supported scenario.

 

Why is it important? – you might ask.

It is important because when you run into issues on your implementation and you don’t find a good solution “googling” around, you might have to call Microsoft for support and their answer for you might be: “you’re running an unsupported scenario.”.

In my case, we ran into issues with AXD files not being sent to the browser by SharePoint and the issue looks to be related to both the URL rewriting and the output cache. for now we disabled the output cache as a workaround and it seems to working fine. Let’s see if we can find a good solution for this issue. I’ll probably write more about it here when we figure it out.

If you use any type of URL rewriting on SharePoint or are planning on doing it, you should this article out.

 

See you,

Amadeu.

 

 

Advertisements

How to Recycle an IIS Application Pool Using a Command Line

Use the following command line in order to recycle an application pool on IIS 7:

[system drive]:\windows\system32\inetsrv\appcmd recycle apppools /apppool.name:”Your Application Pool Name”

 

Works like a charm.

 

See you,

Amadeu.

Showing/Hiding the Ribbon Based on Permissions

I’ve got a task to check why the ribbon was not being displayed for a user with full control on a page on a SharePoint 2010 Publishing site.

Requirements-wise the request made total sense: the user with full control permissions on a page should be able to see the ribbon, check the page out, edit the page, check it back in and publish it. During my tests I noticed the master page had a SPSecurityTrimmedControl control around the ribbon. This control was preventing to ribbon to be shown for the user because it was configure to only show it for users with ManageWeb permissions.

<SharePoint:SPSecurityTrimmedControl
ID=”TrimRibbon”
PermissionsString=”ManageWeb”
runat=”server”>

Checking the list of SPBasePermissions values for the PermissionString property I was able to find the permission I wanted to use: EditListItems. This way all users with permissions to edit items/pages can see the ribbon.

When I changed the SPSecurityTrimmedControl control to use the EditListItems permission and published the master page, the user was still not seeing the ribbon.

After a couple of tests using different permissions, I found an article by Infowise explaining  the details of the SPSecurityTrimmedControl control and the usage of the PermissionContext property. This property controls the scope of the PermissionString property and by default is uses CurrentSite. Some of the values of the SPBasePermissions are scoped to the List or List Item.

In order to my permission check to work, I had to add the PermissionString property to the SPSecurityTrimmedControl control using the CurrentItem value:

<SharePoint:SPSecurityTrimmedControl
ID=”TrimRibbon”
PermissionsString=”EditListItems”
PermissionString=”CurrentItem”
runat=”server”>

After this change, the user was able to see the ribbon on the pages he had full control permission on and the site admins are still able to see it.

 

During my research, I also found this other article explaining a little bit more of the SPSecurityTrimmedControl control. Worth to check it out.

 

 

See you,

Amadeu.