Wednesday, 04 February 2009
« Hiding the root node from the SiteMapPat... | Main | FIX: Changing your MOSS site Url causes ... »
I love 'bugs' like this, as they result in a very satisfying 'aha' moment.

I've been working on an internet facing SharePoint MOSS site that uses forms authentication and a custom membership provider to authenticate users against the client's back office system. The back office system already has a web front end, and some of this functionality we needed to expose through the MOSS site: rewriting this functionality wasn't an option, so we chose to embed the existing back office web pages within iframes hosted in MOSS pages.

Given this setup, we had to ensure that when a user was logged into the MOSS site, the user would not also be prompted to login to the back office system whenever they hit a back office page hosted in an iframe.

The back office system uses a simple authentication scheme; if you've logged in successfully it places a  cookie on your machine which is used on all subsequent requests to verify that you are authenticated. As the back office web site is on a different domain to our MOSS site we cant just simply set the cookie ourselves within some custom MOSS code, we have to somehow get the back office system to set the cookie. To do this we are using a similar technique to a web bug: when a user successfully logs into MOSS, we write a hidden <img> tag pointing to a file on the back office web server. The url contains the information needed for the back office to believe the request is from the authenticated user, and so the response from the back office web server will set the cookies we need. Our <img> tag looks like this:

<img src="http://foo-backoffice/MembersArea/custom/setcookies.asp?UserValidated=xxxxxxxx&UserCheckSum=f0701xxxxxxxxxxxxxb359c87&redirectUrl=http://foo-backoffice/MembersArea/custom/active.gif" style="display:none;" />

And the response from the backoffice server looks like this (captured using Fiddler);




So the user now has an authentication cookie for the back office domain. Note that the back office application has specified a path for the cookie of /MembersArea.

Now, if the user browses a MOSS page that hosts an iframe pointing at a back office page, the authentication cookie is sent to the back office and the user is not prompted to login to the  back office. An example iframe tag from our 'update your profile' MOSS page:

<iframe width="715px" height="1400px" scrolling="no" frameborder="no" src="http://foo-backoffice/membersarea/updates/layout1.asp"></iframe>

The problem i encountered was this: the user was still being prompted to login to the back office, despite the web bug successfully setting the authentication cookie!

Using Fiddler I could see that the authentication cookie was not being passed to http://foo-backoffice/membersarea/updates/layout1.asp, and after some head scratching & some experimenting i realised why:

  • The authentication cookie had it's path set to /MembersArea  (note the case)
  • The back office web page i was trying to load in the iframe was http://foo-backoffice/membersarea/updates/layout1.asp
So, when you request a url and your browser checks to see if you have a cookie for that url, the browser is doing a case sensitive comparison between the cookie path and request url. This is certainly true in IE7 - i haven't tested this in other browsers.



Wednesday, 04 February 2009 11:51:17 (GMT Standard Time, UTC+00:00)  #      Comments [0]  |  Trackback
All comments require the approval of the site owner before being displayed.
Name
E-mail
(will show your gravatar icon)
Home page

Comment (Some html is allowed: a@href@title, strike) where the @ means "attribute." For example, you can use <a href="" title=""> or <blockquote cite="Scott">.  

Enter the code shown (prevents robots):

Live Comment Preview