Anonymous access prompted for login after click in web part area on publishing portal

Currently I'm experimenting with publishing portal and the ability to use it for publicfacing internet sites where anonymous access is allowed. In the site permissions I gave the anonymous users access to the entire website.
Afterwards I created a custom list named 'Test' and entered three simple items with just the title-field filled.

On the default.aspx of the publishing portal I added a ListVievWebPart to the 'Test'-list and published it.

Now if the anonymous user loggs in, he sees the default publishing page with that LVWP and three items in it.But if he clicked on an item, the login-popup appeared. Also if I tried to break the list-permission-inheritance from the web, the list items would open but the first click in the webpart resulted in that nasty login-popup.

So what to do? A lot of pages, blogs and forums on the internet suggest to deactivate a hidden feature called 'ViewFormPagesLockDown' to allow anonymous users to have access to list-items.
Another approach I found on several pages was to remove the coupling to the code-behind in the file wpribbon.aspx on the _layouts-folder directly to workaround the other problem.

I didn't like neither the first nor the second way. The one kills the security concept, the other transgesses the rules of Microsoft by changing files directly on the server.

So I grabbed good old SharePoint Manager 2010 and examined the 'Test'-List where I detected the AnonymousPermMask64-Attribute that had this string set by default: ViewListItems, ViewVersions, Open, ViewPages, UseClientIntegration.

This had to be the key to solve the problem... I went to the MSDN-Article describing all SPBasePermissions-enum-values and found... ViewFormPages (View forms, views, and application pages, and enumerate lists).

Okay, rest was easy... If there is a feature activated on publishing-portal called ViewFormPagesLockDown that prevents the anonymous user from entering formpages, then the basepermission ViewFormPages perhaps grants access for the element.

So I programmatically broke the inheritance of the list-permissions and reset the spbasepermissions to the AnonymousPermMask64-Attribute as you can see in the following code-segment and everything worked as I imagined:



SPList spList = spWeb.GetList("/Lists/Test");

spList.BreakRoleInheritance(false);
spList.AnonymousPermMask64 =
 SPBasePermissions.ViewListItems |
 SPBasePermissions.ViewVersions |
 SPBasePermissions.Open |
 SPBasePermissions.ViewPages |
 SPBasePermissions.UseClientIntegration |
 SPBasePermissions.ViewFormPages;

spList.Update();