Monday, August 18, 2008

DotNetOpenId adds an OpenID AJAX login control

DotNetOpenId may be feature complete per the OpenID spec, but it's far from stagnant. The next version will be packed with new enhanced security features that can be optionally turned on by relying party sites with high security requirements, and a new AJAX login control! I'm pleased to announce as well that it will be just as easy to drop in and use as the non-AJAX version.  Ah, the joys and power of ASP.NET.  Gotta love it.  That's why I think .NET is the best platform for developing OpenID-enabled web sites.

You can preview the new AJAX control early. And please, leave comments here on this blog on how you like/dislike it. Don't leave comments on the preview comment page just linked to, because those comments are not actually stored anywhere...

Labels: ,

10 comments:

  1. can you show how to use it with jquery?
    ReplyDelete
  2. What is it you want to accomplish with it using jquery? It functions without any coding on your part at all, so I need to know what you'd like to do in addition to what it already does.
    ReplyDelete
  3. Do you have any indication when it's going to be available?

    And when, where and how do you recieve the open id response claims properties?

    Are those available server side or in javascript? etc.

    Marc Selman
    ReplyDelete
  4. Hi Marcus,

    All great questions. The sreg/ax claim responses aren't built into this control at all yet, nor support for any other extensions. But you bring up a great point. It would be awesome to have support for drawing out these claims in both Javascript and on the server.

    The way the control is architected (for security reasons), nothing about the authentication or extensions would be verified until it reached the server the final time, but the Javascript could use the claims to prefill some form fields or something else lightweight and low-risk.

    I'll see what I can do about enabling that scenario and write a new post when I can share how it works.

    When will it be available? I'd say a couple weeks away. One of the tricky things behind AJAX controls is that its a lot harder to do forced information hiding with Javascript, so to fix bugs or enhance this control after its released will be tricky to do while maintaining backward compatibility with people who've cracked open the .js file and started taking advantage of its internals in order to customize it. So I've got to give some time to review code and make sure I feel as confident with it as I can to avoid upgrade problems for developers such as yourself in the future.
    ReplyDelete
  5. I've added support to the control for adding extensions, and the preview demo now uses simple registration to pull the email address out of an OpenID account.

    No support for getting the values using javascript yet... they're only available at the server for now. We'll see if that can be improved.
    ReplyDelete
  6. Voila!

    The latest version (which is still a preview anyway) of the control now allows for OpenID extensions and accessing those extensions from javascript is a very simple way.
    Check out the linked sampled again to see it in action!
    ReplyDelete
  7. Great work. I hope to try this next week. Does it work cross-domain? So if i am on domainA and plug in my script from domainB (a widget say) will it auth against domainB ok?
    ReplyDelete
  8. So Weblivz, I don't think I understand your question. Can you give me a specific example? If it's as simple as "Can my ajax login control log me into domainA when my provider is on domainB?" the answer is yes.
    ReplyDelete
  9. Hi Andrew - about the cross domain question. It's mainly whether it uses GET or POST. Get can work cross domain wherewas post will not. Or more specifically, the underlying Xml http provider will not work cross-domain so some hacks need to be used.
    ReplyDelete
  10. Interesting. I'd love to see a sample showing XmlHttpRequest working cross-domain even with a GET request as I was unsuccessful at it.

    The ajax control I wrote works with both GET and POST, using POST if the payload is large enough, by not using XmlHttpRequest at all but instead using invisible iframe's and some carefully engineered redirects.
    ReplyDelete

Subscribe to: Post Comments (Atom)