Setting Up Your Anonymous Portal 转
Description:
One question I’ve seen quite a few times is: “How can I make my Portal available to the Internet?” In other words, how can I turn on anonymous access for my Portal? It’s actually not that difficult…just a few IIS and Portal settings, but you’ll also want to be able to manage your portal, which can be a little difficult without the proper planning. Setting Up Anonymous Access. 1. You’ll want to set your portal up for anonymous access. Go to your site settings for your portal and choose Manage security and additional settings. You’re then presented with another page of options – choose Change anonymous access settings. You can then choose to allow anonymous users access to Areas and content or Areas, content and search. 2. Go to IIS and on your properties for your portal web site, choose Directory Security. Choose the “Edit…” button under Authentication and Access Control. You’ll notice that “Enable Anonymous Access” is not checked, but Integrated Windows Authentication is checked. Check the Enable Anonymous Access option, but also leave the Integrated Windows Authentication option checked as well. I’ll explain why later on. You now have a site that can be accessed by all users, regardless of whether they have an active directory account on the SharePoint domain. In fact, all users come in as anonymous, whether or not they are part of the SharePoint domain. However, enabling anonymous access has two “side-effects.” First, you might notice that if you manually navigate to http://portalsite/_layouts/1033/default.aspx, you can access this page. This is the page that allows the portal administrator to administer the site. While it might seem that this is a BIG security hole, it seems that all actions from this page require the user to log in with the correct credentials in order to modify anything. They will be able to see your web part dwp files that are “installed” on SharePoint, your site templates and your list templates, but they cannot modify them without first entering valid credentials. I don’t know if there is much you can do about this; the directory in which this page resides needs to allow anonymous users because of some other files that are contained in there. For instance, there are many javascript files in the _layouts/1033 directory (.js) that SharePoint uses in the portal to which anonymous users need to be able to access (e.g. ows.js) in order for the pages to work properly. If the _layouts/1033 directory does not have anonymous access enabled, anonymous users will be prompted to log in to access these javascript files. The second “side-effect” is that you, as the administrator, will find it difficult to modify the pages. You can do something about this, but it requires a little programming AND it requires that you implement this before you turn on anonymous access. There is a class provided with the SharePoint object model called the Authentication Button class. This class allows you to create an Authentication button that, when clicked, will prompt users to login. They will then validate against the active directory and, if authenticated, allowed access to SharePoint as the logged in user versus an anonymous user. The details on this class are here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/spptsdk/html/smpcauthenticationbutton.asp. To implement this, simply create a web part and create an instance of the AuthenticationButton class and render it. Here’s the code that I’ve used: public class WebPart1 : Microsoft.SharePoint.WebPartPages.WebPart { private AuthenticationButton AuthButton; protected override void RenderWebPart(HtmlTextWriter output) { AuthButton.RenderControl(output); } protected override void CreateChildControls() { AuthButton = new AuthenticationButton(); Controls.Add(AuthButton); } } Furthermore, I create an area on my portal, which I usually exclude from the navigation structure, and put this web part on this area. I tell the people that should be able to log in to navigate to this area, where they can see my web part with the AuthenticationButton class implemented. They click the login button, enter their user name and password, and they’re in. However, there is one final setting that you need to make to your web.config in order for the AuthenticationButton class to work properly in the portal (this button wasn’t designed with the Portal in mind, but when you add this setting, it should work just fine). Add the following node under the <configuration> node in your web.config: < appSettings > < add key="SPS-EnforceIISAnonymousSetting" value="false" / > < /appSettings > Note: I received this last tip from Microsoft, but unfortunately I wasn't able to follow-up on what exactly this setting is doing. If you have any questions regarding this article, please feel free to use the discussion boards on this site or email me directly at ZandyG@Magenic.com
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/spptsdk/html/smpcAuthenticationButton_SV01014571.asp
One question I’ve seen quite a few times is: “How can I make my Portal available to the Internet?” In other words, how can I turn on anonymous access for my Portal? It’s actually not that difficult…just a few IIS and Portal settings, but you’ll also want to be able to manage your portal, which can be a little difficult without the proper planning. Setting Up Anonymous Access. 1. You’ll want to set your portal up for anonymous access. Go to your site settings for your portal and choose Manage security and additional settings. You’re then presented with another page of options – choose Change anonymous access settings. You can then choose to allow anonymous users access to Areas and content or Areas, content and search. 2. Go to IIS and on your properties for your portal web site, choose Directory Security. Choose the “Edit…” button under Authentication and Access Control. You’ll notice that “Enable Anonymous Access” is not checked, but Integrated Windows Authentication is checked. Check the Enable Anonymous Access option, but also leave the Integrated Windows Authentication option checked as well. I’ll explain why later on. You now have a site that can be accessed by all users, regardless of whether they have an active directory account on the SharePoint domain. In fact, all users come in as anonymous, whether or not they are part of the SharePoint domain. However, enabling anonymous access has two “side-effects.” First, you might notice that if you manually navigate to http://portalsite/_layouts/1033/default.aspx, you can access this page. This is the page that allows the portal administrator to administer the site. While it might seem that this is a BIG security hole, it seems that all actions from this page require the user to log in with the correct credentials in order to modify anything. They will be able to see your web part dwp files that are “installed” on SharePoint, your site templates and your list templates, but they cannot modify them without first entering valid credentials. I don’t know if there is much you can do about this; the directory in which this page resides needs to allow anonymous users because of some other files that are contained in there. For instance, there are many javascript files in the _layouts/1033 directory (.js) that SharePoint uses in the portal to which anonymous users need to be able to access (e.g. ows.js) in order for the pages to work properly. If the _layouts/1033 directory does not have anonymous access enabled, anonymous users will be prompted to log in to access these javascript files. The second “side-effect” is that you, as the administrator, will find it difficult to modify the pages. You can do something about this, but it requires a little programming AND it requires that you implement this before you turn on anonymous access. There is a class provided with the SharePoint object model called the Authentication Button class. This class allows you to create an Authentication button that, when clicked, will prompt users to login. They will then validate against the active directory and, if authenticated, allowed access to SharePoint as the logged in user versus an anonymous user. The details on this class are here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/spptsdk/html/smpcauthenticationbutton.asp. To implement this, simply create a web part and create an instance of the AuthenticationButton class and render it. Here’s the code that I’ve used: public class WebPart1 : Microsoft.SharePoint.WebPartPages.WebPart { private AuthenticationButton AuthButton; protected override void RenderWebPart(HtmlTextWriter output) { AuthButton.RenderControl(output); } protected override void CreateChildControls() { AuthButton = new AuthenticationButton(); Controls.Add(AuthButton); } } Furthermore, I create an area on my portal, which I usually exclude from the navigation structure, and put this web part on this area. I tell the people that should be able to log in to navigate to this area, where they can see my web part with the AuthenticationButton class implemented. They click the login button, enter their user name and password, and they’re in. However, there is one final setting that you need to make to your web.config in order for the AuthenticationButton class to work properly in the portal (this button wasn’t designed with the Portal in mind, but when you add this setting, it should work just fine). Add the following node under the <configuration> node in your web.config: < appSettings > < add key="SPS-EnforceIISAnonymousSetting" value="false" / > < /appSettings > Note: I received this last tip from Microsoft, but unfortunately I wasn't able to follow-up on what exactly this setting is doing. If you have any questions regarding this article, please feel free to use the discussion boards on this site or email me directly at ZandyG@Magenic.com
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/spptsdk/html/smpcAuthenticationButton_SV01014571.asp
浙公网安备 33010602011771号