It's really hard to tell what you mean by, "For whatever reason I can not use session only here. It does not return the correct record from the table. Maybe that doesn't make anysense." without looking at the code you have. However, the session does not, itself, actually return any of your data. The session variables hold what you tell them to hold. Therefore, when you pull data from a session variable, it's data that you put there in the first place. So there must be some error in either the code you use to assign values to your session variables or in the page-level code. It's pretty easy, if you're not paying careful attention, to accidentally change the value of a session variable or to have a naming conflict between a session variable and a page-level variable. I ran into this a couple weeks ago and it took me a little while to figure out what was going on. You might want to carefully and deliberately walk through each step of your existing code to find out exactly why the correct data is not being returned from the table. Rich > -----Original Message----- > From: Stuart Felenstein [mailto:stuart4m@xxxxxxxxx] > Sent: Tuesday, September 21, 2004 9:46 AM > To: Bastien Koert; m.saleh.eg@xxxxxxxxx > Cc: jasper@xxxxxxxxxxxxx; php-db@xxxxxxxxxxxxx > Subject: Re: Passing URL parameters, how to hide > > > See response interspersed: > --- Bastien Koert <bastien_k@xxxxxxxxxxx> wrote: > > > To be entirely honest, there is no real reason not > > to use the url to pass data, IF the data is not > > sensitive. For sensitive data, sessions are the > > best thing to use. HIdden fields are good only to > > keep the users from accidently changing the id to > > something. > > For whatever reason I can not use session only here. > It does not return the correct record from the table. > Maybe that doesn't make anysense. In the listing of > recods where the user would click to go update, there > is a repeat region SQL statement that shows all > records from table under session ID. > > e.g. > Record_Table > > recordID userID info1name info1details > 1 3 somename sos > 2 4 somename sos > 3 3 somename sos > 4 4 somename sos > 5 3 somename sos > 6 5 somename sos > > > > > This doesn't negate the need to validate the > > incoming data, ALL incoming data needs to be > > validated and exceptions need to be > > handled. So if the user changes the id number to > > something else, then a message should appear saying > > 'no record found' > > This sounds fine and from what I've seen the common > method. So what form of validation does one use to do > this ? > > > A better approach to securing sensitive data is to > > use the database and to develop a system whereby > > usiers can only access their own limited data. > > There is a little more data involved here (like > > storing a user_id with the row) > > See above, user_id is stored in row > > > This user_id can then be associated with users > record > (profile) and that profile could be used to > determine > whether the user can view/edit/access the > particular > record. The user's profile is stored in a > > > session (or it could be validated every time there > > is db interaction) and those values determine > exactly > which records the user can do anything with. > > You can build profiles that could llimit the access > > to data belonging to a > > particular group of users, a particular region of > > the country or to a single > > location, depending on the structure of the compnay > > and the desired goals of > > the system. > > In my system, users cant' just change data anywhere. > The are forms to insert in particular tables, and > update forms when the need to change info arises. > I am not sure that what you speak about here is > practicle or necessary for this application > > > Stuart > > > > Bastien Koert > > > > > > > > >From: M Saleh EG <m.saleh.eg@xxxxxxxxx> > > >Reply-To: M Saleh EG <m.saleh.eg@xxxxxxxxx> > > >To: Stuart Felenstein <stuart4m@xxxxxxxxx> > > >CC: Jasper Howard <jasper@xxxxxxxxxxxxx>, > > php-db@xxxxxxxxxxxxx > > >Subject: Re: Passing URL parameters, how > > to hide > > >Date: Tue, 21 Sep 2004 15:19:32 +0400 > > > > > >1-So I'm going to ask, how does PHP stop a URL from > > >being changed ? Are there specific functions that > > >block that type of activity ? > > > > > >I said :" I personaly dont recommand using url > > parameters for > > > passing record ids, i'd rather use hidden inputs, > > > sessions, or even cookies but never URI > > >querystrings for record ids. " > > > > > >2-Stuart Felenstein askes : "Can you explain a bit > > further how an hidden > > >input > > >might work ?" > > > > > >I'll answer ur first question here. The addresses > > on the browsers are > > >in control of the users. you cant control that. > > wat's on the client > > >side is only controlled by the client which is the > > browser. So u cant > > >stop changing the address,( the work around is > > using a popup that > > >wouldnt show the address but still a person with > > abit of knowledge > > >would figure out openning a new window hisself n > > entering the address > > >so it aint practical). Instead you can validate the > > ID that is comming > > >from the URI. How's that? alright, Your check the > > ID weather with > > >encryption or not if it matches with the ID of the > > user logged in show > > >the form if not that's it show the error page. > > > > > >Ur 2nd question.. Okay .. how would u use the > > hidden inputs? with > > >hidden inputs.. I mean the form hidden elements > > (<input type="hidden" > > >name="id" value="recordID" />) so instead of having > > hyperlinks > > >pointing to the form page use a form with submit > > btns that post the > > >hidden id to the page that shows the user forms. > > That is by fetching > > >the recordID by post. > > > > > >Hope it's useful. > > > > > > > > >On Tue, 21 Sep 2004 01:20:42 -0700 (PDT), Stuart > > Felenstein > > ><stuart4m@xxxxxxxxx> wrote: > > > > See my response interspersed: > > > > > > > > --- M Saleh EG <m.saleh.eg@xxxxxxxxx> wrote: > > > > > > > > > You should always avoid passing Record IDs > > through > > > > > URL parameters. > > > > > Use form Hidden fields instead! > > > > > > > > I agree. Even as someone with limited > > experience. > > > > That is why I'm trying to figure out the right > > way to > > > > do it. The record ID is hidden in form itself. > > > > The way to get to the update form for that > > record is > > > > via a hyperlink. I'm not sure how to get the > > user to > > > > the update form without the hyperlink or how to > > hide > > > > the id part of the url parameter in the link. > > > > > > > > > In your case, when ur selecting the users form > > data > > > > > from the record check if it's the same user if > > not > > > > > then if he tries to change the ID from the URI > > > > > Parameter just block it. > > > > > > > > Yes, I think this is the way to go. And I'm > > halfway > > > > there, in that , if someone changed the id and > > brought > > > > up another users record, and they attempted to > > make > > > > changes the update would fail. > > > > > > > > So I'm going to ask, how does PHP stop a URL > > from > > > > being changed ? Are there specific functions > > that > > > > block that type of activity ? > > > > > > > > > I personaly dont recommand using url > > parameters for > > > > > passing record ids, i'd rather use hidden > > inputs, > > > > > sessions, or even cookies but never URI > > > > querystrings > for record ids. > > > > > > > > Can you explain a bit further how an hidden > > input > > > > might work ? > > > > > > > > > Better use of URI querystrings would be for > > logic, > > > > > section, category, > > > > > decision, options rather than important data > > such as > > > > > ur table primary > > > > > keys! > > > > > > > > Agreed! > > > > > > > > > > > > > > Hope this is useful. > > > > > > > > Very useful, thank you! > > > > > > > > Stuart > > > === message truncated === > > -- > 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
