2

We've recently run into an issue with our ASP.NET application where if a user goes to ourcompany.com instead of www.ourcompany.com, they will sometimes end up on a page that does not load data from the database. The issue seems to be related to our SSL certificate, but I've been tasked to investigate a way on the code side to fix this.

Here's the specific use case:

There is a user registration page that new users get sent to after they "quick register" (enter name, email, phone). With "www" in the URL (e.g. "www.ourcompany.com") it works fine, they can proceed as normal. However, if they browsed to just "ourcompany.com" or had that bookmarked, when they go to that page some data is not loaded (specifically a list of states from the DB) and, worse, if they try to submit the page they are kicked out entirely and sent back to the home page.

I will go in more detail if necessary but my question is simply if there is an application setting I can say to keep the session for the app regardless of if the URL has the "www" or not? Buying a second SSL cert isn't an option at this point unless there is no recourse, and I have to look at a way to solve this without another SSL.

Any ideas to point me in the right direction?

Wayne Molina
  • 19,158
  • 26
  • 98
  • 163
  • If you perhaps value SEO on your site, would it be good to consider my answer of removing the canonical urls? See as to why its bad to have both showing the same content: http://stackoverflow.com/questions/1047438/what-are-canonical-urls-and-how-does-it-effect-your-seo – Phil Jul 28 '11 at 13:30

4 Answers4

3

When your users go to www.ourcompany.com they get a session cookie for the www subdomain. By default, cookies are not shared across subdomains, which is why users going to ourcompany.com do not have access to their sessions.

There is a useful thread discussing this issue here. The suggested solution is:

By the way, I implemented a fairly good fix/hack today. Put this code on every page: Response.Cookies["ASP.NET_SessionId"].Value = Session.SessionID; Response.Cookies["ASP.NET_SessionId"].Domain = ".mydomain.com";

Those two lines of code rewrite the Session cookie so it's now accessible across sub-domains.

Doug, 23 Aug 2005

Brian Beckett
  • 4,742
  • 6
  • 33
  • 52
  • I'll check that out; thanks. Would putting that code in Global.asax work, do you think? There are a hundred or more files that may or may not have similar issues (we only know of one, however). – Wayne Molina Jul 20 '11 at 13:30
  • Worth trying! How about in Application_BeginRequest, if you have access to the Response object at that point? – Brian Beckett Jul 20 '11 at 13:32
1

Surely you are trying to solve the wrong problem?

Is it possible for you to just implement URL rewriting and make it consistent?

So for example, http://example.com redirects to http://www.example.com ?

For an example of managing rewriting see:

http://paulstack.co.uk/blog/post/iis-rewrite-tool-the-pain-of-a-simple-rule-change.aspx

Phil
  • 4,012
  • 5
  • 39
  • 57
1

From the browsers point of view, www.mysite.com is a different site than mysite.com.

If you have a rewrite engine, add a rule to send all requests to www that don't already have it.

Or (this is what I did) add a separate IIS site with the "mysite.com" host header and set the IIS flag to redirect all traffic to www.

In either of these cases, any time a browser requests a page without the www prefix, it will receive a redirect response sending it to the correct page.

Here's the redirect site home directory properties:

enter image description here

And the relevant host header setting:

enter image description here

This fixes the issue without requiring code changes, and incidentally prevents duplicate search results from Google etc.

3Dave
  • 28,657
  • 18
  • 88
  • 151
1

Just an update, I was able to fix the problem with a web.config entry:

<httpCookies domain=".mycompany.com" />

After adding that, the problem went away.

Wayne Molina
  • 19,158
  • 26
  • 98
  • 163