Identity Selectors & Browser Detection

I spent a chunk of time recently trying to figure out how a web developer could pre-test a user’s browser configuration to determine whether some kind of identity selector client or plugin will pick up on the embedded HTML object and give the user a little infocard-love, if you know what I mean 🙂

It’s a little messy. Ok it’s a lot messy.

The CardSpace team has given us a way to test whether their client is installed (which I really appreciate), but sadly, the way that they have given us can only be evaluated using a scripting language that runs on one brand of browser. What we all really need is a way to tell if *any* identity selector is installed or, in a future perfect world, *which* identity selector is installed, in a vendor-agnostic way.

Sadly, the browser wars have completely derailed ease and simplicity in determining capabilities for embedded content. It’s hard for me, looking back, to imagine what possible reason the IE6 team might have had for choosing to populate only part of the ‘navigator’ object in Javascript. Why would they choose to populate navigator.appName and navigator.platform, but leave things like navigator.plugins and navigator.mimetypes blank? And why would they choose the worst *possible* way not to support it, by returning a valid but empty array every time, making it impossible to tell the difference between a call to a supporting browser that happens to have a negative result, and a call to an nonsupporting browser that may still actually have the plugin you want installed? Sadly, this functionality appears to not have changed for IE7 either.

In my wildest happiest dreams, I would test once to see if the ‘application/x-InformationCard’ mime type is registered. If it isn’t registered, I would test no further, and send the user to a “getting an Identity Selector” help page.

If the mime type does exist, I would (in my happy dream) find out what plugin is registered to the the above mimetype. I might also check the plugins list to find out whether there were any other known identity selector plugins that were installed but either disabled or not the default. I could then tell the user exactly what plugin it is that is handling their identity selector needs. Wouldn’t that be a nice and user-friendly? Instead, I’m stuck trying to jump through the same nasty hoops that the people trying to detect Flash versions go through.

Don’t believe me? Look at the scripts that are written to accomplish what should really be a simple task.

After all this angst, I can only report varied results. It is obvious to me that this is not a piece of code that you can write and walk away from, because it can’t possibly be vendor-agnostic. The identity selector detection script will have to be tweaked and coddled and monitored forevermore, just like the flash detection scripts.

Right now I have three possible clients to detect. If I want to detect the CardSpace client without using VBscript, it seems reasonable to assume that if I parse navigator.appVersion and see both “MSIE 7.0” and “.NET CLR 3”, life is probably good, good enough to know that at least one identity selector is installed. If, in the future, the user had both CardSpace and the OSIS identity selector installed, I’m not sure how you could determine which one was active. Chances are you could use VBscript for that, but then you would have to do something in the case that VBscript is disabled…

In trying to detect Ian Brown’s Safari plugin, I’ve found that navigator.mimetypes shows that the “application/x-Informationcard” mimetype is registered, but I can’t derive an enabled plugin from navigator.mimeTypes["application/x-informationCard"].enabledPlugin, I’m not sure why. I will keep working on this and let you know.

I can’t detect Chuck’s Firefox plugin at all, because it isn’t a plugin, it’s an extension, and extensions are considered private by the browser. I can’t even tell that the “application/x-informationcard” mimetype is registered. I don’t think there is any fix for this, except perhaps asking Chuck very nicely if he could look into what it would take to move away from an extension and towards a plugin.

Well, that’s the report from the trenches. Pete, you may be right, perhaps all we can do is to let the user fail, and then try to explain it to them after the fact. The sad thing about being forced to be reactive instead of proactive, is that when the html object is invoked but no token is returned, there can be a number of root causes. Trying to explain them all to the user will make their head spin around — which leads me to another little thing I’m working on, you’ll hear about that pretty soon 🙂

Advertisements

~ by Pamela on 5 Nov 06.

4 Responses to “Identity Selectors & Browser Detection”

  1. Hey Pam,
    navigator.mimeTypes[“application/x-informationCard”].enabledPlugin fails because the current version of the Safari plug-in incorrectly registers itself for the “application/x-informationcard” MME type (note the lowercase ‘c’).
    Fixing that post haste.
    As far as universal detection scripts go, it’s worthwhile checking out Garett Seracks efforts in this area: http://blogs.msdn.com/garretts/archive/2006/08/04/688971.aspx
    His script currently works with all known plug-in based selectors.
    Cheers,
    – Ian

  2. Hey Pam,

    It’s true. The detection of information card support is…tricky at best. Every browser *may* implement the support in a different way. I’ve got one cross-browser detection script working, but I know that there is an upcoming FireFox extension (not related to Chuck’s, and we should see by the first week of December, I’m told) that provides pluggable support for an Identity Selector, including CardSpace. When that actually makes itsef known, I’ll have to account for that.

    The trouble is, that to gracefully detect information card support, you always have to know how it is going to be implemented on that particular client. I like your idea of it being plugable at the OS level (and trust me, we’re looking at how to implement that), but that doesn’t answer the how at the browser level.

    We’ll get there sooner or later 😀

    G

  3. Oh, and of course, I failed to see Ian’s post above.

    I’m making my next detection script a tad more sloppy, to catch the uppercase C problem.

    Actually, I’m pretty sure I can detect Chuck’s (and the unanounced one I spoke of) a different way anyway. Hmm. maybe not Chuck’s. I don’t think he used XBL. I’ll have to talk to Chuck to make sure that I can detect his.

    G

  4. I’m not sure that the technique used in Garrett’s latest script is effective with IE7. I’ve been seeing many false positives on IE 7 with no .NET framework 3.x installed. Simply checking the userAgent isn’t enough, many people tweak their userAgent to obfuscate their browser platform.

    I did some debugging of the embedded object created in the javascript and found a property ‘isInstalled’. Using the script debugger, this value seems to be returning appropriate results in IE7 instances with and without .NET 3.x installed. See the following screenshots:


    This script element also gets mentioned in the guide for supporting infocards in browsers and webapps: http://www.identityblog.com/?page_id=412#infocardg_topic11

    This approach seems far more reliable than checking the issuerPolicy for ‘undefined’.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: