Printable View
Is there any safe number of session variables to have.
I have 6 and they are small strings, no objects.
I was thinking of storing the database connection object in a session variable but then you get into all sorts of checks depending on which page the user happens to start their navigating at.
Look to store a database connection string in the web.config file. The appSettings section is the place for that. Those settings get loaded into memory by the asp.net worker process when it starts, and the framework provides a easy way to access them. Plus, when you need to change the connection string, you can do it in the web.config file and the change is populated for the site without any recompiling or restarting the web site.
As far as your question, you can store an aweful lot in session/application variables. I think there is a setting somewhere, but I am not sure exactly where...check the machine.config. I think it is more dependent on the servers memory than anything.
Hellswraith,
How secure is the web.config file? I know about the app setting section and have been reading about the forms authintication method and storing users in the web.config. The book I have doesn't cover things like "what if, a savy hacker can download the file because the server has it set with a read permision?". I haven't done any testing no time :( I was just wondering if you knew anything about that aspect of it.
By default asp.net won't serve up .config files. If a admin of the web server overrides this default setting, then your web.config file isn't very secure. I haven't seen anyone override this setting before, and you can be sure that ALL reputable hosting companies won't change that behavior. If yours does, I would leave immediately.
You can encrypt the settings if you are worried about security..but this is only as secure as the encryption used, and whether or not the hacker can get the string needed to decrypt the setting.
I use it, because it seems to be mostly secure from the common hacker, and easy for me to use. If a hacker can get that file, they can also get your dll, and/or your database. If you store your connection string in code, and a hacker gets your dll, they can decompile it and find it anyway.
That's what I thought. Good to have a second opinion though. Thanks.
I did think about that but we have different databases for developing and production.
We test against a database that is identical to the production database apart from a prefix to the database name (the tables are the same)
Some how I would need to connect to the right database in the right situation.
The way I have done it so far is to include the connection strings in a class, I figured this way it would be compiled in to the dll, and have a session variable indicating which state I am in. This is set in Session Start.
Here is an idea. Maybe you could check HostAddress or something and see if you running on 127.0.0.1?
Your losing me. I assume you are testing the asp.net app on a dev server using a dev database. Then when you deploy your asp.net app, you put it on the production server using a production database....Is this correct?Quote:
Originally posted by davidrobin
I did think about that but we have different databases for developing and production.
We test against a database that is identical to the production database apart from a prefix to the database name (the tables are the same)
Some how I would need to connect to the right database in the right situation.
The way I have done it so far is to include the connection strings in a class, I figured this way it would be compiled in to the dll, and have a session variable indicating which state I am in. This is set in Session Start.
If so, all you need to do is have the same setting in your web.config file twice, each with a different value.
Comment out the production one when you are developing. Uncomment the production one when you are deploying, as well as comment out the dev one.