Do I have to support "mysite.com" and "www.mysite.com"? OpenID problems?

I have implemented OpenID support for an ASP.Net 2.0 web application and everything seems to work fine on my local machine.

I am using DotNetOpenId library. Before redirecting to a third party website, I store the original OpenID in the session to be used when the user is authenticated (standard practice I believe).

However, I have a habit of not typing www

when I enter a URL into the address bar. When I tested the login on a real server, I was having problems when the session was cleared. My return code was hardcoded as www.mysite.com.

Is it possible that switching from mysite.com

to www.mysite.com

caused the session to switch?

Another problem is that www.mysite.com is not in the realm of mysite.com.

What is the standard solution to these problems. Should the site be automatically redirected to www.mysite.com

? I could just make the link to the registration page an absolute URL with content www

? Or is it just hiding another problem?

+1


source to share


3 answers


Solve the problem you talked about easily. Just install the realm at * .mysite.com, not just mysite.com. If you are using one of the ASP.NET controls included in the library, you simply set the control's property to set the scope. If you do this programmatically, you set a property on the IAuthenticationRequest object before calling RedirectToProvider ().

Regarding the session / cookie issue with the transition between www and non-www host, you have two options:



  • Instead of storing the original ID in the session, which is a bad idea anyway for several reasons, use the IAuthenticationRequest.AddCallbackArguments (name, value) method to store user-entered data, and then use IAuthenticationResponse.GetCallbackArgument (name) to call the data when the user has passed authentication.
  • Forget about it. There's a reason the dotnetopenid library doesn't automatically save this information for you. Directed Identity is just one scenario: If a user types "yahoo.com", you probably don't want to tell them "Welcome, yahoo.com!" rather, "Welcome to id.yahoo.com/andrewarnott"! The only way to achieve the correct behavior is to use the IAuthenticationResponse.FriendlyIdentifierForDisplay property to decide what to show the user as their ID. It gives more accurate information and is easier than storing the value in a callback and returning it back. :)
+2


source


I don't know how OpenID works, but LiveID gives you a token based on a combination of user and domain. I would just redirect www to mysite.com.



+1


source


Cookies and sessions and everything else are lost between www.site.com and site.com. I don't have enough patience to read all the specs in full, but http://www.w3.org/Protocols/rfc2109/rfc2109 states that

A is an FQDN string and has the form NB, where N is a non-empty name string B is .B 'and B' is an FQDN string. (So ​​xycom domain-matches.y.com, but not y.com.)

Note that domain-match is not a commutative operation: abccom domain-matches.c.com, but not the reverse.

I think that means yes, you need to forward to www. I've always added domain fix code to my sites when cookies and sessions are used.

+1


source







All Articles