Hi, I have a list of books obtained from the database. When a user selects a book, I'd like it to retrieve the information for that book and display it on screen. However, I'd like to keep the ID of the book hidden from the client-side, so what would be the best way to transfer the ID of the selected book? I think my brain has melted, so I'm probably missing something obvious. Sessions seem to be the only way to not have any ID information transferred, but I'm not sure how to implement a system where an item is selected (from whichever control type is most suited) and the ID of the item is somehow picked up by the server and the relevant information retrieved. (Using ASP.NET + SQL Server). Thanks for any advice
A:
I am not sure I understand your question, because the answer seems too obvious: just don't send the entity's id to the client. Use it on the server side to compose the ASP.NET page, but don't include the id itself on the output page that is sent to the client.
Does this make sense? :-)
CesarGon
2009-12-01 00:57:46
@downvoter: a comment is appreciated if you downvote; it really helps to learn what is the problem with one's answer. Thanks.
CesarGon
2009-12-01 01:12:25
Hashes are a one way mapping and cannot be used as a unique key; you can also perform an analysis to get the correspondence between hash and book-id
Hassan Syed
2009-12-01 01:17:34
Well, sure. That's why I am asking if my answer makes sense. The requirements of entity identification on the client side are quite vague in the question. I am trying to create a dialogue here! :-)
CesarGon
2009-12-01 01:20:19
The problem with this is how does the ASP.NET page know which book ID to use to generate the page or the images on the page? (I wasn't the downvoter!)
RickNZ
2009-12-01 04:47:23
Thanks for the reply, but I don't understand how this would work. Even if I use a hash, how would the server know which hash to test for?
keyboardP
2009-12-01 15:27:13
A:
How about using a "pseudo id" for each book? I am assuming you need something on the client side to tell the server which book the client chose.
Generate a Guid for each book to use as the web side "pseudo id", that should keep the real id fairly secure.
Moose
2009-12-01 01:01:24
Guid's are a viable option, although inferior to remus's solution. The de facto GUID scheme (of which microsoft is an instance) is bloated and nasty to generate. Plus it takes a 16-byte (primary ?) key entry in the database; it also requires a database trip for the web-server to retrieve state. I suggest reversable encryption like Remus suggested. Blowfish is a nice (very efficient) algorithm for encryption.
Hassan Syed
2009-12-01 01:14:08
Seems like it's one or the other. A round trip to to database (which will probably happen anyway once you have the key) or decryption. Creating a Guid is simple with .Net, and it was just a suggestion. You could just as easily generate a random 4 byte integer and use that. Sounds like some hate for Guids going on.
Moose
2009-12-01 01:55:45
+4
A:
Do you really want to hide the database id from the user, as in a scenario where the user has some alternate access to the database and you want him to search for the book the hard way?
Usually the requirement is not to keep the ID secret, but to prevent the user from figuring out IDs of other items (eg. to enforce a certain funnel of navigation to reach an item) or from sharing the ID with other users. So for example is ok to have an URL http://example.com/books/0867316672289 where the 0867316672289 will render the same book to the same visitor, but the user cannot poke around the value, so 0867316672288 or 0867316672290 will land 404s. It may also be required that another user entering 0867316672289 gets also a 404.
Keeping the ID truly 'secret' (ie. storing it in session and having the session state keep track of 'current book') adds little value over the scheme described above and only complicates things.
One solution is to encrypt the IDs using a site secret key. From a int ID you get a 16 bytes encrypted block (eg if AES block size is used) that can be reverted back by the site into the original ID on subsequent visits. Visitors cannot guess other IDs due to the sheer size of the solution space (16 bytes). If you want also to make the pseudo-ids sticky to an user you can make the encryption key user specific (eg. derived from user id) or add extra information into the pseudo-id (eg. encrypt also the user-id and check it in your request handler).
Remus Rusanu
2009-12-01 01:01:46
Thanks, I think I'll go with the encryption. The books are not for public display, but only available to the person who has written it or who has been invited by the author. So another check is done for permission, but I'm trying to keep the inner workings exposure to a minimum. I like the idea of the encryption so may well store the encrypted value in a hidden field, so I can retrieve it from when the user selects a book.The ID's are simply integers, so guessing that isn't too tricky, but I'd like to add extra protection by only accepting well-formed URLs with the correction encryption data.
keyboardP
2009-12-01 15:19:49
Perhaps http://stackoverflow.com/questions/396164/exposing-database-ids-security-risk ? the link in your post takes to Google page-speed
Remus Rusanu
2009-12-01 01:11:32