-
-
We do most our SharePoint development based on ASP.NET WebForms and UserControls. WebParts are only used to host UserControls and pass information between them using Connections. WebForms are frequently used as PopUp windows triggered by the UserControls.
In some scenarios you will want to set a different user account authentication for the popupwindows. SharePoint uses default Windows Authentication In our case we needed to have extended permissions to enable a popupwindow to display users from Active Directory using the DirectoryEntry and DirectorySearcher objects in System.DirectoryServices namespace. For regular ASP.NET applications this is usually trivial, and we made it work fairly quick when only running the ASPX'es from the vdir and not in SharePoint context.
The problem is related to the "double-hop" issue described in detail (with more links) by nuno here. We tried out the suggestions made by this Microsoft KB HOWTO. We configured IIS to use a authorized user for the pages that needed to access DirectoryServices (in IIS Manager- File Security - Anonymous Access - Account used for anonymous Access), but for some reason this caused the ASPX'ed to no longer recognize postbacks. There are many possible explanations for this, but considering the extra deployment effort in adding stuff to the IIS metabase we wanted another solution.
The trick is to set special impersonation for the pages that need extra authorization. In the web.config file that applies for the WebForms we added the following lines in the <configuration> element:
<location path="ASPNETVDir/SubDir/Popup/WebFormThatNeedsToAccessAD.aspx">
<system.web>
<identity impersonate="true" userName="SPSADUser" password="pwd" />
</system.web>
</location>
This ensures that the page will run with the correct user to have authorization to use DirectoryServices. Another thing to remember is that this user also needs permission to use and run the appropriate files of your web application, so make sure of that aswell.
-
-
Have you ever noticed that your international characters, like our norwegian æ ø and å, just seems to disappear completely from Sharepoint pages and other content (ASP.NET UserControls etc) that are hosted in the Sharepoint context. It is related to the globalization settings for the Sharepoint site.
Edit the Sharepoint web.config file to reflect your local settings (utf-8 does not work for us norwegians):
<globalization fileEncoding="iso-8859-1" requestEncoding="iso-8859-1" responseEncoding="iso-8859-1" />
Maybe Microsoft should consider setting this property for us when we install a Norwegian version of their software?
-
-
Some things are just not obvious, or maybe I am just getting spoiled. Well, I just spent a couple of hours trying to figure out why Sharepoint didn't bother to persist my changed WebPart Title property through postbacks. First I thought this was due to my UserControl approach, and was caused by the ASP.NET UserControl beeing routed around Sharepoints ISAPI stuff.
Then I noticed that the main property of my webpart, which is a WebPart Connection Consumer class btw, was reset on postback. My Cell Provider webpart calls the consumer correctly and the property CompanyID which is marked with the attribute WebPartStorage(Storage.Personal) is set in the CellReady eventhandler of the consumer. I naturally assumed that this would be stored in Storage.Personal because of the attribute marking.
Enter protected bool WebPart.SaveProperties. Nuff said...