0
votes

I was wondering is there any way to enable anonymous access to some specific SiteCore content item? Assigning read permissions to extranet\anonymous for the item through Sitecore admin - doesn't help...

[UPDATE] In access viewer I ensured that extranet\anonymous has read access to required item. In site definition I use extranet domain for my site:

<site name="website" hostName="mytest" patch:before="site[@name='scheduler']" virtualFolder="/" physicalFolder="/" enableAnalytics="true" rootPath="/sitecore/content/My Test" startItem="/Home" database="master" filterItems="true" domain="extranet" allowDebug="true" cacheHtml="true" htmlCacheSize="10MB" registryCacheSize="0" viewStateCacheSize="0" xslCacheSize="5MB" filteredItemsCacheSize="2MB" enablePreview="true" enableWebEdit="true" enableDebugger="true" enableWorkflow="true" disableClientData="false" loginPage="/login/Login.aspx"/>
3
What is the current user when you're trying to access the item? Have you looked at the "Access Viewer" to verify that extranet\anonymous has effective permissions?Steve McGill

3 Answers

3
votes

I can think of two reasons why "assigning read permissions to extranet\anonymous doesn't help":

Issue A: The requirements or architecture of your site means that permissions aren't helpful to solving this problem.

For example, a situation where you want an item to be secured most of the time, but need to allow anonymous users to read a summary of it before they have authenticated correctly.

Here you can use code to override the user context being used to load the item. The simplest, but most dangerous approach is this:

using (new Sitecore.SecurityModel.SecurityDisabler())
{
    var item = Sitecore.Context.Database.GetItem("/path/to/item");
    // further processing
}

That just turns off Sitecore's security enforcement inside the using statement. Hence the danger. Don't put anything that's really security sensitive inside that block.

Alternatively you can change the security context to a different user for the duration of a block of code with

var user = Sitecore.Security.Accounts.User.FromName("domain\username", false); 
using (new Sitecore.Security.Accounts.UserSwitcher(scUser))
{
    var item = Sitecore.Context.Database.GetItem("/path/to/item");
    // further processing
}

This is the preferred approach - as you are still using security - just temporarily for an account with more rights than the context user.

Issue B: Permissions should be the right answer for your solution, but do not work in this case.

If this is the case, it's pretty much impossible to address your problem without more details of your Sitecore install and what your site is trying to do. If this applies to you then you may do better to talk to Sitecore Support to diagnose why the user rights are not being correctly applied in your site. They will be able to look at your configuration, code and log files to try and work out the underlying issue.

1
votes

It depends on your site definition what user will be used when accessing the item while unauthenticated. Are you sure that extranet\anonymous is being used? Because there are following users that are possibly being used (from most likely to least likely):

  • built-in\anonymous (a virtual user which is assigned to any unauthenticated visitor viewing a Web site that does not have an explicitly assigned domain)
  • extranet\anonymous (a user which is assigned to any unauthenticated visitor viewing the default Web site)
  • sitecore\anonymous (a user which is assigned to a visitor when accessing the Sitecore login page)

EDIT 07/05/2014

I have also noticed that default\anonymous is used. It's not described in the documentation as the above users. Let me know which user was being used.

0
votes

Resolution: Remove extranet/anonymous deny read permission from "sitecore" element in the content tree.

To prevent anonymous access to the whole site you can just use "sitecore/content" element.

To allow anonymous access to any child item - assign read permission to anonymous user from the site domain. In my case it was extranet/anonymous.

I wonder is it bug or feature. Anyway, I'm happy that I found the solution.