Telligent Community
Telligent Community
  • Site
  • User
  • Site
  • Search
  • User
Telligent Community 10.x
  • Verint Community
  • More
Telligent Community 10.x
Legacy User Documentation Common things to check when using Forms Authentication
  • Ask the Community
  • User Documentation
  • API Documentation
  • Manager Training
  • Developer Training
  • Tags
  • More
  • Cancel
  • New
  • Telligent Community 10.0
  • -All platform topics
    • +Achievements
    • +Activity Story Stream
    • +Authentication
    • +Blogs
    • +Business Rules
    • Calendar
    • +Chat
    • +Content tools
    • Document Preview
    • +Email
    • Featured content
    • +Forums
    • +Friends
    • Gamification
    • +Groups
    • Hashtags
    • Ideas
    • +Job Service
    • +License
    • Likes
    • +Localization
    • +Media galleries
    • +Members
    • Mentions
    • +Mobile
    • +Moderation, spam and abuse
    • +Notifications & messages
    • Our quality assurance testing strategy
    • +Page Editing
    • +Permissions
    • +Profile & sign-in
    • Quick Post
    • Ratings
    • Responsive design
    • +Roles
    • Rule Automation
    • +Scores
    • +Search
    • +Security
    • +SEO
    • +Site admin
    • +Site configuration
    • Social basics guide
    • Social Twitter feed
    • +Status messages
    • Tags
    • -Telligent Community Troubleshooting Guide
      • Can't insert an image using the enhanced text editor after upgrading
      • Common things to check when using Forms Authentication
      • Common webfarm configuration questions
      • Configuration problems
      • Exceptions
      • +Fix access to uploaded files
      • Friendly error message
      • How to: Load images inline
      • Search index problems
      • Search stop words
      • Sorry, there was a problem with your last request message
      • SQL times out when accessing the site
      • Telligent Job Service troubleshooting
      • Troubleshoot search errors
    • Terminology Guide
    • +Themes
    • Tour Tips
    • +Tuning & performance
    • +User accounts
    • +User reputation score
    • Video Transcoding
    • +Widgets
    • +Wikis
  • Customization
  • Development
  • Getting started
  • System Requirements
  • +How Do I Install Telligent Community
  • +Upgrade Telligent Community
  • Release Notes

Common things to check when using Forms Authentication

Table of Contents

  • Authentication ticket name
  • Machine keys
  • Cookie paths
  • Cookie domains

When using the Forms Authentication module, there are a couple of areas to check first when troubleshooting any issues you might encounter when setting it up. These include the authentication ticket name, the machine keys, the cookie path, and the cookie domain.

Authentication ticket name

The most common issue when using Forms Authentication is that the name of the cookie used for the authentication ticket is different between the two applications. Forms Authentication works by creating a certain cookie that contains basic information about the user. The name of the cookie is set in the web.config. In ASP.NET, the default name is “.ASPXAUTH”, however Telligent Community Server's out-of-the-box web.config sets it to “.Zimbra.Evolution”. If the two applications do not have the same name set, then the other application will not recognize the authentication ticket from the main application.

To change this, you can either change the main application to match Community Server's setting by changing its <forms> line in the web.config to “.Zimbra.Evolution”, or you can change Community Server to use the same setting as your own application, but changing its web.config to use “.ASPXAUTH” or whatever it already has specified. An example is:

<authentication mode="Forms">
 
<forms name=".Zimbra.Evolution" ... />
</authentication>

Machine keys

When using Forms Authentication between two ASP.NET applications, you need to ensure that the machine keys between the two applications match. The machine keys are used to encrypt and decrypt the information within the authentication ticket. If they do not match, one application will not be able to utilize the other application’s authentication ticket.

The machine keys are set within the <system.web> section of the web.config. A sample machine key section looks like this:

<machineKey
  validationKey="CFBAC2E26EB8...174C6901CE50D"
  decryptionKey="43AEA5079E…97035372A"
  validation="SHA1" />

Cookie paths

A frequent issue with the cookie created for the authentication ticket is the path on the cookie. Typically, an application will create the cookie with its path set to its own application path. So if your application is at /app and Community Server is at /tc, when you set the authentication cookie within /app, ASP.NET will automatically set the cookie’s path to /app. Then the browser will only pass the cookie along to page requests under /app, and not to /tc. To get it to carry over, you’ll need to set the cookie’s path to /, so that it will be accessible between the two applications.

The cookie’s path can either be specified in the web.config or through code. To set it in the web.config, use the path attribute on the <forms> line in the parent application's web.config, such as:

<authentication mode="Forms">
 
<forms name=".Zimbra.Evolution" ... path="/" />
</authentication>

Additionally, it can be set in code when you use the GetAuthCookie method of FormsAuthentication instead of just the SetAuthCookie method when creating the cookie in the parent application. For example:

HttpCookie cookie = FormsAuthentication.GetAuthCookie(username, true);
cookie.Path = "/";
Response.Cookies.Add(cookie);

Cookie domains

Another common issue with the cookie for the authentication is the domain for the cookie. Similarly to the paths of the cookies, if the cookies are created on two different subdomains, then the cookie will only be accessible on the domain where it was created. For instance your main application may be on www.domain.com, but you have Community Server running on tc.domain.com. If you create the cookie on www.domain.com, the browser will only send it to that domain, and it won’t be passed along when they navigate over to tc.domain.com.

The cookie can be carried over by setting the domain to “.domain.com”.  Cookies don’t use the common “*” wild card. Simply use “.domain.com”. With this entry, the browser will not  pass the cookie when it goes over to cs.domain.com as well.

Like the path, the domain can be specified in either the web.config or through code. When setting the web.config file, it will only check for the authorization cookie. You must have this set for the site to correctly recognize the new domain level cookie:

<authentication mode="Forms">
  <forms name=".Zimbra.Evolution
" ... domain=".domain.com" />
</authentication>

The "domain" name is ignored by the FormsAuthentication.SetAuthCookie method, so you must manually set it on your login page when creating the AuthCookie. For example:

HttpCookie cookie = FormsAuthentication.GetAuthCookie(username, true);

cookie.Domain = ".domain.com";
Response.Cookies.Add(cookie);

  • Share
  • History
  • More
  • Cancel
Related
Recommended
  • Telligent
  • Professional Services
  • Submit a Support Ticket
  • Become a Partner
  • Request a Demo
  • Contact Us

About
Privacy Policy
Terms of use
Copyright 2021 Verint, Inc.
Powered by Verint Community