Security trimmed SiteSettings page

A couple of days ago I posted about the "Manage web site" option in the "User Permissions for Web Application" section of the Central Admin. If we unchecked that option we saw that a lot options disappeared in the Site Settings page for users who have Full Control and this was the desired case in our environment. Unfortunately a lot of unexpected errors occurred because of the removal of permissions. Not only the permissions were removed from the users but also from the service accounts on which SharePoint runs. So the conclusion was to enable it again to maintain functionality and just have to deal with less strictly managed sites.

But! Today I found the solution.. it seems that the Site Settings page is just a feature as well and you know what you can do with links that are controlled by features.. Yes! You can security trim them! So in order to remove the links from the Site Settings page you just open the sitesettings.xml (\12\TEMPLATE\FEATURES\SiteSettings) and the following bit to each link : 'RequireSiteAdministrator="TRUE"'

So the 'Site Features' link (one of which we don't want the user to play with) looks like this:

<CustomAction
        Id="ManageSiteFeatures"
        GroupId="SiteAdministration"
        Location="Microsoft.SharePoint.SiteSettings"
        RequireSiteAdministrator="TRUE"
    Rights="ManageWeb"
        Sequence="80"
        Title="$Resources:SiteSettings_ManageSiteFeatures_Title;">
        <UrlAction
            Url="_layouts/ManageFeatures.aspx" />
    </CustomAction>

 

And here is the tricky part.. at least.. it feels really tricky.. you will have to uninstall the site settings feature using STSADM and install it again for the settings to take effect

STSADM -o uninstallfeature -name sitesettings
STSADM -o installfeature -name sitesettings

There you have it! A trimmed Site Settings page without having to unchecking the 'Manage WebSite' option. Although with URL hacking you can get there ofcourse so it's not really bulletproof (although, you can edit the .aspx pages and put a SPSecurityTrimmedControl around it)

SPGridview and collapsed grouping by default!

This really bugged me when I came across the SPGridView (as you can read in the previous about this control) that when you set the following properties

oGrid.AllowGrouping = true;
oGrid.AllowGroupCollapse = true;

You'd expect that there is another property where you can specify if you want to have it collapsed or expanded when the Grid gets rendered. Unfortunately there isn't.. but (and that's why I'm posting ;)) there is dirty way to do it and that's injecting some javascript after the grid gets rendered. Thanks to my collegua Servé "CSS/HTML & Javascript Wizard" Hermans the following bit of script gets the job done.

<script type="text/javascript">
var rows = document.getElementsByTagName('tr');
var numRows = rows.length;
for (var i = 0; i < numRows; ++i) 
{
    if (rows[i].getAttribute("isexp") != null && rows[i].getAttribute("isexp").toLowerCase() == "true")
    {
          if(rows[i].firstChild.firstChild != null && rows[i].firstChild.firstChild.tagName.toLowerCase() == "a")
          {    
              if (rows[i].firstChild.firstChild.title.toLowerCase() == "expand/collapse")
                  {
                    rows[i].firstChild.firstChild.fireEvent("onclick");
            }
          }
    }

}
</script>

To explain it the script.. an event called "ToggleSPGridViewGroup" (which can be found in the spgridview.js in the Layouts folder) is fired when you click on the expand/collapse icon on the grouped item. So I thought "Why not fire all of the links to have it all collapsed by default?" :) I thought this wasn't possible since it seems REALLY dirty to actually fire events without user interaction. But it actually is possible! Thank god ;)

Technorati tags: MOSS. Development, WSS

Self-Service Site Creation and permissions

Yet again a post about permissions! This one is about the self service site management feature that you can enable in the Central Administration page near the Application Management and then right here :

So you enable it and click on "OK" just like the screenshot below :

Next you want to create a site using the 'scsignup.aspx' page and there you get an access denied error and SharePoint wants you to login with a user who has sufficient permissions to perform this action. So I checked the eventlog for any errors and found the following :

The site /sites/<sitename> could not be created.  The following exception occured: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)).

And then it hit me.. we unchecked the "Self-Service Site Creation permission" in the "User permissions for web application" (see screenshot below at the bottom) :

So I checked it and tada! We could create sites using the Self-Service Site Creation page!

Now this all makes sense ofcourse although I figured that once you enabled it, the permission would be turned on automatically or an error would be raised to inform you that you need to make sure that the permission is set.

Hopes this helpes someone ;)

 

Technorati tags: MOSS, Support

Permissions and workflow

In our environment we unchecked in the 'User Permissions for Web Application" the following option "Manage Web Site  -  Grants the ability to perform all administration tasks for the Web site as well as manage content. " By doing this we see the following difference in the Site Settings page :

Manage Web Site : Checked

Manage Web Site : Unchecked

So if you see the 'unchecked' sitesettings page, a site owner for example cannot manage features or delete his own site. This is in our environment is very desirable since site owners are not administrators but 'just' users. Therefore giving them the least amount of privileges is a must (so they can't destroy their own site ;)). It's like deploying workstations and giving the user not administrators permissions on their desktop.

But! When a user is trying to start a workflow the keeps getting the "Operation in progress' screen and in the eventlog of the front-end server the following error occurs:

Event code: 4011
Event message: An unhandled access exception has occurred.
Event time: 8/27/2007 8:23:07 AM
Event time (UTC): 8/27/2007 6:23:07 AM
Event ID: 14b3855a81684973a4ede892d8c82298
Event sequence: 354
Event occurrence: 2
Event detail code: 0
Application information:
    Application domain: /LM/W3SVC/1574755854/Root-3-128326491020874251
    Trust level: Full
    Application Virtual Path: /
    Application Path: d:\Inetpub\wwwroot\wss\VirtualDirectories\80\
    Machine name: <machinename>
Process information:
    Process ID: 2280
    Process name: w3wp.exe
    Account name: <accountname>
Request information:
    Request URL: <url>/_layouts/IniWrkflIP.aspx?List=5fa2c8f9-d6df-4ba5-af1c-960cab0b15d5&ID=4&TemplateID={463a6ced-0731-4180-9626-2ccce20551a7}&Source=<url>
    Request path: /_layouts/IniWrkflIP.aspx
    User host address: 172.16.46.2
    User: <accountname>
    Is authenticated: True
    Authentication Type: Basic
    Thread account name: <accountname>

So what does this say? Well, it tells you that the process hasn't got sufficient permissions to perform the action. So if we check the option "Manage Web Site" again, the error won't be raised and the workflow will work just like it should. In my opinion this is bad.. very bad.. I reckon that the process accounts (and thus the System Account) should be excluded from the Web Application permissions set. Since you assign permissions to the users of the web application instead of the system accounts.
And yes.. I have also set the service accounts having Full Control in the Policy for Web Application pages.

So if someone has the answer, let me know ;)

 

Technorati tags: MOSS, Support

QuickLaunch and workspaces

Ever noticed that you don't have the QuickLaunch available when working with (meeting) workspaces in 2007? Even though you checked the option to enable it, it's still not there! Well fear not since Servé Hermans made it visible.. how? Well read it at : How to enable Quicklaunch on multipage meeting workspace  and you might having this as well, pleasing yourself and your users in the quest for more userfriendliness;)

Technorati tags: MOSS, Customize