Hi Chris, We have exactly the same behaviour with a subsite collection doing all the right things. Settings are identical and I can't for the life of me work out why. ViewFormpagesLockdown is disabled, anonymous access is set sitewide - and yet anonymous users CANNOT directly access anything in _layouts and are not able to view list form pages with explicit access enabled on the list.
I wound up deleting that site as an aberration after extensive testing to find the cause. Some sources believe it was the combination of enabling anonymous access for Lists and Libraries, then deactivating the feature, then changing access to sitewide... In the end I never cracked it. If you ever work it out I'd love to know the answer; especially if you can get it working for a root site! Regards, Paul -- Online Developer/Administrator, ICT Projects Team CEO Sydney From: [email protected] [mailto:[email protected]] On Behalf Of Chris Howell Sent: Tuesday, 23 November 2010 12:20 AM To: ozMOSS Subject: Re: Help with 401 errors on public site Hi, Thanks for all the responses. Still working my way through them and need to discuss with my colleague who I'm working with on this issue. Strangest thing we've found now is that we actually have a sub site that exhibits the behaviour we would like but need to get to the bottom of why this sub site does it but not others. Will keep digging and let you know what we find/come up with. Cheers, Chris From: Paul Noone <[email protected]<mailto:[email protected]>> Reply-To: ozMOSS <[email protected]<mailto:[email protected]>> Date: Mon, 22 Nov 2010 08:29:38 +1100 To: ozMOSS <[email protected]<mailto:[email protected]>> Subject: RE: Help with 401 errors on public site Hi Chris, There is no way around this without writing a customer provider. We hit the same issue and the decision was made to disable the feature to return normal functionality and access to much needed list forms by users and search botsalike. There were two caveats around this: 1. Modify all list views to remove Modified and Checked-Out fields to alleviate some of the privacy concerns. a. I strongly suggest a coded solution using a provisioning feature at site creation. b. We additionally purchased a solution that allows us to permission fields. 2. Hiding the View All Site Content page. a. Still haven't got around to this because I can't find a simple solution that doesn't involved modifying the OOTB page. b. Am considering creating a new page that requires authenticated users and replacing the link to viewlsts.aspx with the new page. Would be interested in hearing what solution you ultimately apply. Regards, Paul -- Online Developer/Administrator, ICT Projects Team CEO Sydney From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Chris Howell Sent: Saturday, 20 November 2010 11:21 AM To: ozMOSS Subject: Re: Help with 401 errors on public site James, Thanks for the response. AFAIK we are using the ViewFormPagesLockDown feature. Some work was done previously with permissions but as I understand it, that only resolved issues for internal staff accessing the site; the problem still remained for external anonymous users. Cheers, Chris From: James Boman <[email protected]<mailto:[email protected]>> Reply-To: ozMOSS <[email protected]<mailto:[email protected]>> Date: Thu, 18 Nov 2010 23:53:57 +0000 To: ozMOSS <[email protected]<mailto:[email protected]>> Subject: RE: Help with 401 errors on public site I know it might not be immediately helpful, but on the topic of 401's in Internet facing sites there is something to be to be aware of that might be contributing to your 401 woes... If you use the ViewFormPagesLockDown feature (as all public facing MOSS sites should) it has security ramifications such that if you break security inheritance at the list or item level, Anonymous Internet users will lose access (regardless of the permissions granted), and be presented with 401 errors. It doesn't matter if you specifically grant access to the items/lists, and toggle the Anonymous setting - Internet users will lose access if the Special Permission level is not inherited. So for Internet sites you must choose between * Enabling the ViewFormPagesLockDown feature and living with web level security only * Not using ViewFormPagesLockDown and having all your system forms available (like View All Site Content) I logged an incident with Microsoft Support - and got the "By Design" resolution. Cheers, James. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Chris Howell Sent: Thursday, 18 November 2010 3:19 PM To: ozMOSS Subject: Help with 401 errors on public site Hi, We have a public facing internet site and we're seeing a lot of 401 errors in Web Trends. The errors are occuring for links such as: http://www.oursiteurl.au/Pages/ We've got a couple of questions that we're looking to resolve so was hoping to get some input from the list. 1. How do we find any links that exist within the site that are linking directly to a /pages/ link as it appears that somehow people are being taken to this from a link but we're not aware of them; all links we can find are to a specific page within the library. 2. How have people implemented work arounds at the /Pages/ level to redirect to the default.aspx page in the library and avoid a 401 error? I've found somesites; the WA one being a very good example (http://www.westernaustralia.com/au/Pages/Welcome_to_Western_Australia.aspx) where this is done. Anyone on the list had any involvement with that site or others and could share info or point to resources? Thanks in advance. Chris _______________________________________________ ozmoss mailing list [email protected]<mailto:[email protected]>http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss _______________________________________________ ozmoss mailing list [email protected]<mailto:[email protected]> http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss
_______________________________________________ ozmoss mailing list [email protected] http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss
