ASP session data storage options, coming from PHP

I've started ASP a few months ago, having come from a few years of PHP.

In PHP, I used a combination of cookies PHP sessions, cookies and storing the Session ID in the database.

When a person logs in, the Session Id is written to the cookie and saved in a column in the database. If the person logs off, the cookie is deleted, if the person forgets, that's okay since the cookie only lives for 72 hours.

Upon visiting the site, I check for a cookie. If it exists, I see if the Session ID exists in the database. If so, we have a match and the person can continue their session. If no match the cookie is deleted, as it was probably forgery.

If no cookie, the person must login. An old value for Session ID stored in the database is simply updated.

Now, with ASP, it seems there are more options. From this article: http://msdn.microsoft.com/en-us/library/ms178581.aspx

* Application state, which stores variables that can be accessed by all users of an ASP.NET application.

* Profile properties, which persists user values in a data store without expiring them.

* ASP.NET caching, which stores values in memory that is available to all ASP.NET applications.

* View state, which persists values in a page.

* Cookies.

* The query string and fields on an HTML form that are available from an HTTP request.

I'll probably stick to my Session+cookie+database system for now, but what of these other things mention开发者_JAVA技巧ed here? They seem mysterious to me. Is a further combination possible to make things even more secure, or would that just be overkill?

My main concern is that possible, the system of Session+Cookie+Database which I use, might have a flaw in it.

We use DNN (ASP based CMS) and develop modules. We use ViewState a lot for storing little things, like row id's. View state doesn't require that cookies are enabled on the browser, but for large objects like datasets, reading and writing and transferring can get heavy. So we store the row id and requery the table when the postback happens.

The query string is really the thing when you are directing users between different pages. For the most part, we are encrypting this now with a utility built into DNN. I would recommend that to stop users that tweak the query string for kicks.

Caching is your scalability thing. It takes a bit more programming work (you always have to be ready to reload), and using it too much puts a memory load on your IIS server, but for data lists that are used a lot, it can really speed things up. I rarely use it for user-specific data.

All in all, these constructs are heavier than you are used to in php, but they will make your programming life much easier.

Using Session (either in memory or via a database) and Cookies for handling and persisting authentication and user details is usually the standard approach in an ASP.NET website.

Application state and Caching provide similar functionality in that it allows you to store data that is accessible to the whole application, not just a specific session, at any time however Caching is the preferred approach as it give you some extra features that allows you to control when the data is refreshed via the CacheDependency object and prioritise its lifetime in the event of memory running low. If you have some data that is expensive to retrieve from a database and relevant to all users of your site then you would store it here i.e. a list of values for a drop down list.

Viewstate persists page data between requests and is typically used to hold your web control values however custom values can be added if desired and relevant. The caveat with this is that these values are encrypted and sent a part of the page response and returned via the request to this can add a large amount of overhead to your page size if you are not careful.