RE: [PHP-DB] Where can I download the php_oci8.dll and ph_oracle.dll ?
they are in the extensions folder in the php folder. From: "Saeid Banaei" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Subject: [PHP-DB] Where can I download the php_oci8.dll and ph_oracle.dll ? Date: Tue, 21 Sep 2004 14:30:10 -0400 Hi, I am trying to use the PHP in windows, IIS environment to access an Oracle database. I need to have the php_oci8.dll and php_oracle.dll modules. From where should download them ? Please help!!! Thanks, _ Designer Mail isn't just fun to send, it's fun to receive. Use special stationery, fonts and colors. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DB] Where can I download the php_oci8.dll and ph_oracle.dll ?
Hi, I am trying to use the PHP in windows, IIS environment to access an Oracle database. I need to have the php_oci8.dll and php_oracle.dll modules. >From where should download them ? Please help!!! Thanks,
[PHP-DB] Grant Privileges on Postgres
Hi all, I run this instruction on Postgres psql tool: grant all privileges on database test to newuser; The goal is to give all privileges to newuser(user that is not a superuser) on test, the owner is postgres but I need to give this other user privileges. The problem is, after run this instruction, the confirmation GRANT apears but when I try to manipulate the database test with newuser, the database server show error permisions. Some ideas? Thank's Norma -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Passing URL parameters, how to hide
Ok guys, I think you're beating a dead horse, the idea is understood, and there are quite a few ways to do what is needed, there have been like 30 posts on this... On Tue, 21 Sep 2004 14:12:43 -0400, John Holmes <[EMAIL PROTECTED]> wrote: > From: "Stuart Felenstein" <[EMAIL PROTECTED]> > > > I still want to pass the id's through hidden. > > > > So the html in the first form looks like this: > > > > > value="recordID"> > > > > > > Form is set to post. > > Why would you pass UserID in the form when you turn around and pull it from > the session in your code? It's a waste. > > Also, with the above, if I were to change UserID to 5 (assuming that a valid > userID) and recordID to 20 (assuming that's a valid recordID that userID 5 > has access to), would I be able to see the record? I shouldn't be... > > ---John Holmes... > > > > -- > PHP Database Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- << Jasper Howard - Database Administration ApexEleven.com 530 559 0107 --->> -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Passing URL parameters, how to hide
From: "Stuart Felenstein" <[EMAIL PROTECTED]> I still want to pass the id's through hidden. So the html in the first form looks like this: Form is set to post. Why would you pass UserID in the form when you turn around and pull it from the session in your code? It's a waste. Also, with the above, if I were to change UserID to 5 (assuming that a valid userID) and recordID to 20 (assuming that's a valid recordID that userID 5 has access to), would I be able to see the record? I shouldn't be... ---John Holmes... -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Passing URL parameters, how to hide
From: <[EMAIL PROTECTED]> the encryption is random, there is no algorithm to break it, I'm not going to argue against any of the other problems with this system, but no one is going to be able to break this algorithm, its 14 characters of lowercase and upper case letters and numbers, in random order. How is this encryption? You have a unique 14 character code that identifies each record in the database. How is it any different than using md5() and uniqid() to create 32 character unique codes. Do you "decrypt" the 14 characters into useful data when you receive it? "no one is going to be able to break this algorithm" lol... you know that for a fact, do you? Number 1, we don't have to break it, we just have to find 14 characters that match another record. Number 2, if this is a true encryption of other data (such as record id, ip, whatever), then it's just a matter of determining what encryption method your using and your keys. Hard? Maybe... Impossible? No. ---John Holmes... -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Passing URL parameters, how to hide
are you using native encryption from the database ? Stuart --- [EMAIL PROTECTED] wrote: > the encryption is random, there is no algorithm to > break it, I'm not going > to argue against any of the other problems with this > system, but no one is > going to be able to break this algorithm, its 14 > characters of lowercase and > upper case letters and numbers, in random order. > > > -->> > Jasper Howard :: Database Administration > Velocity7 > 1.530.470.9292 > http://www.Velocity7.com/ > <<-- > - Original Message - > From: "Stuart Felenstein" <[EMAIL PROTECTED]> > To: "Jasper Howard" <[EMAIL PROTECTED]>; > <[EMAIL PROTECTED]> > Sent: Tuesday, September 21, 2004 1:03 AM > Subject: Re: [PHP-DB] Passing URL parameters, how to > hide > > > > 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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> wrote > in > > > message > > > > > > news:[EMAIL PROTECTED] > > > > 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 <[EMAIL PROTECTED]> > 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 <[EMAIL PROTECTED]> > > > 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 pr
Re: [PHP-DB] Passing URL parameters, how to hide
Okay, I can make that change. Stuart --- Bastien Koert <[EMAIL PROTECTED]> wrote: > > No, No, NO! > > The user id should not be in the hidden elements in > the form. > > You need to store that in a session variable for the > duration of that user's > session. Otherwise they can try to hack by changing > the combination until > they hit another valid record. > > Bastien > > >From: Stuart Felenstein <[EMAIL PROTECTED]> > >To: John Holmes <[EMAIL PROTECTED]> > >CC: [EMAIL PROTECTED] > >Subject: Re: [PHP-DB] Passing URL parameters, how > to hide > >Date: Tue, 21 Sep 2004 08:23:51 -0700 (PDT) > > > >Nope, can't get to any other record. One would > have > >to match both userid and recordID to get a hit. > >Perhaps now I should put this into a form and send > it > >via hidden fields , for another layer of > protection. > > > >Stuart > > > > > >--- John Holmes <[EMAIL PROTECTED]> wrote: > > > > > From: "Stuart Felenstein" <[EMAIL PROTECTED]> > > > > > > > So what I did was this statement: SELECT * > FROM > > > Table > > > > WHERE RecordID = blue and UserID = red > > > > blue is the variable for the recordID > > > > red is the variable for the userID > > > > > > > > So now when I change either of those variables > in > > > URL > > > > no record is returned. > > > > > > > > Did I finally get this right ? > > > > > > You tell us; can you get to any other record? > Sounds > > > like you're heading in > > > the right direction, though... > > > > > > ---John Holmes... > > > > > > > > > >-- > >PHP Database Mailing List (http://www.php.net/) > >To unsubscribe, visit: http://www.php.net/unsub.php > > > > _ > Powerful Parental Controls Let your child discover > the best the Internet has > to offer. > http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines > > Start enjoying all the benefits of MSN® Premium > right now and get the > first two months FREE*. > > -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Passing URL parameters, how to hide
--- M Saleh EG <[EMAIL PROTECTED]> wrote:
> Ur 2nd question.. Okay .. how would u use the hidden
> inputs? with
> hidden inputs.. I mean the form hidden elements
> ( 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.
>
I still want to pass the id's through hidden.
So the html in the first form looks like this:
Form is set to post.
In the update / awaiting form. I have the form waiting
to be pass the variables. Not working though ,
wondering if I'm making a mistake somewhere .
Update page (where it grabs the parameters:
$Blue__rsUpdate = '1';
if (isset($HTTP_SESSION_VARS['xx_id_x'])) {
$Blue__rsUpdate = $HTTP_SESSION_VARS['xx_id_'];
}
$Red__rsUpdate = '-1';
if (isset($HTTP_GET_VARS['recordID'])) {
$Red__rsUpdate = $HTTP_GET_VARS['recordID'];
}
Forget the 's , they are only there to protect the
innocent ;).
Stuart
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Passing URL parameters, how to hide
the encryption is random, there is no algorithm to break it, I'm not going to argue against any of the other problems with this system, but no one is going to be able to break this algorithm, its 14 characters of lowercase and upper case letters and numbers, in random order. -->> Jasper Howard :: Database Administration Velocity7 1.530.470.9292 http://www.Velocity7.com/ <<-- - Original Message - From: "Stuart Felenstein" <[EMAIL PROTECTED]> To: "Jasper Howard" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, September 21, 2004 1:03 AM Subject: Re: [PHP-DB] Passing URL parameters, how to hide > 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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> wrote in > > message > > > news:[EMAIL PROTECTED] > > > 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > > 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 up
Re: [PHP-DB] Finding the value of the COMMENT in a table column
> Hi all, > > Anyone know how to access the optional COMMENT you can add to columns > during table creation? > If you don't expect 20 diffrent answers for 20 different databases you should be more specific. Nobody knows which database do you use. /Georg -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DB] Re: PHP - FOXPRO
The following excerpt is a result found on the internet. I am not the author of that text, but as it might help, here you go: >Here's the first part: > >http://php.weblogs.com/com_php > >Using COM from PHP to get to the ADO object model. ADO is an >abstraction of OLE DB funtionality. > >The second part is connecting to an OLEDB Provider for VFP: > >http://fox.wikis.com/wc.dll?Wiki~VFP_OleDB_Provider > >That should get you going. Good luck, Stefan Reimers -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Passing URL parameters, how to hide
No, No, NO! The user id should not be in the hidden elements in the form. You need to store that in a session variable for the duration of that user's session. Otherwise they can try to hack by changing the combination until they hit another valid record. Bastien From: Stuart Felenstein <[EMAIL PROTECTED]> To: John Holmes <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED] Subject: Re: [PHP-DB] Passing URL parameters, how to hide Date: Tue, 21 Sep 2004 08:23:51 -0700 (PDT) Nope, can't get to any other record. One would have to match both userid and recordID to get a hit. Perhaps now I should put this into a form and send it via hidden fields , for another layer of protection. Stuart --- John Holmes <[EMAIL PROTECTED]> wrote: > From: "Stuart Felenstein" <[EMAIL PROTECTED]> > > > So what I did was this statement: SELECT * FROM > Table > > WHERE RecordID = blue and UserID = red > > blue is the variable for the recordID > > red is the variable for the userID > > > > So now when I change either of those variables in > URL > > no record is returned. > > > > Did I finally get this right ? > > You tell us; can you get to any other record? Sounds > like you're heading in > the right direction, though... > > ---John Holmes... > > -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php _ Powerful Parental Controls Let your child discover the best the Internet has to offer. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Passing URL parameters, how to hide
Nope, can't get to any other record. One would have to match both userid and recordID to get a hit. Perhaps now I should put this into a form and send it via hidden fields , for another layer of protection. Stuart --- John Holmes <[EMAIL PROTECTED]> wrote: > From: "Stuart Felenstein" <[EMAIL PROTECTED]> > > > So what I did was this statement: SELECT * FROM > Table > > WHERE RecordID = blue and UserID = red > > blue is the variable for the recordID > > red is the variable for the userID > > > > So now when I change either of those variables in > URL > > no record is returned. > > > > Did I finally get this right ? > > You tell us; can you get to any other record? Sounds > like you're heading in > the right direction, though... > > ---John Holmes... > > -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Passing URL parameters, how to hide
Sounds about right...I would use the session variable for the user name so that is not even present...but that is the result that you want... Bastien From: Stuart Felenstein <[EMAIL PROTECTED]> To: Bastien Koert <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED] CC: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [PHP-DB] Passing URL parameters, how to hide Date: Tue, 21 Sep 2004 08:17:43 -0700 (PDT) So what I did was this statement: SELECT * FROM Table WHERE RecordID = blue and UserID = red blue is the variable for the recordID red is the variable for the userID So now when I change either of those variables in URL no record is returned. Did I finally get this right ? Stuart --- Bastien Koert <[EMAIL PROTECTED]> wrote: > >When I > > > request "update.php?recordID=2", you should be > doing > > > something like "SELECT > > > * FROM Record_Table WHERE recordID = 2 AND > userID = > > > 3", ... _ Take advantage of powerful junk e-mail filters built on patented Microsoft® SmartScreen Technology. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Passing URL parameters, how to hide
From: "Stuart Felenstein" <[EMAIL PROTECTED]> So what I did was this statement: SELECT * FROM Table WHERE RecordID = blue and UserID = red blue is the variable for the recordID red is the variable for the userID So now when I change either of those variables in URL no record is returned. Did I finally get this right ? You tell us; can you get to any other record? Sounds like you're heading in the right direction, though... ---John Holmes... -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Passing URL parameters, how to hide
So what I did was this statement: SELECT * FROM Table WHERE RecordID = blue and UserID = red blue is the variable for the recordID red is the variable for the userID So now when I change either of those variables in URL no record is returned. Did I finally get this right ? Stuart --- Bastien Koert <[EMAIL PROTECTED]> wrote: > >When I > > > request "update.php?recordID=2", you should be > doing > > > something like "SELECT > > > * FROM Record_Table WHERE recordID = 2 AND > userID = > > > 3", ... -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Passing URL parameters, how to hide
From: "Bastien Koert" <[EMAIL PROTECTED]> You can also validate the IP of the user for the session. Since many people are still on dialup, they do not have a static IP and therefore its of little value to store...but it should remain the same for the session. IP addresses are pretty much worthless unless you're on an intranet where you can control them. Thats why I said CAN, since it is unreliable That's why I said ARE, since I drive a Dodge. ---John Holmes... -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Passing URL parameters, how to hide
Thats why I said CAN, since it is unreliable Bastien From: "John Holmes" <[EMAIL PROTECTED]> To: "Bastien Koert" <[EMAIL PROTECTED]>,<[EMAIL PROTECTED]>,<[EMAIL PROTECTED]> CC: <[EMAIL PROTECTED]>,<[EMAIL PROTECTED]> Subject: Re: [PHP-DB] Passing URL parameters, how to hide Date: Tue, 21 Sep 2004 10:22:32 -0400 From: "Bastien Koert" <[EMAIL PROTECTED]> You can also validate the IP of the user for the session. Since many people are still on dialup, they do not have a static IP and therefore its of little value to store...but it should remain the same for the session. IP addresses are pretty much worthless unless you're on an intranet where you can control them. The IP address of a user can change in the middle of a session and multiple users can have the same IP address (using proxies, for example). I wouldn't rely on them for anything. ---John Holmes... -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php _ Take advantage of powerful junk e-mail filters built on patented Microsoft® SmartScreen Technology. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Passing URL parameters, how to hide
When I > request "update.php?recordID=2", you should be doing > something like "SELECT > * FROM Record_Table WHERE recordID = 2 AND userID = > 3", which will not > return any rows. Okay that makes sense I will try that. Though I'd imagine the SQL will need to be different since I could be dealing with hundreds, thousanda etc of records. No the SQL is the same for 1 record or 10 million...What you may need to do is put an index or two on the table that match the where clause to speed up the searchthat's it. Bastien _ Take charge with a pop-up guard built on patented Microsoft® SmartScreen Technology http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Passing URL parameters, how to hide
--- John Holmes <[EMAIL PROTECTED]> wrote: > From: "Stuart Felenstein" <[EMAIL PROTECTED]> > > For whatever reason I can not use session only > here. > > It does not return the correct record from the > table. > > Don't say that you cannot use sessions, just say > that you haven't figured > out how to correctly use them, yet. Okay, I can admit that much ;) > > 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. > > What do you mean by "session ID" here? What is that? I *think* what would be commonly referred to as session variables. Consisting of Username, UserID (the original id assigned to user with registration, and access level. > > > e.g. > > Record_Table > > > > recordID userID info1name info1details > > 1 3 somenamesos > > 2 4 somenamesos > > 3 3 somenamesos > > 4 4 somenamesos > > 5 3 somenamesos > > 6 5 somenamesos > > Okay, so explain this table structure to us. If I > log in as UserID #3, does > that mean I have access to records 1, 3 and 5? Correct > How do you remember that I'm UserID #3 as I go > throughout the site? By using both the UserID and AccessLevel. Pages are marked with a "restrict access" to a certain level or type. Generally the pages that are restricted now are form pages. So there is also a grabbing of the session varaible , in this case the userid. When I > request "update.php?recordID=2", you should be doing > something like "SELECT > * FROM Record_Table WHERE recordID = 2 AND userID = > 3", which will not > return any rows. Okay that makes sense I will try that. Though I'd imagine the SQL will need to be different since I could be dealing with hundreds, thousanda etc of records. Stuart -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DB] PHP - FOXPRO
HELLO FRIENDS I NEED KNOW HOW CAN CONNECT PHP WHIT A FREE TABLE IN FOXPRO I HAVE ADODB FOR PHP, BUT I DON`T KNOW NOW PROGRAMER PLEASE, HELP ME I NEED CODE SAMPLE AttE :-Eduardo Cortés C.Ingeniero Informático-Empresas Verschae M.R-TEL : 032 - 267326 -
Re: [PHP-DB] Passing URL parameters, how to hide
From: "Bastien Koert" <[EMAIL PROTECTED]> You can also validate the IP of the user for the session. Since many people are still on dialup, they do not have a static IP and therefore its of little value to store...but it should remain the same for the session. IP addresses are pretty much worthless unless you're on an intranet where you can control them. The IP address of a user can change in the middle of a session and multiple users can have the same IP address (using proxies, for example). I wouldn't rely on them for anything. ---John Holmes... -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Passing URL parameters, how to hide
Ok, so you can't store the record id in the session, no problem. Assuming
you store the userid in a session, you can pass the record id in the hidden
field.
Then when retreiving the data, after validating the record_num
How to validate:
If you know that the record_is id only numeric, then check for that, if its
alpha and of a certain length, check for that, if there is a pattern to the
record_id (like AA-123) then use regex to check the data.
You can also validate the IP of the user for the session. Since many people
are still on dialup, they do not have a static IP and therefore its of
little value to store...but it should remain the same for the session.
$sql = 'select * from tableName where record_id = $record_id and user_id =
{$_SESSION['user_id']}';
$result = mysql_query($sql);
if (mysql_num_rows($result)!= 1){
//either more than 1 row or no rows so present the user with an error
message and the form / page to choose their record again
}else{
//data retreived is ok...so pass the results to the user in form or
whatever
}//end if
As for the design/build of the security system, its up to you. But the one
thing that is useful is that you can use over and over if its well designed,
Bastien
From: Stuart Felenstein <[EMAIL PROTECTED]>
To: Bastien Koert <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: [PHP-DB] Passing URL parameters, how to hide
Date: Tue, 21 Sep 2004 06:45:48 -0700 (PDT)
See response interspersed:
--- Bastien Koert <[EMAIL PROTECTED]> 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 somenamesos
2 4 somenamesos
3 3 somenamesos
4 4 somenamesos
5 3 somenamesos
6 5 somenamesos
> 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 <[EMAIL PROTECTED]>
> >Reply-To: M Saleh EG <[EMAIL PROTECTED]>
> >To: Stuart Felenstein <[EMAIL PROTECTED]>
> >CC: Jasper Howard <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED]
> >Subject: Re: [PHP-DB] 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,(
Re: [PHP-DB] Passing URL parameters, how to hide
From: "Stuart Felenstein" <[EMAIL PROTECTED]> For whatever reason I can not use session only here. It does not return the correct record from the table. Don't say that you cannot use sessions, just say that you haven't figured out how to correctly use them, yet. 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. What do you mean by "session ID" here? What is that? e.g. Record_Table recordID userID info1name info1details 1 3 somenamesos 2 4 somenamesos 3 3 somenamesos 4 4 somenamesos 5 3 somenamesos 6 5 somenamesos Okay, so explain this table structure to us. If I log in as UserID #3, does that mean I have access to records 1, 3 and 5? How do you remember that I'm UserID #3 as I go throughout the site? When I request "update.php?recordID=2", you should be doing something like "SELECT * FROM Record_Table WHERE recordID = 2 AND userID = 3", which will not return any rows. So now you can say "Record does not exist or you do not have access to it". Do the same thing when you UPDATE the record "UPDATE Record_Table SET info='$info' WHERE recordID=2 AND userID=3". that update will not update anything if they userID doesn't match and you can show an appropriate message (there's usually an "affected_rows()" function for your database that's useful here). You still need to validate "recordID" to ensure it's an integer before you put it in your query and ensure user's can't change their own userID, but hopefully you're getting the idea, now... ---John Holmes... (FYI: Please trim your posts) -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Passing URL parameters, how to hide
ACL ?? Is that Account Control Language ? Maybe that is something I should use. Stuart --- M Saleh EG <[EMAIL PROTECTED]> 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 > <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > > >Reply-To: M Saleh EG <[EMAIL PROTECTED]> > > >To: Stuart Felenstein <[EMAIL PROTECTED]> > > >CC: Jasper Howard <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] > > >Subject: Re: [PHP-DB] 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 > ( > >name="id" val
RE: [PHP-DB] Passing URL parameters, how to hide
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:[EMAIL PROTECTED] > Sent: Tuesday, September 21, 2004 9:46 AM > To: Bastien Koert; [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: [PHP-DB] Passing URL parameters, how to hide > > > See response interspersed: > --- Bastien Koert <[EMAIL PROTECTED]> 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 somenamesos >2 4 somenamesos >3 3 somenamesos >4 4 somenamesos >5 3 somenamesos >6 5 somenamesos > > > > > 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 <[EMAIL PROTECTED]> > > >Reply-To: M Saleh EG <[EMAIL PROTECTED]> > > >To: Stuart Felenstein <[EMAIL PROTECTED]> > > >CC: Jasper Howard <[EMAIL PROTECTED]>, > > [EMAIL PROTECTED] > > >Subject: Re: [PHP-DB] 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 >
Re: [PHP-DB] Passing URL parameters, how to hide
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > >Reply-To: M Saleh EG <[EMAIL PROTECTED]> > >To: Stuart Felenstein <[EMAIL PROTECTED]> > >CC: Jasper Howard <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > >Subject: Re: [PHP-DB] 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 ( >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 > ><[EMAIL PROTECTED]> wrote: > > > See my response interspersed: > > > > > > --- M Saleh EG <[EMAIL PROTECTED]> wrote: >
Re: [PHP-DB] Passing URL parameters, how to hide
See response interspersed: --- Bastien Koert <[EMAIL PROTECTED]> 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 somenamesos 2 4 somenamesos 3 3 somenamesos 4 4 somenamesos 5 3 somenamesos 6 5 somenamesos > 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 <[EMAIL PROTECTED]> > >Reply-To: M Saleh EG <[EMAIL PROTECTED]> > >To: Stuart Felenstein <[EMAIL PROTECTED]> > >CC: Jasper Howard <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] > >Subject: Re: [PHP-DB] 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 > ( >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 > ><[EMAIL PROTECTED]> wrote: > > > See my response interspersed: > > > > > > --- M Saleh EG <[EMAIL PROTECTED]> 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 h
Re: [PHP-DB] Passing URL parameters, how to hide
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 <[EMAIL PROTECTED]> Reply-To: M Saleh EG <[EMAIL PROTECTED]> To: Stuart Felenstein <[EMAIL PROTECTED]> CC: Jasper Howard <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject: Re: [PHP-DB] 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 () 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 <[EMAIL PROTECTED]> wrote: > See my response interspersed: > > --- M Saleh EG <[EMAIL PROTECTED]> 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
Re: [PHP-DB] Passing URL parameters, how to hide
From: "Stuart Felenstein" <[EMAIL PROTECTED]> --- M Saleh EG <[EMAIL PROTECTED]> wrote: You should always avoid passing Record IDs through URL parameters. Use form Hidden fields instead! Hidden form fields are still passed in the URL unless you're using a POST method for your form. It doesn't matter if the ID is passed in the URL or hidden in POST data, though, the users can still change it. Hiding data in POST offers no more security than passing it in the URL, it just slows dedicated people down for a few seconds, if that. 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 ? No, there are not. No web based app can stop the URL from being changed. The best way to handle this is to set up a permissions table that says "User 1234" has permission to view/edit/delete ID numbers 10, 20 and 30. If that user requests any other ID number, then show a failure. If that user tries to send data to update any other ID, then show a failure. If a user only has (and only ever will have) access to their own record, then it's even easier to store their ID in the $_SESSION and send a failure if there's a request or update for any other ID number. "encrypting" the ID (notice the quotes), hiding it in POST, etc are mostly "security through obscurity", meaning they just slow people down a little but usually offer no additional security. If implemented correctly, they may not be a bad idea, but they should only be used in addition to an actual security setup like I described above. There may still be issues with your login code, how you're remembering who users are, etc... but that's another email. :) ---John Holmes... -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Passing URL parameters, how to hide
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 () 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 <[EMAIL PROTECTED]> wrote: > See my response interspersed: > > --- M Saleh EG <[EMAIL PROTECTED]> 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 > > > > > > On Mon, 20 Sep 2004 15:32:07 -0700, Jasper Howard > > <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> wrote in > > message > > > > > > news:[EMAIL PROTECTED] > > > > > > > > > > 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 eno
[PHP-DB] session
Execuse me, i know i am not putting my question in right mail forum but i
trust that many of you can give me the right answer. also request you to
kindly give me email add. of mailing list where this type question should be
put up.
i am using
session_cache_limiter("public");
in one of my webpages, now when i click on logout (where i used
session_destroy() function), it works well but when i press back button of
brower it comes to my same page from where i logged out. i can not remove
the session_cache_limiter("public") because i am using this function to
remember data. is there any other option so that after logout the back
button could not show the same page.
with best wishes
balwant
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Passing URL parameters, how to hide
See my response interspersed: --- M Saleh EG <[EMAIL PROTECTED]> 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 > > > On Mon, 20 Sep 2004 15:32:07 -0700, Jasper Howard > <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> wrote in > message > > > news:[EMAIL PROTECTED] > > > > > > > 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 <[EMAIL PROTECTED]> > 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 <[EMAIL PROTECTED]> > 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
Re: [PHP-DB] Passing URL parameters, how to hide
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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> wrote in > message > news:[EMAIL PROTECTED] > > 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > 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://ww
