I have an older (v5 - yeah, I know...) installation, and I have a single portal that does not want to write the FormsAuthentication (.DOTNETNUKE) cookie on login.  User can see pages that require role when returning from the login form, but moving to any other page (or, if admin, trying to edit something), the user is no longer authenticated and the site returns to a non-logged in state.  In checking tools it appears that the .DOTNETNUKE cookie is not being written at all to the cookie cache.

This only happens on a single child portal in the installation.  Other child portals do work.  I thought that it may have something to do with using the IP address in the alias (ex. [ipaddr]/[portalname]), but I have other portals using the same scheme that do not have this issue.  Note also that Superusers DO work, but local Administrator accounts do not.  A few other items of note: We are using the MPUS Multi-Portal Sharing suite to provide SSO, but this portal is not participating in that environment, and I have the AD Provider installed, but not active for this portal.

Any ideas on why it would be happening for a single portal only?  Thanks

those cookies (and the forms auth cookies) are written when the user log's in (and in a version such as 5 they're updated every minute - whereas more modern versions of dnn no longer use portalroles at all). As to why it's not being written, my guess is that it is and then is immediately expired. Take a look at the requests in a http proxy such as fiddler and you'll be able to see what goes on under the covers - the most typical case here is that DNN believes a request is outside the users portal and expires the cookies e.g. something on a page in your failing portal is referencing a .net mapped extensions (aspx/asmx etc.) that is not in the desktopmodules folder -as such DNN checks to see if it can ensure this is still a request within the portal by checking any portalid or tabid. If it doesn't find one, DNN has to assume the user changed portal and expire the cookies. I've seen this happen in the past with "shared" pages such as thumbnail.aspx (and the fix was easy i.e. update the link to include the portalid, so DNN is happy the user has not changed portal)

---

Buy the new Professional DNN7: Open Source .NET CMS Platform book Amazon US