Hi

I seem to have a poblem which I thought I fixed.  Basically an anonymous user can view the shop items presented in ShopHome.aspx but when the title is clicked the GET is redirected to the login screen.

I thought I fixed this when I noticed one product out of the 10 I have setup did not re-direct. the difference between that product and the others was that it did not have a manufacturer assigned.  When I assigned one I noticed that it too redirected to login.

So, I investigated a little more and found the 'Associate Users' property sheet.  I added the anonymous CS user and it appeared to have fixed the problem.

Unfortunately the problem has returned.

Any suggestions - things I have missed.  I will admit that my reading of the manual has been a little speedy!

Thoughout community server redirection to access denied can occur due to a multitude of issues.  Can you tell me what changes you have made to the theme page (if any) and also what is being reported in the event and exceptions logs (if any)

Cheers,
Rob

Ah, well we have made lots of changes.  Basically chopping code blocks from one area to another.  Incorporating large portions of the ShopHome.aspx code in to Home.aspx within Themes\[OUR_THEME]\Common

Links from the product descriptions within Home.aspx point to the original \Shops\ folders and from there on the shop runs as you guys coded it.

Exceptions excerpt:

User Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.0.
Path: /themes/shops/tchbasic/shopItem.aspx?App=the_community_host&PostName=Graffiti-CMS-Small-Business-Edition as HTTP GET
Referrer: /
Message: Associate action not permitted by security provider
CommunityServer.Components.CSException: Associate action not permitted by security provider
at FourRoads.CsShop.Core.Components.Security.AssociateSecurityCheck.WillDo()
at FourRoads.CsShop.Core.Components.Associate.AssociateCRUD.GetAssociate(Int32 sectionID, Int32 associateID, Boolean useCache)

I cut that short...it goes on for ages ;-)

Any pointers?

Just a quick note to say my workaround to this issue is to not select a manufacturer for a product.  However it would be nice to know if the permissions issue is caused by a mis-configuration or an undocumented feature.

Having looked at the code I belive we have applied an incorrect security check against this object and have clamped down the security to the Manufacturer too much.  I have added this to our defect list and it will be corrected in the next release.

Regards,
Rob