As planned I have implemented the bulk edit mode for the grid view.

This is very inspired from this post from Matt Dotson, in fact the only difference is that it will save automatically on every page refresh instead of relying on a save button – this allows it to work in conjunction with paging and also not be affected when postbacks occur from other controls.

Compared to his article I had to implement these additional event handlers:

1. Grid.DataBinding: I call SaveGrid here to ensure the data gets saved before it is refreshed. This needs to be protected with a lock because UpdateRow may cause databinding to be performed as well
2. Grid.RowUpdated: set the KeepInEditMode to true – this prevents the grid from trying to rebind (so this should remove the lock requirement from the previous handler, but I kept it in to be on the safe side)
3. Grid.RowInitializing: this is an event I added to the grid, because otherwise there is no way to slip something into InitializeRow without actually deriving from the grid (my strategy with the grid view is to define feature “mix-in” modules that can be added to a stock (or in this case, “almost” stock) grid view. The problem if you derive from GridView every time is it becomes hard to combine those features… i.e. a classic problem of inheritance vs composition. Unfortunate that ASP.NET favors the former, but that is for another post)
4. Grid.PageIndexChanging: call SaveGrid here otherwise the data will be muffed when the user changes pages

The SaveGrid implementation is a bit simpler, since my DataSource control is completely disconnected so I can afford to call Update pretty often… for this reason I did not bother with keeping a “dirtyRows” list and instead update every single row in the datagrid.

In the end, it gives a pretty transparent experience to the user, something like this:

If you read over the installation instructions to enable the Windows authentication for the 7.2 web client, you will see that there is a fairly lengthy setup process – you need to setspn this and that, configure your users to use Windows authentication, and set up the Web server to run as a domain admin, no less. You know when I read that I could not believe they would actually recommend running IIS – seems like the most obvious point of entry for any attacker – as a Domain Administrator, but I suppose it is not that big of a step from their previous recommendation to run it as a Local Administrator. I may be weird but I like this stuff to run as either Network Service or some other reasonably lowly trusted user. So I had to peek at the implementation to see if it was really necessary and how to get around it if it was.

Now in general under ASP.NET enabling Windows authentication by itself is a pretty easy task. What is a bit more difficult is getting it to coexist with the regular forms authentication, so that some users will be directed to the Windows login page, some to the forms login page, and they will be accessing the same application. In Saleslogix they have a special HTTP module called MixedModeSecurityModule – it will intercept requests to the /Windows.aspx page and hijack the forms authentication process at that point. Basically:

1. User sends request to /Windows.aspx
   
2. IIS sends a 401 response to get the browser to pass credentials. There is a bit of trickery here – 2 HTTP modules around the forms authentication module, one to hide the 401 status and replace it with a 200, and the other one to restore the 401 status so it is sent to the browser (otherwise, the forms authentication module will catch the whole thing and redirect to login page)
   
3. Browser sends credential. As a side note I had a bit of trouble getting IE7 to send that automatically, if there is a dot in the site’s name it will assume it is in the internet zone and not pass them
   
4. MixedModeSecurityModule handles the FormsAuthentication “Authenticate” event and retrieves the SID using the LogonUserIdentity property of the request, connects to the database (more on this below) and checks whether the SID passed is associated with a user.
   
5. At this point it retrieves the user logon and password, decrypts the password, forms the connection string, and generates the FormsAuthentication cookie – the user is now properly set up.

No need for Domain Admin rights, right? Network Service will be enough since it will be able to identify the domain users.

There is one iffy step: the one where the module connects to the database to retrieve the user info. This is the step where the web site should use impersonation to connect to the Saleslogix server. Saleslogix would have you configure the whole web site to run as a privileged user, and, I guess that would work, IF the user was also enabled to log into Saleslogix – pretty radical, though. Seems like we have 2 options to get around it:

1. Use an actual user for the connection string that will check the Windows Authentication. I tried that one, hard-coding the credentials for Admin, and it worked – so I know that is possible. The credentials are also stored somewhere in the registry (lightly encrypted) if the Legacy web components have been configured (which is required for the mail merge anyway)
2. Use impersonation/delegation to pass the credentials of the user logging into the web site. This is kind of nicer because it doesn’t require us to dig for password, one drawback is the computer will have to be trusted for delegation… This is likely to be tough to get configured at customer’s sites so I am not going to look into it any further.

Either way, we have to replace the stock MixedModeSecurityModule class, and replace the GetUserPass method so that it will be able to connect to the database. The easiest way to make the change would be to paste the code from Reflector and add User Id and Password parameters to OleDbConnectionBuilder – so basically only 2 lines of code. The rest of the stuff looks a bit crusty (it seems like they tried a lot of different methods before settling on that one and forgot to clean up afterward) but it does work.

Finally, here are a few links that deal with the Mixed Mode authentication:

• ASP.NET Mixed Mode Authentication
  By Paul Glavich
• Mixed Mode Authentication (Ayende)
• An article from Paul Wilson about it – uses a different approach, which I think looks a lot cleaner – doesn’t require the HttpModule hackery and instead relies more on the built-in mechanisms.

If it was up to me I would like to rewrite it using the technique shown in that last link. But currently the Windows authentication is very intermingled with the rest of the login crap and I have seen too many times what happens to Saleslogix when you start pulling on one of the strings!

Updated (2007-03-18): this still works under 7.2.2. Here is the code for the security module helper I created (based on the one distributed by Sage). You will have to adjust the references to SSSWorld assemblies in order to be able to use it, though.

Well I finally bit the bullet and implemented the solution I discussed in my previous post on databinding by creating a new data source control. 2 comments:

1. It was ridiculously easy
2. It is fucking awesome

So now the code from my datagrid looks like this:

<asp:gridview datasourceid='dsProducts'>
<columns>
<DataBoundField DataField='ProductName'>
</columns>
</asp:gridview>

<sss:SlxEntityDataSource EntitySourceProperty='Products' id='dsProducts' >

The SlxEntityDataSource retrieves the entity bound to the page and resolves the Products property. That’s pretty much it really… There is an EntityDataSourceView which contains the actual logic needed to retrieve the entity within the collection… It is also possible to just set this to a custom collection. And of course NHibernate automatically persists all this mess (with the help of Saleslogix to save it into the session until we are ready to commit it) without me having to lift one finger. Next in line is adding a small improvement to the GridView to make it possible to edit more than 1 row at a time because having to click Edit/Update every time is a bit of a drag. There is a good post for this on Matt Dotson’s blog.

Well the last comment I can make for now is what a piece of dogshit ObjectDataSource is. I wish I hadn’t spent so much time trying to make it work despite all. The ASP.NET databinding is actually starting to look pretty good!

Well I tried the VS2008 download 3 times now and it always shuts down at 50% or more – they use that crappy “Akamai” download manager or whatever it is called. If the connection is interrupted it comes up with a message box that interrupts the downloads and won’t resume it until you click OK. If you wait too long the authentication times out and it gives “Requested file not available” error. Then it cancels the download. It will give you a chance to cancel the cancel but it still does it. What a piece of crap. Guess I will wait until it is available on the regular MSDN.

Well, almost.

May be old news to a lot of people, but I found out the FINDSTR utility which is installed standard on Win XP machines (probably Win 2k3 as well) has enough options to be a decent replacement to grep in the common cases. Even makes it easier for some things – for example use /S for a recursive search instead of having to build it with find.

For myself I still prefer using grep/find instead (on cygwin)… but will be useful when working on other boxes.