SharePoint Sharpener

Obsessively Sharpening SharePoint

Archive for August 2008

Enabling Anonymous Access on an Internet-Facing MOSS Portal

with 3 comments

If you are using the publishing features of SharePoint on an internet-facing portal, you probably need to enable anonymous access.

It’s a quick two-step process:


A. Edit Authentication Providers

  1. Go to Central Administration and then Application Management.
  2. Under SharePoint Web Application Management click Web application list.
  3. Select the web application on which you want to enable anonymous access.
  4. Under Application Security select Authentication providers.
  5. Click the zone you want edit (probably Default).
  6. Check the box Enable anonymous access and click Save:



B. Enable Anonymous Access at Site Collection Level

  1. Go back to your site and go to Site Settings – at site collection level.
  2. Under Users and Permissions click Advanced permissions.
  3. In the Settings drop-down menu select Anonymous Access.
  4. Click Entire Web site (or whatever applies to your setup) and click OK:



Remember, hardening your internet-facing MOSS installation is essential to shield your portal against intruders.


Written by Thomas Sondergaard

August 28, 2008 at 11:39 am

ViewFormPagesLockDown Does not Kick In

with 3 comments

Hardening your internet-facing MOSS installation is essential to avoid attacks. Check out Microsoft’s excellent guide which takes you through most of the steps required to shield your portal against intruders.

However, if your portal wasn’t born as a publishing portal, all anonymous users will have access to AllItems.aspx, DispForm.aspx and other pages that you probably don’t want outside users to see. For instance, you may have created a newsletter signup web part which posts data to a list (using elevation). In time, the list fills up with more or less sensitive information about your newsletter subscribers and you probably don’t want this information to end up in the wrong hands.

Unfortunately, it is quite easy for someone with just a litte SharePoint experience to guess the path to e.g. the AllItems.aspx page of a SharePoint list:


And if your portal is not locked down, all list items will be there for the taking.



Stsadm comes to the rescue yet again. To activate the lockdown, simply run this stsadm command:

stsadm -o activatefeature -url <site collection url> -filename ViewFormPagesLockDown\feature.xml

If you get the “Operation completed successfully”-message, you’re in business.

Well, almost…


The final step

You’ll probably find that the new feature still hasn’t kicked in. Fear not, you simply need to deactivate and reactivate anonymous access on the portal.

Written by Thomas Sondergaard

August 28, 2008 at 9:59 am

Elevation: Run Code as an Administrator

with one comment

Sometimes you may need your web part to perform tasks for which the current user doesn’t have priviliges. For instance, we needed a sign up form for our WCM web site where the user could enter contact information that should be stored in a list.

Naturally, our web site runs with anonymous access and the the anonymous users do not have access to the underlying lists, including the list where the contact information goes.

Thus, submitting to the list is not just a matter of doing an Items.Add() because this causes a login dialogue to pop up and ultimately a 401 Unauthorized error.

Normally you’d create an element in the list with code similar to this:



However, if the logged-in user doesn’t have sufficient credentials to write to the list, a login dialogue will pop up.


Run with Elevation

To get around this problem you can use SPSecurity.RunWithElevatedPriviliges() like this:



For this to work, you need to instantiate the SPSite and SPWeb objects inside delegate():



Now the list will be updated with a new element, created by the system account.

Written by Thomas Sondergaard

August 27, 2008 at 6:56 am

Custom Properties in a SharePoint web part

with one comment

It’s simple, really. Whenever you install a web part, it probably needs a few settings to work properly.

Maybe the web part needs to know the name of a specific list to be able to gather information and display it to the user. Or perhaps it requires the email address of the person who should receive status updates from the web part.

In any case you want the web part to be able to store simple textual and persistant information to be used in your code. You may of course decide to store this information in, say, a SQL Server table but – unless you need to store vast amounts of information – this is overkill and makes installation of the web part unecessarily difficult.


Custom web part properties to the rescue

You can add your own properties to the tool pane which appears when you access the settings of a web part in the browser. You can even make your properties appear in its own section, like this:



To achieve this, first add the following namespaces to your web part code:



Then, for each property you need, insert a code block similar to this:



Note that Category, WebDisplayName and WebDescription are optional but they do make your custom property much more readable for the end user.

In the above example, propEmail contains the default value of the property.

Written by Thomas Sondergaard

August 4, 2008 at 1:21 pm