Content Query WebPart(CopyUtil.aspx) and Anonymous Access on your site

Content Query WebPart (CQWP) is a great little webpart, which lets you display any content from any level of your site on a webpart page. The problem with this webpart is that it was not designed for anonymous access, at least not completely. O.



If you have a site enabled with anonymous access and if you drop this web part on a page. you will notice that this webpart shows the contents to anonymous user correctly however when you click on any of the list item(hyperlink), It will challenge you to enter windows credentials or you will get "403" forbidden error.

After examines I found that Content Query Webpart usages copyutil.aspx page in layouts folder which in turn redirects to appropriate edit form depending on the type of the list. That's where the problem lies.

The "CopyUtil" class inherits from a generic class called "UnsecuredLayoutsPageBase". This class has a property called AllowAnonymousAccess . Which the inheriting class should override and set it to the true or false based on how web application is configured







Workaround:

1) Override the ContentQuery Web Part's XSLT and instead of using copyutils.aspx use the "dispform.aspx"

2) Create a cusotm copyutil.aspx page and override the AllowAnonymous property

FBA and friendly display name in SharePoint 2007

If you have ever implemented the form authentication(FBA) in SharePoint, you will soon experience that SharePoint treats non AD authentication as a step child. Though , its very simple and straight forward to implement a form based authentication however it is not the same user experience as you would expect or see with Active Directory based authentication.

One thing immediately becames visible is the user name. When you log with Active Directory you see a friendly name like shown below.

However , with the form authentication you see the loginId and NOT the FirstName & Last Name, you would like to see.The reason is simple. The standard MembershipUser interface, only has one property called "UserName", This properly holds the fully qualified user name ( domain/username) or (membershipprovider/userId) .

So how do we display a friendly name? After investigating, I came up with two options.

1) User Profile (MOSS Only)

It appears that SharePoint read the friendly display name from the user profile of a user if one exists. By default there is no user profile created for FBA. You can manually create a user profile for all users via SSP or programmatically create for all users.

I found following utility by Sahil , which takes a xml file and does bulk user profile import. Sahils' also shows a code snippet on how to programmatically create user profile

http://blah.winsmarts.com/2007-1-SharePoint_2007_Utility_-2_-_PI_-_Utility_to_Import-Export_actual_user_profiles.aspx

2) UserInfo table (WSS and MOSS)

This solution requires direct update to SharePoint table but does work. So I recommend carefully planning before any update.

At every site collection level, SharePoint stores the firstname + last name in the userInfo table . The friendly name is appears to be picked up from the tp_title column. I believe SharePoint creates entry in this table, the first time you add a user in any list or a site ACL. Look for your form authenticatation (FBA) userId in this table and replace it with a friendly name.

I think this is a good enhancement request for MembershipProvider and SharePoint team

Microsoft breaking its own rules of cookie security

In order to minimize the XSS vulnarabilites, Microsoft had implemented a "HttpOnly" cookie feature in IE 5.0 and above versions. This feature prevents other scripts or applications (e.g. applets) from directly accessing the cookie marked as "HttpOnly". Fair enough, though not everyone agrees that this really prevents any attack but I think its a good idea. ( http://www.gnucitizen.org/blog/why-httponly-wont-protect-you)


What is the relation of HttpOnly cookies with SharePoint? Well, as you know SharePoint 2007 is a ASP.NET 2.0 application, which means its utilizes all underlying features of ASP.NET 2.0 such as authentication and authorization. When ASP.NET authenticate user via form, it generates a cookie called ".ASPXAUTH" cookie. This cookie by default is marked as httpOnly, which mean no other applications should be able to access this cookie, including windows call such as InternetGetCookie (http://msdn2.microsoft.com/en-us/library/aa384710.aspx) which gets all cookies stored on your computer for a given site but respects the "HttpOnly" flag..

Office applications such as Word, Excel and SharePoint designer does not work well with Form Authentication but you can make it by setting the authentication cookie to persistent cookie. When you set the form authentication, the SharePoint login page has a check box to remember the userId/Password, this creates a persistent cookie, After this setting, if you open the Office applications, you are not prompted for authentication. If the Office applications are playing by rule and using the InternetGetCookie() method to get the cookies for a given url then they should not be getting the ASPXAuth cookie as this cookie is set as "HttpOnly" cookie by SharePoint/ASP.NET Form Authentication Handler? After monitoring the office appliations, I noticed that I office applications directly access the local cookie folder to read the cookies files.

My only guess is they are bypassing any standard windows call s and reading the temporary internet folder for cookies and parsing the cookies using undocumented features:) . Agreed, its a good feature to support the form authentication with office applications but directly accessing cookies is not something I expected specially after all the preaching they did on the securities

Your thoughts please?