ACL ?? Is that Account Control Language ? Maybe that is something I should use. Stuart --- M Saleh EG <m.saleh.eg@xxxxxxxxx> wrote: > I agree with John Holmes. > It's all the matter of obfuscating in this case. > > The real deal & structure is to have a set of > permission checking! > This is where ACL comes into play. But I asume ur > app is not that of a > big one for u to make a set of permissions based > actions and gui's. So > staticaly just check if the user is the same user or > have access to a > certain record. > > Again as John Holmes mentioned, Hiding or encrypting > ur data is just a > way of making it tough to break in. But the points I > mentioned earlier > about checking and securing ur code before hitting a > trip to ur DB. > Checking ur datatypes... n integrity... will save u > time instead of > thinking how to hide it, think of how to secure it > even if it's open! > so ACL comes into play. > > That's my opinion. > > > On Tue, 21 Sep 2004 09:27:26 -0400, Bastien Koert > <bastien_k@xxxxxxxxxxx> wrote: > > Hi Guys > > > > Just to jump in here. I really need to disagree > with any method of hiding > > the 'record id' > > > > How is hiding the record ID in the hidden input > any safer than in the > > URL...simple answer: it isn't...it will prevent > the unsophisticated user > > from changing the value, but its not even > challenge to a seasoned user. Same > > goes for cookies. > > > > 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. > > > > 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' > > > > 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) 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. > > > > Designing this is tricky and its a lot of work, > but when complete, its > > portable (you can use the framework in many > applications) and its secure. > > Basically you build an admin area, whereby some > trusted users have admin > > privileges and assign those to various users. The > permissions themselves are > > simply yes/no fields, assigned with checkboxes or > radio buttons. > > > > 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 > === message truncated === -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
