Up front it sounds like a good option. However, my first thought is, entering another encrypted id just puts me back to the same problem. How easy would it be for someone to break the encryption algorithm ? My guess is that it would be easy. Stuart --- Jasper Howard <jasper@xxxxxxxxxxxxx> wrote: > When I created a business management script for the > business I work for, it > was important that ids in url's were encrypted. What > I did was create a code > for each item that needed one. My encryption table > fields looked something > like: enc_id, encryption, table, id where enc_id was > the unique identifier > in this table, encryption was the 14 character code, > table was the table > that the encrypted data was stored in, and id was > the id of the encrypted > data. That was you can pass the 14 digit code in the > html, then when you > need to use it in a php script you can just make a > function that returns the > data from the database from the encryption code. For > extra security (since > someone could just remember the encryption code) I > added a cron job script > that changed the encryptions every midnight. If > anyone thinks something like > this would work for them, some thing to remember is > that you need to make > sure that when you add an item to the encryption > table in the db that each > code is unique. > > -- > > > -------------------------------------------------------------->> > Jasper Howard :: Database Administration > ApexEleven Web Design > 1.530.559.0107 > http://www.ApexEleven.com/ > <<-------------------------------------------------------------- > "Stuart Felenstein" <stuart4m@xxxxxxxxx> wrote in > message > news:20040920221627.4201.qmail@xxxxxxxxxxxxxxxxxxxxxxxxxx > > I'm restarting this post. I thought I was out of > the > > woods, but not. > > Here situation, in most of my update forms which > > involve 1 record, passing a session variable , > usually > > the users ID is enough. No URL param passing. > > > > Not so in two update forms I have where there are > > multiple records for each user. If I pass a > session > > variable it only brings up the first record. So > > unless I am missing something, I must pass the > record > > ID via a URL parameter. That works just great, > but > > the problems lies in the fact, that all anyone > would > > need to do is change recordID=1 to recordID=2 and > they > > can see someone elses record, which is supposed to > > confidential. > > > > Now I've looked at sights like Monster, Amazon, > Ebay, > > and tried changing the recordID in the URL area, > but > > it either ignores my change or kicked back an > invalid > > ID. > > This is even if I remove the other ID's from the > line. > > > > > > So, I'm sure this has been dealt with more, I > don't > > have the foggiest clue yet though how I can > implement > > something that either hides, or prevents a user > from > > going through records in the database by changing > the > > id number. > > > > Appreciate any suggestions or ideas. > > > > Thank you, > > Stuart > > > > > > > > > > > > --- Stuart Felenstein <stuart4m@xxxxxxxxx> wrote: > > > > > Turned out "hiding" the id wasn't necessary as > the > > > awaiting update page can grab the session ID. > > > I wasn't thinking. Sorry > > > Stuart > > > --- John Holmes <holmes072000@xxxxxxxxxxx> > wrote: > > > > > > > Stuart Felenstein wrote: > > > > > I'm still confused over one aspect of URL > > > > parameters. > > > > > As far as a form passing data back to the > > > server, > > > > I > > > > > understand about get, post and replace. > > > > > > > > > > Here is my problem. > > > > > I have an update form. User is logged in to > the > > > > > system and needs to update whatever > information. > > > > > Right now I'm including in the link the > user's > > > ID, > > > > so > > > > > when they arrive at the update page, their > > > record > > > > will > > > > > be displayed. > > > > > The problem is all one has to do is change > the > > > ID > > > > > number in the URL parameter in the update > page > > > and > > > > you > > > > > can go to someone else's record. > > > > > > > > > > How do programmers generally get around this > ? I > > > > must > > > > > be missing something. > > > > > > > > How do you identify the user once they are > logged > > > > in? There should be > > > > some way to relate the logged in user to valid > > > > records they can see. > > > > Then, if they request an invalid record, you > can > > > > show them an error > > > > page. Hiding the ID isn't going to fix > anything. > > > > > > > > -- > > > > > > > > ---John Holmes... > > > > > > > > Amazon Wishlist: > > > > www.amazon.com/o/registry/3BEXC84AB3A5E/ > > > > > > > > php|architect: The Magazine for PHP > Professionals > > > - > > > > www.phparch.com > > > > > > > > > > > > > > > > > > -- > > > PHP Database Mailing List (http://www.php.net/) > > > To unsubscribe, visit: > http://www.php.net/unsub.php > > > > > > > > -- > PHP Database Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
