ASP.NET 2.0 Membership Provider - SSL alias - shared webapp

[Rich Williams]

Hi All,

Hope i can explain my problem. I have a single webapp that uses ASP.NET 2.0
Membership . Inside my website setup in IIS i have created an domain alias
that will be secured. The webapp actually runs multiple domains and 1 SSL
domain.

I need to ensure that my users stay logged in when moving between the
secured pages and the insecured pages. Obviously these pages are under
different domains/aliases (ie: www.mystore.com & ssl.mystore.com) but again,
are the same "website" in IIS and the same application. I also need to pass
around things like shopping cart information etc. between the SSL domain
(alias) and the regular domains. Will the member information, status etc be
passed between the website aliases?

First of all will this work? How are the ASP.NET 2.0 Membership sessions
stored? Per webapp or per domain? What is the process of getting this type of
scenario working? I have searched many sources and have yet to find a
documented solution. Am i going about this the wrong way?

 

[Dominick Baier [DevelopMentor]]

Hello Rich,

The MemberShip provider data store is organized around ApplicationNames -
the default app name is '/' if you don't reconfigured the provider.

So by default all of your sites should access the same membership data.

What you might experience is that FormsAuth thinks this is a different server,
go and experiment with the new EnableCrossDomainRedirect and Domain attributes
in the Forms Authentication configuration.

 

[Rich Williams]

Hi Dominick,

I've searched around for more info and haven't found anything about
EnableCrossDomainRedirect . I've tried adding it to the web.config file with
no luck. Doesn't seem to be recognized. There is an EnableCrossAppRedirect
which wouldn't do anything for me as i am using a single app.

Do you have anymore information? Or can you direct me towards some kind of
resource? Is there some article or documentation i can use to find out more
about the domain attributes? This seems like a very straight forward hurdle
that many developers will need a solution for. What other possible solution
might there be? Passing around a session ID from domain to domain is probably
not very safe. Thanks for your help!

Rich