We have gone back to the drawing board with SharePoint 2010 planning, and now are challenging some ideas about how authentication must be configured for SharePoint to work with our clients. Previously, we felt the need to provide multiple supported authenticaiton types (Windows, Basic, and Forms) hosted on different IIS web sites, with unique URL’s (sharepoint, sharepointlite, partnerpoint). We also felt the need to have a version of sharepoint with “Client Integration” features enabled, and one with these features disabled (sharepointlite). With changes in SharePoint 2010, is this really necessary?
First, let’s look at the Windows vs. Basic assumption. Are there any browsers out there that do not support Windows/NTLM authentication? In fact, there are… the Android mobile browser and, um…, well, there do not appear to be any others. However, it is not necessary to make a separate web site available to allow basic authentication. If we enable basic auth on an exsiting Windows-auth web site, browsers that do not support Windows auth suddenly start working. (Update, 2013-02-36: Chrome for Android now supports NTLM authentication, so there appears to be no need to support Basic authentication at all at this point in time.)
Now, let’s look at the client integrated vs. dumbed-down assumption. Previously, we wanted to ensure the clients handled links to MS Office documents stored in SharePoint in a predictable fashion. Users of Firefox and Safari frequently complained about “strange” document handling behavior in SharePoint links. For people experiencing confusion caused by failed attempts to launch Office applications from SharePoint browser links, we exposed a version of SharePoint that had the client integration features disabled. HOWEVER, under SharePoint 2010, the client integration features are much more reliable. On Windows, I am able to make use of Office 2010 client integration in both IE9 and Firefox. On the Mac, client integration works with Office 2011 Mac and Safari 5 or FireFox 8. Additionally, SharePoint will detect if a browser cannot support client integration, and will disable Office inegration links automatically. For example, the “Open in Word” link is greyed-out in my Chrome browser, while the “Download file” link is active.
Add to this the new mobile web version of SharePoint 2010. If you connect from a browser listed in the “compat.browser” file on the SharePoint web server, you get directed to a light-weight mobile version of SharePoint instead. See: http://blogs.technet.com/b/office2010/archive/2010/03/09/configure-sharepoint-server-2010-for-mobile-device-access.aspx for more details on how “compat.browser” works. This version will use Office Web Apps to render Office documents, but editing will not be possible. This grants mobile users a functional (if somewhat limited) access method for SharePoint content, while at the same time sidestepping the issue of client integration. It also means that we do not have to deal with the hassle of attempting to ensure that Office Web Apps will work in a myriad of underpowered mobile browsers.
All things considered, things are looking bright for SharePoint 2010. It seems we no longer will need a “lite” version of SharePoint, and we will not need two URLs to support the varying authentication needs of legacy browsers.