Forms Authentication

Overview

Using ASP.NET forms authentication against the database is the default configuration for mojoPortal and is recommended for most public facing web sites. You don't have to do anything to configure this other than the initial connection string setting for the database. Users are authenticated by their username or email address and password stored in the mp_Users table.

Setting Login Timeout

Users should be logged off after a period of inactivity. User sessions are terminated when users close their browser (all windows/instances of their browser) and after the configured timeout is reached. By default, this timeout is set to 2 weeks, or 20,160 minutes.

When using Forms Authentication (the default Authentication Provider), you can change this on your site by updating the timeout value on the forms element in your web.config file.

Keep in mind that if you do set a low value like 5 for 5 minutes, then you should probably also uncheck the Allow Persistent Authentication Cookie setting in Site Settings. It would be a bad user experience if the user checks "Remember Me" on the login page and then his is logged out after a short time of activity. Note that this "Remember Me" checkbox only determines if the cookie can survive closing the web browser, the cookie is still subject to the timeout regardless of whether the web browser is closed. But if the browser is closed and re-opened before the amount of time then the user will still be authenticated.

Also keep in mind another bad user experience if you set a low number like 5 minutes. Suppose the user is editing a large article and then gets sidetracked into a conversation without saving and 5 minutes goes by, then he tries to save the content but it fails because he is no longer signed in and the edits are lost which can be very frustrating for a user.

We have a session keep alive that is used on edit pages to prevent the user session from timing out while editing but this is based on the IIS session timeout (which defaults to 20 minutes) not on the auth cookie timeout. So, the sessions keep alive makes a background request from an iFrame in edit pages but the frequency is based on the session timeout so if session timeout is 20 minutes it makes a background request at 19 minutes to create activity to keep the session alive. However, 19 minutes is too long to wait if the auth cookie will expire sooner than the IIS session. To account for this, we have a config setting:

If you put a value greater than minus 1 it will use that number of minutes for the session keep alive frequency. If you put 1 then it will make a background request from the edit page every 1 minutes so that would be frequent enough to keep the auth cookie alive if the user has the editor open and gets side tracked. But then again if you choose to do that it means that if the user opens an edit page and walks away from the computer you are back at the same security problem because the edit page would keep the auth cookie fresh.

So, as usual, there are tradeoffs between security and user experience. If you are worried that the user would leave the machine unattended with the editor open then you would not want the session keep alive to make requests frequent enough to keep the auth cookie alive, but it can lead to user frustration if the user had unsaved edits and his auth cookie expired.