A lot is written on SharePoint impersonation.One of my collegues Victor Vogelpoel wrote a whole series of blog posts on this topic with a whole bunch of implementations. Using all his described implementation methods one thing was still not possible: check if a user is in a certain role. You need to become admin to do this check, but impersonation by going back to the application pool account (which is also a SharePoint administrator account) as described by Victor is still not good enough for checking roles. Raphael Londner has a blog post on how to achive a kind of impersonation that should be powerful enough in his weblog post SharePoint impersonation using COM+ Components. I did not check it out yet, but it looks promising. Thanks Rui for pointing this out to me!
- The number of possible simultaneous connections in a browser
- IE browser has memory leaks when doing complex operations
By default a browser supports only up to 2 simultaneous connections as described by Michael Schwartz in this blog entry. It is possible to increase this amount through a registry setting. Good to increase the amount of simultaneous downloads, but not something you can count on in yor application. This means that you should really watch out in implementing multiple separate XmlHttpRequests from your web page. Although I assume that calls are just blocked when the “request queue” is full, and will be executed when a previous request is finished. I thought that applications in Flash could work around that limitation, but as far as I know Flash utilizes the browser HTTP stack, so will probably suffer from the same restrictions (can someone confirm this?).
IE memory leaks:
Something that really “shocked” me a while ago was this weblog post by (again) Michael Schwartz. He describes memory leaks with XmlHttpequests in sites like http://www.start.com. I didn’t hear much about it after that post, until I stumbled over a blog entry by Telerik (the developers of the great WYSIWYG HTML editor). They describe IE memory leaks, and some tips on how to avoid them. They link to this article at http://quirksmode.com with more pointers to information on IE memory leaks.
Lets hope that implementations like Ajax.Net, MagicAjax and Atlas and all the other Ajax libraries work around these issues so we simple developers don’t have to take care of all the quirks that the different browsers will definitly have. This is one of the reasons why Flash looks so interesting: one vendor, so probably the same bugs on all platforms;-)
In a previous post I described an issue I had with WSS SP2 running on the .Net 2.0 Framework.
The issue is that in unghosted pages (pages modified through FrontPage, and therefor having a copy of the modified site definition page ending up in the database) it is not possible to add web parts through the web interface. It is still possible through FrontPage though.
Sources from within Microsoft confirmed that this is indeed a known issue.
For now there are the following solutions:
- Continue running WSS on Everett (funy that Microsoft keeps using the code names for there technologies;-) This means; the .Net 1.1 Framework)
- Reghost* the page (if this is possible, FrontPage should’t have made changes to the page itself, only to web parts and their connections)
- Use FrontPage to add web parts for these unghosted pages. One ceveat however: this only works for shared web parts, it is not possible to work with personal web parts through FrontPage.
Lets hope that Microsoft will come out with a hotfix for this issue, so all out trouble will be over. In the mean time: be careful what you edit with FrontPage and don’t mind about to be only editable through FrontPage, and what must be modifyable through the web interface.
*Reghosting can be done through the GhostHunter web part.