Home/ Questions/Q 809649
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-15T00:45:40+00:00

I am using database with a list of username/passwords, and a simple web form

  • 0

I am using database with a list of username/passwords, and a simple web form that allows for users to enter their username/password.

When they submit the page, I simply do a stored procedure check to authenticate. If they are authorised, then their user details (e.g. username, dob, address, company address, other important info) are stored in a custom User object and then in a session. This custom User object that I created is used throughout the web application, and also in a sub-site (session sharing).

My question/problems are:

  1. Is my method of authentication the correct way to do things?

  2. I find users complaining that their session have expired although they “were not idle”, possibly due the app pool recycling? They type large amounts of text and find that their session had expired and thus lose all the text typed in. I am uncertain whether the session does really reset sporadically but will Forms Authentication using cookies/cookiless resolve the issue?

  3. Alternatively should I build and store the User Object in a session, cookie or something else instead in order to be more “correct” and avoid cases like in point #2.

  4. If I go down the Forms Authentication route, I believe I cannot store my custom User object in a Forms Authentication cookie so does it mean I would store the UserID and then recreate the user object on every page? Would this not be a huge increase on the server load?

Advice and answers much appreciated.

L

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team
    1. It doesn’t really care whether you use your own authentication system, or the default membership providers when using such a simple scenario.
    2. You should avoid using the InProc session state when the app might recycle some times a day. Rather store your session into a database (SqlSessionState) or use a StateServer. Then the application pool can recycle all day without interferring with your sessions. Setting the session timeout to 60 minutes or something, will solve the remaining issues. Never use cookieless sessions (unless you know what you’re doing), as they make it way too easy to steal one’s session.
    3. Just store it into the session (or profile if you use the default membership provider). Not only is a cookie easily readible, it is also limited to 4 KB.
    4. No, you will have a profile where all the user information is stored. It doesn’t really matter whether you use forms authentication or a custom system that stores it’s data into SqlSessionState. The membership provider will store the Profile ID into a cookie, same as the session state will save the Session ID into a cookie.
    • 0