The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Best place to store data

Hi,

I have an asp.net application that based upon the url will read a company id from my sql db. This allows me to display different data in the app based upon the id. Has anyone done anything similar? Where would be the best place to store the id, in session or viewstate or somewhere else?

Thanks
Kieran
Kieran
Monday, July 03, 2006
 
 
Think about what scope / lifetime you need for that data.

Viewstate, Session, Cookie are all good options with different characteristics
Locutus of Borg Send private email
Monday, July 03, 2006
 
 
Thanks. I guess as the id will be based upon the URL, then it could be set for the application on first request and then remain for all users, this would result in less hits on the db. Does that make sense?

Kieran
Kieran
Monday, July 03, 2006
 
 
Hi Kieran, if you make the company id an application-level variable so that all users of your site share it, then what happens when another user for a different company tries to use your site with a different company id in the url?  Also, relying on the company id in the URL will allow people to view other companies data (dont know if that is ok in your case or not). 

following on what Locutus said, google "MSDN viewstate session cookie" for more background.
Parker
Monday, July 03, 2006
 
 
In practice, it's fairly rare to transmit an id as part of the URL.

If you require the user to log into the system or otherwise transmit his credentials (such as Microsoft's Active Directory, or MIT's Kerberos), you capture that information, verify it, and save the results in a viewstate, session or cookie, which is then automatically associated with that user regardless of the URLs used.

As Parker hinted, if you rely upon...

http://www.kieran.com/ViewPrivateData.asp?id=55

...then it becomes extremely trivial for someone else to come along and change that URL to...

http://www.kieran.com/ViewPrivateData.asp?id=70

...and see that person's data.

That said, this concept is useful for finding documents, parts, items, inventory, goods, etc, that are normally identified by a unique number, and are visible to everyone.  For example...

http://www.kieran.com/GetBookByID.asp?id=54384

...makes perfect sense.
TheDavid
Monday, July 03, 2006
 
 
For the ID of the logged in user, I use the session. For any other ID, I pass it in the URL and encrypt the query string.
sloop
Monday, July 03, 2006
 
 
I would store it in viewstate. Storing it in session is also possible but keep in mind that more than one browser instance on the same computer can potentially access the same session variables. This means that if you are doing some sort of company report, the user couldn't open two browser instances and access different company records. A general rule of thumb is to keep user specific stuff in session variables and page specific stuff in viewstate or other hidden fields. But that's just my opinion. It really depends on the type and use of the data.

By the way... when did including data in a url become more popular than the old tried and true method of posting back form data?
johnny bravo
Monday, July 03, 2006
 
 
If client1 will have a url such as client1.system.com and client2, client2.system.com and they both point at the same system, what would be the best way to identify which client is currently accessing the system and load their data. For example the sql table may look like:

1  Client1    client1.system.com
2
Kieran
Tuesday, July 04, 2006
 
 
...continued, sorry!

2    Client2    client2.system.com

How can I identify which url is coming in and then load their data only from the one system? This is a public system and so they url ideally needs to remain clean.

Has anyone done anything similar?

Kieran
Kieran
Tuesday, July 04, 2006
 
 
"By the way... when did including data in a url become more popular than the old tried and true method of posting back form data?"

It never was more popular. The GET method just happens to be the default and people have to be told to use POST instead.

However, I do it this way in my examples because it's a lot easier to describe what's being sent.
TheDavid
Thursday, July 06, 2006
 
 
"How can I identify which url is coming in and then load their data only from the one system?"

Why would you want to save this in a SQL table?

Every time a user requests a web page, the special http variables REMOTE_HOST, REMOTE_ADDR and REMOTE_USER uniquely identify the user.  SERVER_NAME and SERVER_PORT tells you exactly where they are connecting to.

So it's very easy to write code (in whatever language you're using) that essentially says...

If ( SERVER_NAME == "dev.kieran.com" ) {
  // this is a developer
  send_debugging_info();
}

If ( REMOTE_HOST == 127.0.0.1 ) {
  // this is someone connecting from this machine
  send_system_admin_stuff();
}

If ( REMOTE_USER == "Kieran" ) {
  // this is the author of the software
  open_super_secret_backdoor();
}

And as such, you can set up a series of rules on what to do based on the type of connections being made. If you don't want to put "dev.kieran.com" and "Kieran" directly in the code, put those values into a configuration file.  That way your website still works even if the database server is down.
TheDavid
Thursday, July 06, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz