Get it now.

We need your help and financial contributions.  Please support this project and make a donation today.

Get it now.

We need your help and financial contributions.  Please support this project and make a donation today.

Q&A

Q: Is there any compelling reason to upgrade?
A: If you're using v3.4.7 and happy with it, no, there's no big reason to upgrade yet.  No security holes have been discovered in v3.4.7 and if any are, v3.4.x is still a supported branch and fixes will be back-ported and released in a subsequent version.   If however, you are interested in OAuth 2, then you should upgrade.

Q: Why the focus on NuGet recently?  Is the .zip distribution still supported?
A: NuGet provides a very convenient way to not only obtain the current release of DotNetOpenAuth, but to automatically be notified of updates when they become available and to install them into your applications.  It also includes functionality so that when you install DotNetOpenAuth into your applications, important changes to your .config files can be made to keep your site secure.  The .zip distribution is still supported for those folks who have not yet discovered NuGet.

Q: How can I get the samples now that I'm downloading the library via NuGet?
A: That is a big reason why we still ship the .zip version.  Install the library to your applications using NuGet, and then go download the .zip file to get the samples.  Eventually we'd like to create NuGet packages that include login screens, authorization pages, etc. so that "samples" can be installed directly into your web app, ready for you to customize them.  But this will require more community contributions to become a reality.

Q: What breaking changes are there since v3.x?
A: Due to the divided assembly refactoring that happened for v4.0, some of the type names and the assemblies they belong to have changed.  If you're upgrading a project from v3.x to v4.x, review your web.config file to ensure that the types and assembly names that mention DotNetOpenAuth are valid in v4.x and update if necessary.  Referring to the samples' web.config files will probably help streamline this process for you.  Also, the NuGet packages include some of the web.config boilerplate code for you.

Q: Why does installing the DotNetOpenAuth NuGet package add so many dependency packages and assembly references?
A: To appease the demands of a few large customers, DotNetOpenAuth as a multi-protocol, multi-role library was broken up into smaller assemblies that implement specific protocols and roles.  There are individual NuGet packages that represent each role for each protocol.  The DotNetOpenAuth package become the aggregate of all these smaller packages, so that it fills the same complete picture that the v3.x version of DotNetOpenAuth did.  If you prefer the one unified assembly version, you can install the DotNetOpenAuth.Ultimate NuGet package.

Q: Which is recommended?  Installing the DotNetOpenAuth or DotNetOpenAuth.Ultimate NuGet package?
A: The "DotNetOpenAuth" package is recommended, since other NuGet packages that take a dependency on this library will likely choose to express those dependencies in terms of the smaller DotNetOpenAuth.* packages.  By installing DotNetOpenAuth instead of DotNetOpenAuth.Ultimate, you avoid potentially installing both packages and ending up with type resolution  conflicts.  You mustn't choose to install both--you should decide on one or the other.

Q: Is OAuth 2 support built-in?
A: Yes and no.  OAuth 2 being an unfinalized spec, and DotNetOpenAuth's support for the latest draft of OAuth 2 being incomplete besides, it felt inappropriate to include OAuth 2 in an "official release".  It is (informally) included in the "unified" DotNetOpenAuth 4.0 distribution, but that portion of the library is considered "unstable".  It is also available in NuGet packages that are in a "prerelease" state.

Q: When will OAuth 2 be included in an official release?
A: When the spec is finalized, or at least stable enough to have reasonable confidence that breaking changes to the library wouldn't be necessary in order to support a later version of the spec, then DotNetOpenAuth will go through the regular security review and thorough security unit testing process that merits an official release.

Q: What about OpenID Connect?
A: OpenID Connect is an unfinalized protocol  built upon OAuth 2, another unfinalized protocol.  When broadly adopted, it will likely deprecate OpenID 2.0 as the recommended way to support delegated authentication.  DotNetOpenAuth will support this new protocol, sometime after OAuth 2 support is stable.

A full review of what's new in v4.0 is currently being prepared however if you would like to check it out in the meantime you can by checking out our pre-release nuget package.

As always, we really want to hear about how you get on so be sure to post on our facebook page or ask any questions you may have on stackoverflow. Be sure to tag your post with 'dotnetopenauth'.

Enjoy!

Release Notes

Frequently Asked Questions

Q: Should I upgrade?

If you're happy with DotNetOpenAuth v3.4.7, there is no compelling reason to upgrade as there are neither critical bug fixes nor interoperability improvements in this v4.0 release. The beta release is a preview of what is expected to stabilize in the coming few weeks, and when the final release is available. Please try out the beta and report any issues you find.

Q: What has changed?

1. Several backward compatibility breaking changes compel us to tag this with a major version increment. More details in following questions.
2. DNOA builds against both .NET 3.5 and 4.0. NuGet will automatically install the right version of the DLL for your target framework. What does this mean for you? Not much, actually. A few references in DNOA have migrated from their .NET 3.5 versions to .NET 4.0 versions but it shouldn't make any real impact on your code or the runtime behavior of the library. But a few customers have been pleading for a 4.0 compiled assembly, so now you've got it. You're welcome.
3. First class NuGet distribution support including symbol packages. This means that if you've set up your VS for source stepping with the appropriate servers explicitly listed, you can step directly into dotnetopenauth source code while you're debugging without any extra steps like finding and downloading matching source code. Woot!
4. FIPS-compliant SHA algorithms can now be configured in your .config files.

Q: How can I update my code to work with the new version?

Please review your web.config file's entries to any DNOA behaviors or extensions as some of those types have been renamed or placed under different namespaces. You can compare your entries with those found in the current samples or simply look in the dotnetopenauth.dll assembly for those types to confirm they are where you think they are.

Q: Why the backward compatibility breaking changes?

In order to accommodate a few (large) customers who needed DotNetOpenAuth split up into many smaller assemblies, DNOA was refactored in 21+ assemblies. While it still ships primarily as one unified assembly, the refactoring required moving types around and splitting some types into two, giving one or both new names and/or namespaces. It's an unfortunate growing pain, but in the end I believe this will also make the codebase more maintainable, so please bear with us in this transition.

Q: Where are the samples?

NuGet doesn’t seem to lend itself as well to shipping whole projects which the samples currently are. The samples are expected to ship with the traditional .zip file distribution when that becomes available.

Q: When will the traditional .zip file distribution of the beta be available for download?

We expect to release the traditional .zip with everything included within another week or two.

Q: Where can I find the source code for this release?

https://github.com/AArnott/dotnetopenid/commit/v4.0.0.12030-Beta1

In Short

1. Get DNOA4Glimpse:
   NuGet Command: PM> Install-Package DCCreative.DNOA4Glimpse

What is Glimpse?
(http://getglimpse.com/About)

Glimpse is a very cool set of utilities that provide developers with a massive array of how requests go about being served, as well as a host of other information about the server itself.

At its core, Glimpse allows you to debug your web site or web service right in the browser. Glimpse allows you to "Glimpse" into what's going on in your web server. In other words what Firebug is to debugging your client side code, Glimpse is to debugging your server within the client.

Glimpse is available via NuGet at http://nuget.org/List/Packages/Glimpse.

Exposing DotNetOpenAuth to Glimpse

Writing a plugin for Glimpse is childsplay. Glimpse exposes a friendly Plugin interface

public interface IGlimpsePlugin
{
	string Name { get; }
	object GetData(HttpContextBase context);
	void SetupInit();
}

Simply inherit from IGlimpsePlugin then implement the members in your plugin.

[GlimpsePlugin]
public class DotNetOpenAuthPlugin : IGlimpsePlugin {
	public void SetupInit() {
	//...
	}
	public string Name {
		get { return "DotNetOpenAuth"; }
	}
}

After adding a reference to the assembly containing your plugin, Glimpse will automatically pick up your plugin (thanks to the wonderful powers of MEF).

Demo

I quickly threw together a sample application to test the plugin.

1. Create a new ASP.NET MVC site based on the DNOA MVC relying party sample.
2. Add the DNOA4Glimpse package (Install-Package DCCreative.DNOA4Glimpse)
3. Done (Get the source here)

Glimpse has been turned on (by visiting //yourwebsiteurl.example.com/glimpse.axd) which results in a panel being displayed at the bottom of your screen. As you can see, there is a DotNetOpenAuth tab. Awesome!

Right, now – let’s do an OpenID Authentication

What’s really cool is the Glimpse’s handling of complex objects.

The presentation of complex objects such as the YADIS services detailed above will improve in a version I am currently working on, thanks for some new presentation features coming to Glimpse soon. Watch this space.

So the plugin is still in beta but hopefully you will find it useful.

DNOA4Glimpse and Demo Source is available at https://github.com/DavidChristiansen/DNOA4Glimpse

So what's new about it?

• Overall: Upgraded to latest Code Contracts version.
• RP/OP:Improved avoidance some unhandled VerificationExceptions that could be thrown on partial trust hosts due to a bug in .NET.
• OP: Fixed a couple of bugs in AXFetchAsSregTransform.
• OP: UIRequest extension now serializable, and fixed an unhandled exception on some UI extension requests.
• OP: Added IRequest.ClearResponseExtensions()
• RP: Improved interoperability with some Providers that send non-normalized positive assertions for stateless RPs (avoids some "invalid signature" errors)
• RP: A configuration option to be less strict about requiring remote parties to conform so precisely to the spec.
• RP: OpenIdSelector control no longer breaks ENTER from submitting other forms on the same page.
• RP-MVC: OpenIdAjaxOptions now allows an MVC app to specify a form name instead of only a form index.
• Samples: A random assortment of small improvements to the samples.
• ApplicationBlock: Now includes support for paging through Google Contacts using OAuth.

Sean writes;

The problem that came from this setup was that DotNetOpenAuth determined that the realm was example.com/sitedir instead of example.com, and returned from openid with to the sitedir/authenticate. Andrew Arnott pointed me in the right direction pretty quick after my tweet. Here is what I ended up with to fix this, it is in 2 parts.

Check out Sean’s full article here.