Dev Team Assemble

Evil beware!
Add to Technorati Favorites

Archive

Tag: Security

Its seems that SharePoint has a knack for surprising me with seriously strange errors sometimes. Usually at the core of the error there is a sound explanation as to why this is happening but nonetheless I am not pleased with the obscurity of them sometimes. Case in point, while working on a Console application that would load FBA (Forms Based Authentication) users into a sharepoint sie collection and then create a site for each one (granting permissions and so on) I came across a very strange error - SPException: SharePoint cannot find the user.

This kind of surprised me at first and I was wondering if somehow my CustomMembershipProvider setup stopped working on my portal site, but that was fine. So after hammering away at it for a while I came across a great article written by Waldek Mastykarz on this exact problem.  After reading through his investigation it makes sense why it doesn't work in a console application but it works under the context of a SharePoint website. Essentially the web application has access to a context object and this has access to the providers node in your web.config file,  BUT the console application does not have this information available.  So when the SharePoint assemblies attempt to access this information they cannot because it does not exist.

The way around this is to create an HttpContext in your application before attempting to run SPWeb.EnsureUser("blah") like so:

if (HttpContext.Current == null) { HttpRequest request = new HttpRequest("", web.Url, ""); HttpContext.Current = new HttpContext(request, new HttpResponse(new StringWriter())); HttpContext.Current.Items["HttpHandlerSPWeb"] = web; }

Then add the system.web/membership/providers node to your app.config file (which you may have to create in the project)..  Mine looks like so:

<system.web> <membership> <providers> <add name="CustomSqlProvider" applicationName="/Portal" connectionStringName="sqlData" type="CustomProviders.CustomSqlMembershipProvider, CustomProviders, Version=1.0.0.0, Culture=neutral, PublicKeyToken=91a4fcd60b73a0e8" /> </providers> </membership> </system.web> <connectionStrings> <add name="sqlData" connectionString="Data Source=sqlpd; Initial Catalog=PUsers; Integrated Security=True; MultipleActiveResultSets=True " providerName="System.Data.SqlClient" /> </connectionStrings>

After adding this information and running a few tests it started to work. In fact it worked really well on my dev box...the only problem was it was a little intermittent on my production machine. Which is funny because the provider on the site itself works just fine all the time but in order to get my console application working (the EnsureUser() portion) the site would require an IIS reset. This is the one MAJOR stumbling block that I have yet to overcome...the only saving grace I have is that I can import the users manually into the system first using the UI and then run my console application that will load the sites and grant permissions to sites based on an external configuration file.

Many thanks to Waldek Mastykarz for all his help on this one so far...I know I will be coming back to this one in the near future but my head hurts a little and I need a beer.

Canadian SharePint event anyone?

Technorati Tags: , , , ,

Kudos to Scott Elliott a colleague of mine for putting this together...

Here is how I got my SQL Express to remotely respond to SQL Management Studio.

In SQL Server Configuration Manager:
Under SQL Server 2005 Network Configuration:
Protocols for

  • Enable Shared Memory
  • Enable Name Pipes
  • Enable TCP/IP

Under SQL Server 2005 Servers

  • SQL Server (ServerInstance) Properties

Log on as: Local System (have to restart)
SQL Server Browser

  • Log on as: Local System (may have to enable this service first in the Services MMC applet)

And with that, you should be able to remotely connect! Hazzah!

Technorati Tags: , , ,

http://[your sspname here]/ssp/admin/_layouts/searchsspsettings.aspx

This problem has to do with an issue that comes up after you apply a hotfix to your servers. Essentially it enforces new security rules. To resolve it add the Sharepoint service account to the Box Administrators, WSS_ADMIN_WPG and WSS_RESTRICTED_WPG. Once this is done reset your IIS and you should be good to go.

Props to Søren Nielsen for the following post:
http://soerennielsen.wordpress.com/2008/02/08/make-the-search-work-for-you/

Technorati Tags: , , ,

This is kind of of a weird error and it didn't make sense to me at first (still doesn't really). The best workaround I could find on the net was to temporarily change the application to run in the application pool of the central admin site.

Steps:

  1. Change the AppPool for the app to be the same as the Central Admin site (Home Directory tab in IIS website properties).
  2. Reset IIS or at the very least do an %systemroot%\system32\iisapp.vbs /a "apppoolname" /r (not sure if the iisapp.vbs method will work but cant see why not).
  3. Activate the publishing infrastructure.
  4. Set the app pool back to normal.
  5. repeat step 2.

Enjoy!

Technorati Tags: , , ,