> granted that that is true. however doesn't CF or any other programming > language do the same thing. and if the way your getting at > the data is by > using form and url parameter, then it's very easy for me to > do from the > website and not even bother to try hack the database. using > client variables > and session variables make this a little harder but not > impossible.
I was just thinking about this issue today myself since I'm currently working on something that involves the privacy issues of a lot of users. My initial thought was to do something such as just using Encrypt() and Decrypt() to put all variables encoded into one long form/url string. Though on a page with a lot of links, that would be way too CPU intensive, and its just a hack job around a good security plan (though I can see its usefulness as just one small part of a plan-- I tend to encrypt any somewhat sensitive or easily altered data in Client/Cookie/Session scopes for instance). The solution would be to make a role based security scheme to take care of that problem. In theory, it shouldn't matter if someone is manually entering in ID's of things via Form/URL strings which they want to see so long as you are checking their permission level to that specific record. > Also if > you're the type of person that likes to use integers for primary keys > instead of unique identifiers, then I can see you getting at > anything in the > database from a stored procedure. > As others have said, you could probably just use GUID's if you are that worried. The additional layer of security would negate the minute added CPU time needed to generate GUID's if the application needed the additional security. Again, if you are controlling / checking access to records (essentially treating all data from forms and URL's as if it were a virus), it shouldn't be a problem to begin with. One of the other things I could think of being bad about using plain incrementing integers is that unless you start at a random point of assigning ID's, people could perhaps get a general idea of how many records for that type of data exist in the database. Random ID's (a la Access) are very problematic if you ever need to 'upsize' data to a different database server or environment (i.e. I could see how they could be a pain for clustering and/or replication). Or maybe just the recent experience of upsizing a replicated Access DB pool w/ random ID's to SQL Server has left a bad taste in my mouth. :) - Brandon -------------------------------------- http://spooled.net http://booms.net FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
