Learn More





Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeUsing DNN Platf...Using DNN Platf...Administration ...Administration ...Single Portal does not write FormsAuthentication cookieSingle Portal does not write FormsAuthentication cookie
New Post
3/27/2014 1:01 PM

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

New Post
3/27/2014 4:06 PM

Added - further checking cookies shows that two other keys appear on a successful login (portalaliasid and portalroles) that do NOT appear when logging in on the problem portal.  What would be providing these two keys?

New Post
3/27/2014 7:58 PM
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
New Post
3/31/2014 2:37 PM
UPDATE: After some diagnosis I believe the culprit is a badly formed URL ([ipaddr]/Images/undefined) being generated by the module admin menu. This particular file is generating a "302 Found" response code, and as such it is changing the session context of the browser and timing out the cookies. The request header for the file is as an image.

My current workaround is to disable showing any container code when not logged as a site admin. For regular Registered Users the site logs in properly and maintains the auth cookies throughout. Admins are forced to see the Module Menu so the error crops up.

The "undefined" filename leads to believe that javascript is the culprit. The menu is rendered by the DDR Menu module, but again it has not been a problem on other portals. If anyone has encountered rendering problems with one portal due to JS problems I would like to know. Thanks
HomeHomeUsing DNN Platf...Using DNN Platf...Administration ...Administration ...Single Portal does not write FormsAuthentication cookieSingle Portal does not write FormsAuthentication cookie

These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.
Try Evoq
For Free
Start Free Trial
a Demo
See Evoq Live
Need More Information?