Re: [PHP] $_POST value disappearing?
Jônatas Zechim wrote: Hi.. You need to use $_FILES ( http://php.net/manual/pt_BR/reserved.variables.files.php) Regards, Jônatas Zechim Thanks guys. Donovan -- D Brooke -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST value disappearing?
On Tue, 2011-08-02 at 10:04 -0500, Donovan Brooke wrote: > Hello!, > > I must not be understanding something as I would expect 'f_file' > to show up in the print_r below.: > > ---form-- > > > > > > > ---endform-- > > --index.php-- > > --/index.php-- > > > > > The result I get is: > > Array > ( > [f_ap] => upload > [f_action] => doit > ) > --- > > Can someone enlighten me? > > Thanks, > Donovan try print_r($_FILE) (i think, it's either FILE or FILES) Steve. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST value disappearing?
On 2 August 2011 16:11, Richard Quadling wrote: > On 2 August 2011 16:04, Donovan Brooke wrote: >> Hello!, >> >> I must not be understanding something as I would expect 'f_file' >> to show up in the print_r below.: >> >> ---form-- >> >> >> >> >> >> >> ---endform-- >> >> --index.php-- >> >> --/index.php-- >> >> >> >> >> The result I get is: >> >> Array >> ( >> [f_ap] => upload >> [f_action] => doit >> ) >> --- >> >> Can someone enlighten me? > > Check out $_FILES for the file upload information. http://php.net/manual/en/features.file-upload.php -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST value disappearing?
On 2 August 2011 16:04, Donovan Brooke wrote: > Hello!, > > I must not be understanding something as I would expect 'f_file' > to show up in the print_r below.: > > ---form-- > > > > > > > ---endform-- > > --index.php-- > > --/index.php-- > > > > > The result I get is: > > Array > ( > [f_ap] => upload > [f_action] => doit > ) > --- > > Can someone enlighten me? Check out $_FILES for the file upload information. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST value disappearing?
Le 02/08/2011 17:04, Donovan Brooke a écrit : Hello!, I must not be understanding something as I would expect 'f_file' to show up in the print_r below.: --index.php-- --/index.php-- try *: * ;)
Re: [PHP] $_POST value disappearing?
Hi.. You need to use $_FILES ( http://php.net/manual/pt_BR/reserved.variables.files.php) Regards, Jônatas Zechim PHP & jQuery specialist http://zechim.com mob +55 11 7053 2239 skype ID zechim On 2 August 2011 12:04, Donovan Brooke wrote: > Hello!, > > I must not be understanding something as I would expect 'f_file' > to show up in the print_r below.: > > ---form-- > > > > > > > ---endform-- > > --index.php-- > > --/index.php-- > > > > > The result I get is: > > Array > ( >[f_ap] => upload >[f_action] => doit > ) > --- > > Can someone enlighten me? > > Thanks, > Donovan > > > -- > D Brooke > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP] $_POST vars
Guys - the problem has been solved. Give it a rest. (sent only to the list) (remainder deleted for the benefit of all :) ) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vars
On Thursday, 14 April 2011 at 23:08, Nathan Nobbe wrote:
On Thu, Apr 14, 2011 at 2:53 AM, Stuart Dallas wrote:
> > On Thursday, 14 April 2011 at 07:11, Nathan Nobbe wrote:
> > On Wed, Apr 13, 2011 at 3:30 PM, Stuart Dallas wrote:
> > > > On Wednesday, 13 April 2011 at 19:47, Nathan Nobbe wrote:
> > > > I never make any assumptions about the source of any data when I'm
> > > > developing software, whether in PHP or not. Returning to a previous
> > > > point, usage of global variables as the source of data anywhere other
> > > > than the initial script a request hits is tantamount to negligence. But
> > > > that's just my opinion.
> > > Who said you should make assumptions. One thing you know is that $_POST
> > > was populated by the contents of HTTP POST, or most of it anyways, lol.
> >
> > Again, I don't see how that "knowledge" is useful?
>
> you know what doesn't belong there.
It's coming from the client, over which you have no control whatsoever. It
doesn't matter what you think you know about what it should contain, you
actually don't know anything about what it does contain and you should write
your code accordingly. You can't afford to assume anything about data coming
into your application from sources you don't control.
> > > Here's an example, suppose you have an object, any object in php should
> > > let you dynamically create a public member variable on it on the fly
> > > unless there's an explicit override in __get().
> > >
> > > $oXml = new
> > > SimpleXmlElement('real-data');
> > >
> > > now someone decides to use it to store something clever, because they
> > > can, and it's so much easier than creating an appropriate location
> > >
> > > $oXml->myCleverValue = 'something unrelated';
> > >
> > > whoops the client web service stopped processing our request successfully
> > > because the clever new node inadvertently broke the validation against
> > > the xsd.
> > >
> > > or I'm running through some code and see it in a for loop
> > >
> > > foreach($oXml as $node => $value)
> > >
> > > but I don't see any clever value in the docs from the vendor..
> > >
> > > Separation of concerns for data. The same reason you have a typical
> > > directory structure on an operating system and the same reason you don't
> > > have 10 projects all in the same vcs repository. but nothing is written
> > > in stone..
> >
> > Whoa, whoa, whoa! At what point did I say I think it's ok to put arbitrary
> > data into $_POST?
>
> when you suggested to OP to put the result of a query into $_POST.
Terminology confusion. To me, the "result of a query" is the data, not the
resource. Personally I think it was pretty clear that's what I meant based on
what the OP was planning to do, but I can see how that might not have been
crystal clear.
> > As I said in a previous email, I was responding to the OP's question which
> > was essentially "is it possible to fake a form post" and the answer is yes
>
>
> the question was more like, how do i abstract the input for a template such
> that it can be supplied data via $_POST in one case and the result of a
> select in another.
That's not what he asked, but it is one possible answer to his question.
> > I have at no point advocated using $_POST for data that you simply want to
> > be globally available.
> you've recommended populating $_POST with data that has nothing to do with
> HTTP POST, it is by nature globally available.
I have suggested that there is nothing wrong with modifying data in the $_POST
global variable to essentially fake that it had come from a form post. I never
suggested that it should be used as a generic global store.
I think we've started going around in circles and this is no longer benefiting
anyone. I think we're essentially saying the same thing, but where you're
relying on rules around how $_POST should be used I'm advocating vigilant
defensive programming techniques, and it seems we're going to have to agree to
disagree.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vars
On Thu, Apr 14, 2011 at 2:53 AM, Stuart Dallas wrote:
> On Thursday, 14 April 2011 at 07:11, Nathan Nobbe wrote:
> On Wed, Apr 13, 2011 at 3:30 PM, Stuart Dallas wrote:
> > > On Wednesday, 13 April 2011 at 19:47, Nathan Nobbe wrote:
> > > I never make any assumptions about the source of any data when I'm
> developing software, whether in PHP or not. Returning to a previous point,
> usage of global variables as the source of data anywhere other than the
> initial script a request hits is tantamount to negligence. But that's just
> my opinion.
> > Who said you should make assumptions. One thing you know is that $_POST
> was populated by the contents of HTTP POST, or most of it anyways, lol.
>
> Again, I don't see how that "knowledge" is useful?
>
you know what doesn't belong there.
> > Here's an example, suppose you have an object, any object in php should
> let you dynamically create a public member variable on it on the fly unless
> there's an explicit override in __get().
> >
> > $oXml = new
> SimpleXmlElement('real-data');
> >
> > now someone decides to use it to store something clever, because they
> can, and it's so much easier than creating an appropriate location
> >
> > $oXml->myCleverValue = 'something unrelated';
> >
> > whoops the client web service stopped processing our request successfully
> because the clever new node inadvertently broke the validation against the
> xsd.
> >
> > or I'm running through some code and see it in a for loop
> >
> > foreach($oXml as $node => $value)
> >
> > but I don't see any clever value in the docs from the vendor..
> >
> > Separation of concerns for data. The same reason you have a typical
> directory structure on an operating system and the same reason you don't
> have 10 projects all in the same vcs repository. but nothing is written in
> stone..
>
> Whoa, whoa, whoa! At what point did I say I think it's ok to put arbitrary
> data into $_POST?
when you suggested to OP to put the result of a query into $_POST.
> As I said in a previous email, I was responding to the OP's question which
> was essentially "is it possible to fake a form post" and the answer is yes
the question was more like, how do i abstract the input for a template such
that it can be supplied data via $_POST in one case and the result of a
select in another.
> I have at no point advocated using $_POST for data that you simply want to
> be globally available.
>
you've recommended populating $_POST with data that has nothing to do with
HTTP POST, it is by nature globally available.
-nathan
Re: [PHP] $_POST vars
On Thursday, 14 April 2011 at 07:11, Nathan Nobbe wrote:
On Wed, Apr 13, 2011 at 3:30 PM, Stuart Dallas wrote:
> > On Wednesday, 13 April 2011 at 19:47, Nathan Nobbe wrote:
> > I never make any assumptions about the source of any data when I'm
> > developing software, whether in PHP or not. Returning to a previous point,
> > usage of global variables as the source of data anywhere other than the
> > initial script a request hits is tantamount to negligence. But that's just
> > my opinion.
> Who said you should make assumptions. One thing you know is that $_POST was
> populated by the contents of HTTP POST, or most of it anyways, lol.
Again, I don't see how that "knowledge" is useful?
> Here's an example, suppose you have an object, any object in php should let
> you dynamically create a public member variable on it on the fly unless
> there's an explicit override in __get().
>
> $oXml = new
> SimpleXmlElement('real-data');
>
> now someone decides to use it to store something clever, because they can,
> and it's so much easier than creating an appropriate location
>
> $oXml->myCleverValue = 'something unrelated';
>
> whoops the client web service stopped processing our request successfully
> because the clever new node inadvertently broke the validation against the
> xsd.
>
> or I'm running through some code and see it in a for loop
>
> foreach($oXml as $node => $value)
>
> but I don't see any clever value in the docs from the vendor..
>
> Separation of concerns for data. The same reason you have a typical directory
> structure on an operating system and the same reason you don't have 10
> projects all in the same vcs repository. but nothing is written in stone..
Whoa, whoa, whoa! At what point did I say I think it's ok to put arbitrary data
into $_POST? As I said in a previous email, I was responding to the OP's
question which was essentially "is it possible to fake a form post" and the
answer is yes. I have at no point advocated using $_POST for data that you
simply want to be globally available.
> > But here's a question that just occurred to me... what are you doing
> > differently based on the assumption that those arrays are populated by PHP?
>
> the first place you look for data in the $_POST array is the client layer. it
> doesn't matter if they were populated by php or apache, the important part is
> what the container is supposed to store, what it represents. A common issue
> that was recently brought up on the list is the typical abuse the $_SESSION
> array gets in PHP applications. $_POST is no different, though in my
> experience it's not abused as frequently, most people seem to just get it,
> but then, nothing's written in stone.
>
> > Seems to me that data in those arrays should be treated more carefully than
> > any other data, so why you feel you need to know where they came from is
> > beyond me. Can you elaborate?
>
>
> It's not where the data came from, it's what the data represents. I worked on
> an application several years ago where values were gratuitously placed in all
> of the superglobal arrays. The application had some crude database layer that
> was stuffing the mysql_insert_id into $_POST. So you might see some code like
>
> // do some real work, and by the way insert a record into the db
>
> // then later on
> $ourNewWhateverID = $_POST['NEW_ID'];
>
> well the first assumption is that that value had to come from the browser
> (only client in this application) so you start looking through html forms and
> javascript code (running grep through the template directories etc)... maybe
> it's set dynamically by some javascript code and passed over in an ajax
> request... or it was passed along by the previous page.., or no, maybe
> someone who used to code here didn't realize they could put it in the
> $GLOBALS array where other programmers expect to find user space values ...
> or better yet, they might not use the global context for this sort of thing
> at all... but no, you had to go ahead and
>
> $_POST['NEW_ID'] = mysql_insert_id();
>
> I'm not sure where your meter on best practices falls, but in my book even if
> the key was 'LAST_INSERT_ID' i'd chalk it up to brain dead. Let's take a
> dynamically generated value from the database and put it in a structure
> understood to be populated by data from the request; brilliant!
My point is and has always been that there is nothing inherently wrong with
setting or modifying values in $_POST. I agree that it is bad practice to use
$_POST for arbitrary stuff, but I see nothing wrong in setting or modifying
values to enable another part of your code to process that data as if it had
been POSTed, which is what the OP was wanting to do.
> The only real value I see to setting values in the $_REQUEST et al arrays is
> unit testing.
IOW, faking a request which, again, was what the OP wanted to do!
A couple of final points of personal opinion...
* Any code that
Re: [PHP] $_POST vars
On Wed, Apr 13, 2011 at 3:30 PM, Stuart Dallas wrote: > On Wednesday, 13 April 2011 at 19:47, Nathan Nobbe wrote: > > On Wed, Apr 13, 2011 at 12:34 PM, Stuart Dallas wrote: > > > On Wednesday, 13 April 2011 at 19:15, Nathan Nobbe wrote: > > > On Wed, Apr 13, 2011 at 12:04 PM, Stuart Dallas > wrote: > > > > > On Wednesday, 13 April 2011 at 18:55, Nathan Nobbe wrote: > > > > > On Wed, Apr 13, 2011 at 11:49 AM, Jim Giner < > jim.gi...@albanyhandball.com>wrote: > > > > > > > > > > > > > Can one create a set of $_POST vars within a script or is that > not do-able? > > > > > > > My display portion of my script utilizes the POST array to > supply values to > > > > > > > my input screen - this works well for the first display of an > empty screen, > > > > > > > and any following re-displays if there's an error in the user's > input. But > > > > > > > I want to use this same script/screen to display the results of > a query > > > > > > > when > > > > > > > the user wants to update an existing record. > > > > > > > > > > > > > > > > > > While a user script can populate $_POST this is generally > prohibited as it's > > > > > > typically populated by the environment. > > > > > > > > > > > > It would probly be cleaner to have the display portion of your > script read > > > > > > from an arbitrary array. > > > > > > > > > > > > Said arbitrary array could be populated by $_POST in one case and > the > > > > > > results of a query in another case. > > > > > > > > > > While I don't necessarily disagree with you as far as abstracting > the source of data goes, but it's never "prohibited", it just considered bad > practice. > > > > > > > > considered a bad practice means prohibited for most groups ive worked > with. > > > > > > This isn't any of the groups you've worked with, this is the wide world > and it's full of possibilities. > > > > lol youre right, and none of the groups ive worked with have been part of > this global community, so these must be strictly new possibilities we're > discussing on this thread... > > I clearly didn't put my point across well enough, which was that what is > and what isn't best practice is not set in stone. Best practices vary from > group to group and from project to project, and that's the way it should be. > However, just because you've mostly worked in groups where this is bad > practice does not make it bad practice. > The irony here is I've developed this rule of thumb by working with groups that don't consider it a bad practice but should have. > > > > Personally I've never understood this "thou shalt protect the > superglobals" attitude. They're arrays, nothing more, use them in whatever > way you want to. They're not sacred, endangered or likely to be overcome > with the urge to kill you if you modify them. If your code changes its > behaviour depending upon whether the data you're dealing with has come from > within or without your code I think you have bigger style issues to address. > > > the reason it's a bad practice is it undermines an assumption that > $_POST is only being populated by the environment, which in the case of > $_POST is coming from a form field, ajax / curl request etc. as soon as that > assumption is thrown out the window debugging becomes more involved trying > to track down the mysterious appearance of a $_POST var. if you really need > to store arbitrary data in a supergloabal $GLOABALS is there for that; def > don't stuff these into $_POST :) > > > > > > My idea of "best practice" says that data coming in from outside your > code should only ever be dealt with in the first script the request hits, so > you should never be hunting for where an errant value in $_POST came from. > Given this (and noting the fact that this was your suggestion to the OP) > you're creating the problem you're trying to avoid by using an "arbitrary > array" in the place of $_POST. > > well when you build programs that are more than one script in length > you'll find that data submitted by the user is often referenced further in > the flow than the entry script.. read: front controller. and im not creating > a problem, im avoiding a problem by not overloading the intended use of the > $_POST array. > > Good at making assumptions, aren't you?! > lol, i figured id give it a shot. Anyway, again, you seem to have missed my point. In a front controller > architecture, in my opinion, no code beyond that front controller should > ever be referencing the get, post or cookie superglobals, and ideally not > the server superglobal either. I see what you're saying, but then you're implying that it's ideal to copy the values into secondary data structure(s), perhaps modifying the values along the way or at least have them accessed indirectly after the initial processing. > This, to me, is the equivalent of having all variables a system uses as > globals which, I hope you'll agree, is something everyone agrees to be bad > practice. > is that written in stone? The arbitrary arr
Re: [PHP] $_POST vars
On Wednesday, 13 April 2011 at 19:47, Nathan Nobbe wrote: > On Wed, Apr 13, 2011 at 12:34 PM, Stuart Dallas wrote: > > On Wednesday, 13 April 2011 at 19:15, Nathan Nobbe wrote: > > On Wed, Apr 13, 2011 at 12:04 PM, Stuart Dallas wrote: > > > > On Wednesday, 13 April 2011 at 18:55, Nathan Nobbe wrote: > > > > On Wed, Apr 13, 2011 at 11:49 AM, Jim Giner > > > > wrote: > > > > > > > > > > > Can one create a set of $_POST vars within a script or is that not > > > > > > do-able? > > > > > > My display portion of my script utilizes the POST array to supply > > > > > > values to > > > > > > my input screen - this works well for the first display of an empty > > > > > > screen, > > > > > > and any following re-displays if there's an error in the user's > > > > > > input. But > > > > > > I want to use this same script/screen to display the results of a > > > > > > query > > > > > > when > > > > > > the user wants to update an existing record. > > > > > > > > > > > > > > > While a user script can populate $_POST this is generally prohibited > > > > > as it's > > > > > typically populated by the environment. > > > > > > > > > > It would probly be cleaner to have the display portion of your script > > > > > read > > > > > from an arbitrary array. > > > > > > > > > > Said arbitrary array could be populated by $_POST in one case and the > > > > > results of a query in another case. > > > > > > > > While I don't necessarily disagree with you as far as abstracting the > > > > source of data goes, but it's never "prohibited", it just considered > > > > bad practice. > > > > > > considered a bad practice means prohibited for most groups ive worked > > > with. > > > > This isn't any of the groups you've worked with, this is the wide world and > > it's full of possibilities. > > lol youre right, and none of the groups ive worked with have been part of > this global community, so these must be strictly new possibilities we're > discussing on this thread... I clearly didn't put my point across well enough, which was that what is and what isn't best practice is not set in stone. Best practices vary from group to group and from project to project, and that's the way it should be. However, just because you've mostly worked in groups where this is bad practice does not make it bad practice. > > > Personally I've never understood this "thou shalt protect the > > > superglobals" attitude. They're arrays, nothing more, use them in > > > whatever way you want to. They're not sacred, endangered or likely to be > > > overcome with the urge to kill you if you modify them. If your code > > > changes its behaviour depending upon whether the data you're dealing with > > > has come from within or without your code I think you have bigger style > > > issues to address. > > the reason it's a bad practice is it undermines an assumption that $_POST > > is only being populated by the environment, which in the case of $_POST is > > coming from a form field, ajax / curl request etc. as soon as that > > assumption is thrown out the window debugging becomes more involved trying > > to track down the mysterious appearance of a $_POST var. if you really need > > to store arbitrary data in a supergloabal $GLOABALS is there for that; def > > don't stuff these into $_POST :) > > > > My idea of "best practice" says that data coming in from outside your code > > should only ever be dealt with in the first script the request hits, so you > > should never be hunting for where an errant value in $_POST came from. > > Given this (and noting the fact that this was your suggestion to the OP) > > you're creating the problem you're trying to avoid by using an "arbitrary > > array" in the place of $_POST. > well when you build programs that are more than one script in length you'll > find that data submitted by the user is often referenced further in the flow > than the entry script.. read: front controller. and im not creating a > problem, im avoiding a problem by not overloading the intended use of the > $_POST array. Good at making assumptions, aren't you?! Anyway, again, you seem to have missed my point. In a front controller architecture, in my opinion, no code beyond that front controller should ever be referencing the get, post or cookie superglobals, and ideally not the server superglobal either. This, to me, is the equivalent of having all variables a system uses as globals which, I hope you'll agree, is something everyone agrees to be bad practice. > > My response to the OP was simply answering the question. > > > right, don't bother to offer any insight to a beginner, undermining the > benefit of a list like php-general. Again, your insight is from your perspective. It's an opinion, and one I don't share, hence why I didn't mention it. > > He has a section of code that uses $_POST and he wants to know if he can > > populate that within his code rather than needing it to come from a >
Re: [PHP] $_POST vars
Nathan Nobbe wrote on 04/13/2011 12:47:11 PM: [much snippage] > no, it's actually a better practice. users are expected to populate arrays > they create. the $GLOBALS array is expected to be populated by user > scripts. The $_POST array is expected to be populated by PHP. by the time > you've decided to stuff variables into $_GET or $_POST yourself you've > decided to start mixing variables from your code with variables from the > client. simply put these arrays are not intended to be populated by user > scripts. I like Chris Shiflett's approach, which emphasizes security. Step 1 with posted (tainted) data is to sanitize it. "Clean" values are then moved from $_GET/$_POST into a new array, e.g., $CLEAN, so that it is immediately clear to code reviewers, future support programmers, etc., that the data is now clean and safe to use. With this approach, $_POST is only used at Step 1 and then disappears from the remaining code; $CLEAN is used in subsequent steps. Using $_POST out in the middle of nowhere *looks* like it could be a security flaw, whether it actually is or isn't. And you know how Joel Spolsky feels about code that *looks* like it could be an error ;) But, yes, you can use $_POST just like any other array. Not a practice I prefer, but YMMV. Kirk
Re: [PHP] $_POST vars
PHP then is Truly an amazing and powerful language. I can expand the contents of the array $_POST by simply assigning a separate arry to it. Obviously if I have a duplicate element-name in my array it will override the $_POST element but that's my problem. "Stuart Dallas" wrote in message news:4962044e8a244fc28719d97746759...@3ft9.com... > On Wednesday, 13 April 2011 at 19:12, Jim Giner wrote: > When you say "assign that array to $_POST" do you mean >> >> $_POST = $qrslt; >> >> Not sure about this "assigning an array" thing. > Yup, nothing more complicated than that. -Stuart (remainder deleted for everyone's sake :) ) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vars
On Wed, Apr 13, 2011 at 12:34 PM, Stuart Dallas wrote: > On Wednesday, 13 April 2011 at 19:15, Nathan Nobbe wrote: > On Wed, Apr 13, 2011 at 12:04 PM, Stuart Dallas wrote: > > > On Wednesday, 13 April 2011 at 18:55, Nathan Nobbe wrote: > > > On Wed, Apr 13, 2011 at 11:49 AM, Jim Giner < > jim.gi...@albanyhandball.com>wrote: > > > > > > > > > Can one create a set of $_POST vars within a script or is that not > do-able? > > > > > My display portion of my script utilizes the POST array to supply > values to > > > > > my input screen - this works well for the first display of an empty > screen, > > > > > and any following re-displays if there's an error in the user's > input. But > > > > > I want to use this same script/screen to display the results of a > query > > > > > when > > > > > the user wants to update an existing record. > > > > > > > > > > > > While a user script can populate $_POST this is generally prohibited > as it's > > > > typically populated by the environment. > > > > > > > > It would probly be cleaner to have the display portion of your script > read > > > > from an arbitrary array. > > > > > > > > Said arbitrary array could be populated by $_POST in one case and the > > > > results of a query in another case. > > > > > > While I don't necessarily disagree with you as far as abstracting the > source of data goes, but it's never "prohibited", it just considered bad > practice. > > > > considered a bad practice means prohibited for most groups ive worked > with. > > This isn't any of the groups you've worked with, this is the wide world and > it's full of possibilities. > lol youre right, and none of the groups ive worked with have been part of this global community, so these must be strictly new possibilities we're discussing on this thread... > > Personally I've never understood this "thou shalt protect the > superglobals" attitude. They're arrays, nothing more, use them in whatever > way you want to. They're not sacred, endangered or likely to be overcome > with the urge to kill you if you modify them. If your code changes its > behaviour depending upon whether the data you're dealing with has come from > within or without your code I think you have bigger style issues to address. > the reason it's a bad practice is it undermines an assumption that $_POST > is only being populated by the environment, which in the case of $_POST is > coming from a form field, ajax / curl request etc. as soon as that > assumption is thrown out the window debugging becomes more involved trying > to track down the mysterious appearance of a $_POST var. if you really need > to store arbitrary data in a supergloabal $GLOABALS is there for that; def > don't stuff these into $_POST :) > > My idea of "best practice" says that data coming in from outside your code > should only ever be dealt with in the first script the request hits, so you > should never be hunting for where an errant value in $_POST came from. Given > this (and noting the fact that this was your suggestion to the OP) you're > creating the problem you're trying to avoid by using an "arbitrary array" in > the place of $_POST. > well when you build programs that are more than one script in length you'll find that data submitted by the user is often referenced further in the flow than the entry script.. read: front controller. and im not creating a problem, im avoiding a problem by not overloading the intended use of the $_POST array. > My response to the OP was simply answering the question. right, don't bother to offer any insight to a beginner, undermining the benefit of a list like php-general. > He has a section of code that uses $_POST and he wants to know if he can > populate that within his code rather than needing it to come from a request. > Why he didn't just try it is beyond me, but all this talk of best and bad > practice is all beside the point. > no, it's the entire point. if you ask a question on this list you should expect to get more than a black and white answer. that's how people get better quicker and that's the point of interacting with humans on the other end of the wire. > > keep things cleanly separated and you'll thank yourself later imo. also > when someone is asking a question of this nature, obviously this is the most > critical time to tell them about bad practices rather than just the obvious, > "yes, of course you can do that...". otherwise people asking questions won't > get much more mileage from this list than a google search. > > It's bad practice for reasons that arise equally well from abstracting the > source of data, as you suggested. Why, then, is it bad practice? no, it's actually a better practice. users are expected to populate arrays they create. the $GLOBALS array is expected to be populated by user scripts. The $_POST array is expected to be populated by PHP. by the time you've decided to stuff variables into $_GET or $_POST yourself you've decided to start mixing variables from
Re: [PHP] $_POST vars
On Wednesday, 13 April 2011 at 19:15, Nathan Nobbe wrote: On Wed, Apr 13, 2011 at 12:04 PM, Stuart Dallas wrote: > > On Wednesday, 13 April 2011 at 18:55, Nathan Nobbe wrote: > > On Wed, Apr 13, 2011 at 11:49 AM, Jim Giner > > wrote: > > > > > > > Can one create a set of $_POST vars within a script or is that not > > > > do-able? > > > > My display portion of my script utilizes the POST array to supply > > > > values to > > > > my input screen - this works well for the first display of an empty > > > > screen, > > > > and any following re-displays if there's an error in the user's input. > > > > But > > > > I want to use this same script/screen to display the results of a query > > > > when > > > > the user wants to update an existing record. > > > > > > > > > While a user script can populate $_POST this is generally prohibited as > > > it's > > > typically populated by the environment. > > > > > > It would probly be cleaner to have the display portion of your script read > > > from an arbitrary array. > > > > > > Said arbitrary array could be populated by $_POST in one case and the > > > results of a query in another case. > > > > While I don't necessarily disagree with you as far as abstracting the > > source of data goes, but it's never "prohibited", it just considered bad > > practice. > > considered a bad practice means prohibited for most groups ive worked with. This isn't any of the groups you've worked with, this is the wide world and it's full of possibilities. > Personally I've never understood this "thou shalt protect the superglobals" > attitude. They're arrays, nothing more, use them in whatever way you want to. > They're not sacred, endangered or likely to be overcome with the urge to kill > you if you modify them. If your code changes its behaviour depending upon > whether the data you're dealing with has come from within or without your > code I think you have bigger style issues to address. the reason it's a bad practice is it undermines an assumption that $_POST is only being populated by the environment, which in the case of $_POST is coming from a form field, ajax / curl request etc. as soon as that assumption is thrown out the window debugging becomes more involved trying to track down the mysterious appearance of a $_POST var. if you really need to store arbitrary data in a supergloabal $GLOABALS is there for that; def don't stuff these into $_POST :) My idea of "best practice" says that data coming in from outside your code should only ever be dealt with in the first script the request hits, so you should never be hunting for where an errant value in $_POST came from. Given this (and noting the fact that this was your suggestion to the OP) you're creating the problem you're trying to avoid by using an "arbitrary array" in the place of $_POST. My response to the OP was simply answering the question. He has a section of code that uses $_POST and he wants to know if he can populate that within his code rather than needing it to come from a request. Why he didn't just try it is beyond me, but all this talk of best and bad practice is all beside the point. > keep things cleanly separated and you'll thank yourself later imo. also when > someone is asking a question of this nature, obviously this is the most > critical time to tell them about bad practices rather than just the obvious, > "yes, of course you can do that...". otherwise people asking questions won't > get much more mileage from this list than a google search. It's bad practice for reasons that arise equally well from abstracting the source of data, as you suggested. Why, then, is it bad practice? -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vars
On Wednesday, 13 April 2011 at 19:12, Jim Giner wrote: When you say "assign that array to $_POST" do you mean > > $_POST = $qrslt; > > Not sure about this "assigning an array" thing. Yup, nothing more complicated than that. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ > - Original Message - > From: "Stuart Dallas" > Newsgroups: php.general > To: "Jim Giner" > Cc: "PHP General" > Sent: Wednesday, April 13, 2011 1:59 PM > Subject: Re: [PHP] $_POST vars > > > > > > Not sure what you mean by "the results of a query". If you mean an array > > that you got from a MySQL query (my best guess), then simply assign that > > array to $_POST ... > > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vars
Shrug, it's called reply-all and it's been brought up here before :) -nathan On Wed, Apr 13, 2011 at 12:25 PM, Jim Giner wrote: > No need to email me AND send to the list. Is that the standard practice on > this forum? Not encountered it before. > >
Re: [PHP] $_POST vars
No need to email me AND send to the list. Is that the standard practice on this forum? Not encountered it before. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vars
On Wed, Apr 13, 2011 at 12:04 PM, Stuart Dallas wrote: > On Wednesday, 13 April 2011 at 18:55, Nathan Nobbe wrote: > On Wed, Apr 13, 2011 at 11:49 AM, Jim Giner >wrote: > > > > > Can one create a set of $_POST vars within a script or is that not > do-able? > > > My display portion of my script utilizes the POST array to supply > values to > > > my input screen - this works well for the first display of an empty > screen, > > > and any following re-displays if there's an error in the user's input. > But > > > I want to use this same script/screen to display the results of a query > > > when > > > the user wants to update an existing record. > > > > > > While a user script can populate $_POST this is generally prohibited as > it's > > typically populated by the environment. > > > > It would probly be cleaner to have the display portion of your script > read > > from an arbitrary array. > > > > Said arbitrary array could be populated by $_POST in one case and the > > results of a query in another case. > > While I don't necessarily disagree with you as far as abstracting the > source of data goes, but it's never "prohibited", it just considered bad > practice. > considered a bad practice means prohibited for most groups ive worked with. Personally I've never understood this "thou shalt protect the superglobals" > attitude. They're arrays, nothing more, use them in whatever way you want > to. They're not sacred, endangered or likely to be overcome with the urge to > kill you if you modify them. If your code changes its behaviour depending > upon whether the data you're dealing with has come from within or without > your code I think you have bigger style issues to address. > the reason it's a bad practice is it undermines an assumption that $_POST is only being populated by the environment, which in the case of $_POST is coming from a form field, ajax / curl request etc. as soon as that assumption is thrown out the window debugging becomes more involved trying to track down the mysterious appearance of a $_POST var. if you really need to store arbitrary data in a supergloabal $GLOABALS is there for that; def don't stuff these into $_POST :) keep things cleanly separated and you'll thank yourself later imo. also when someone is asking a question of this nature, obviously this is the most critical time to tell them about bad practices rather than just the obvious, "yes, of course you can do that...". otherwise people asking questions won't get much more mileage from this list than a google search. -nathan
Re: [PHP] $_POST vars
When you say "assign that array to $_POST" do you mean $_POST = $qrslt; Not sure about this "assigning an array" thing. - Original Message - From: "Stuart Dallas" Newsgroups: php.general To: "Jim Giner" Cc: "PHP General" Sent: Wednesday, April 13, 2011 1:59 PM Subject: Re: [PHP] $_POST vars > > Not sure what you mean by "the results of a query". If you mean an array > that you got from a MySQL query (my best guess), then simply assign that > array to $_POST ... > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vars
On Wednesday, 13 April 2011 at 18:55, Nathan Nobbe wrote: On Wed, Apr 13, 2011 at 11:49 AM, Jim Giner wrote: > > > Can one create a set of $_POST vars within a script or is that not do-able? > > My display portion of my script utilizes the POST array to supply values to > > my input screen - this works well for the first display of an empty screen, > > and any following re-displays if there's an error in the user's input. But > > I want to use this same script/screen to display the results of a query > > when > > the user wants to update an existing record. > > > While a user script can populate $_POST this is generally prohibited as it's > typically populated by the environment. > > It would probly be cleaner to have the display portion of your script read > from an arbitrary array. > > Said arbitrary array could be populated by $_POST in one case and the > results of a query in another case. While I don't necessarily disagree with you as far as abstracting the source of data goes, but it's never "prohibited", it just considered bad practice. Personally I've never understood this "thou shalt protect the superglobals" attitude. They're arrays, nothing more, use them in whatever way you want to. They're not sacred, endangered or likely to be overcome with the urge to kill you if you modify them. If your code changes its behaviour depending upon whether the data you're dealing with has come from within or without your code I think you have bigger style issues to address. All hail the superglobals! (sarcasm for those not familiar) -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] $_POST vars
Hi Jim, Sure you can create set of et of $_POST vars : e.g. So that admin_code var is passed to myphpaction.php as post and shall be access there via $_POST["admin_code "]; However, note that in PHP all the output buffer is flushed actually, ONLY after the script execution is terminated. Skype: eliorr.com -Original Message- From: Jim Giner [mailto:jim.gi...@albanyhandball.com] Sent: Wednesday, April 13, 2011 8:50 PM To: php-general@lists.php.net Subject: [PHP] $_POST vars Can one create a set of $_POST vars within a script or is that not do-able? My display portion of my script utilizes the POST array to supply values to my input screen - this works well for the first display of an empty screen, and any following re-displays if there's an error in the user's input. But I want to use this same script/screen to display the results of a query when the user wants to update an existing record. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vars
On Wednesday, 13 April 2011 at 18:56, Jim Giner wrote: And that includes adding entirely new elements in that array? Yes, it's a standard array. It's not special other than being a superglobal. > Do you have any suggestion on how to get the results of a query into POST > easily or is it simply a for loop? Not sure what you mean by "the results of a query". If you mean an array that you got from a MySQL query (my best guess), then simply assign that array to $_POST and Bob's your slightly perverted uncle! And please include the list when replying so everyone can benefit from the discussion. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vars
On Wed, Apr 13, 2011 at 11:49 AM, Jim Giner wrote: > Can one create a set of $_POST vars within a script or is that not do-able? > My display portion of my script utilizes the POST array to supply values to > my input screen - this works well for the first display of an empty screen, > and any following re-displays if there's an error in the user's input. But > I want to use this same script/screen to display the results of a query > when > the user wants to update an existing record. While a user script can populate $_POST this is generally prohibited as it's typically populated by the environment. It would probly be cleaner to have the display portion of your script read from an arbitrary array. Said arbitrary array could be populated by $_POST in one case and the results of a query in another case. -nathan
Re: [PHP] $_POST vars
On Wed, Apr 13, 2011 at 1:49 PM, Jim Giner wrote: > Can one create a set of $_POST vars within a script or is that not do-able? > My display portion of my script utilizes the POST array to supply values to > my input screen - this works well for the first display of an empty screen, > and any following re-displays if there's an error in the user's input. But > I want to use this same script/screen to display the results of a query > when > the user wants to update an existing record. > > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > I'm not sure what you're asking, but you can set the values of the POST array directly within a script, for instance: $_POST['new_key'] = 'new_value'; Adam -- Nephtali: A simple, flexible, fast, and security-focused PHP framework http://nephtaliproject.com
Re: [PHP] $_POST vars
On Wednesday, 13 April 2011 at 18:49, Jim Giner wrote: Can one create a set of $_POST vars within a script or is that not do-able? > My display portion of my script utilizes the POST array to supply values to > my input screen - this works well for the first display of an empty screen, > and any following re-displays if there's an error in the user's input. But > I want to use this same script/screen to display the results of a query when > the user wants to update an existing record. $_POST is a standard PHP array, with the only added feature being that it's available everywhere (i.e. it's a superglobal). There is nothing stopping you modifying that array from anywhere within your code. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST variable
At 6:07 PM -0600 3/12/11, Shawn McKenzie wrote: On 03/12/2011 10:37 AM, tedd wrote: > Here's a demo: > http://php1.net/b/form-radio1/ > Don't make it more complicated than it needs be. My point exactly! So long as the name of the name[] part is the same they will be treated as the same "group" of radio buttons. So here is the long and short; if the name is the same and you specify an index then names with the same index will be grouped together: name[1] and name[1] are the same but different group from name[2]. If you don't specify an index, but the name is the same, then they are grouped together: name[], name[]. By grouped together I mean that only one of the group can be selected and therefore successful on submit. -- Thanks! -Shawn Yeah, that's clear as mud -- I know how to do it and that confused me. :-\ Here's a much simpler example than my previous one: http://rebel.lcc.edu/sperlt/citw229/sticky-radio.php You don't even need an array. Just check the "choice" variable. Cheers, tedd -- --- http://sperling.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST variable
On 03/12/2011 10:37 AM, tedd wrote: > At 9:28 PM +0200 3/11/11, Danny wrote: >> Hi guys, >> >> I have a form that has a long list of radio-bottons inside of it. The >> radio-buttons are dynamically created via php and MySQL. >> >> Here is an example of one of the radio buttons: >> >> > ?>" value="0"> >> > ?>" value="1"> >> >> Now, when I submit this form to another page for processing, how would >> I "catch" >> the above radio-button's $_POST name since I do not know the name, >> only that it >> starts with "radio_" ? >> >> Thank You >> >> Danny > > > Danny: > > Replace with an option[] > array. > > Realize that the name of the radio input stays the same -- it is the > value that changes. > > Here's a demo: > > http://php1.net/b/form-radio1/ > > Don't make it more complicated than it needs be. > > Cheers, > > tedd > My point exactly! So long as the name of the name[] part is the same they will be treated as the same "group" of radio buttons. So here is the long and short; if the name is the same and you specify an index then names with the same index will be grouped together: name[1] and name[1] are the same but different group from name[2]. If you don't specify an index, but the name is the same, then they are grouped together: name[], name[]. By grouped together I mean that only one of the group can be selected and therefore successful on submit. -- Thanks! -Shawn http://www.spidean.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST variable
At 9:28 PM +0200 3/11/11, Danny wrote: Hi guys, I have a form that has a long list of radio-bottons inside of it. The radio-buttons are dynamically created via php and MySQL. Here is an example of one of the radio buttons: ; ?>" value="0"> ; ?>" value="1"> Now, when I submit this form to another page for processing, how would I "catch" the above radio-button's $_POST name since I do not know the name, only that it starts with "radio_" ? Thank You Danny Danny: Replace with an option[] array. Realize that the name of the radio input stays the same -- it is the value that changes. Here's a demo: http://php1.net/b/form-radio1/ Don't make it more complicated than it needs be. Cheers, tedd -- --- http://sperling.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST variable
On 11/03/2011 20:28, Danny wrote:
Hi guys,
I have a form that has a long list of radio-bottons inside of it. The
radio-buttons are dynamically created via php and MySQL.
Here is an example of one of the radio buttons:
"
value="0">
"
value="1">
Now, when I submit this form to another page for processing, how would I "catch"
the above radio-button's $_POST name since I do not know the name, only that it
starts with "radio_" ?
foreach ($_POST as $k => $v) {
if (substr($k,0,6) == 'radio_') {
echo 'Name is -> ',$k,'';
// Do stuff...
}
}
HTH
Rich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST variable
On Fri, 2011-03-11 at 21:28 +0200, Danny wrote:
> Hi guys,
>
> I have a form that has a long list of radio-bottons inside of it. The
> radio-buttons are dynamically created via php and MySQL.
>
> Here is an example of one of the radio buttons:
>
> "
> value="0">
> "
> value="1">
>
> Now, when I submit this form to another page for processing, how would I
> "catch"
> the above radio-button's $_POST name since I do not know the name, only that
> it
> starts with "radio_" ?
>
> Thank You
>
> Danny
>
loop thought all the $_POST variables...
foreach($_POST as $key => $val)
{
if(susbtr($key, 0, 7) === "radio_")
{
# this is what we're looking for
}
}
crude, but works... I am sure there are many ways to look for it.
Steve
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST variable
On Fri, Mar 11, 2011 at 14:28, Danny wrote:
[snip!]
>
> Now, when I submit this form to another page for processing, how would I
> "catch"
> the above radio-button's $_POST name since I do not know the name, only that
> it
> starts with "radio_" ?
One method is a foreach() loop.
$v) {
if (preg_match('/^radio_/Ui',trim($k))) {
echo $k.' is a match, and it\'s value is '.$v.'.'.PHP_EOL;
}
}
?>
--
Network Infrastructure Manager
http://www.php.net/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST issues
On Wed, 2010-12-01 at 20:18 +0400, Nadim Attari wrote: > On 12/01/2010 07:18 PM, Jay Blanchard wrote: > > [snip] > >>> If I just put only this piece of code: > >>> > >>> >>> var_dump($_POST); > >>> ?> > >>> > >>> i get nothing. > > [/snip] > > > > Where are you putting this var_dump? > > > > > > That's the only code on the page. Otherwise, the other codes - header(), > print, etc. are on the page. > > nadim > if i follow correctly, your form submits via: then you redirect to the page.php, and it puts the $_POST variables into the url string... and that works fine. and now, you're trying to get the variables from the page.php, using the $_POST method? wouldn't you want to be checking the $_GET on this page, as they would be coming in from the url string? Steve -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST issues
This thread is a really good example of how difficult it can be to both explain and understand a problem. The original poster might want to restate the question from scratch with a more explicit and complete example. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] $_POST issues
[snip] > Where are you putting this var_dump? > > That's the only code on the page. Otherwise, the other codes - header(), print, etc. are on the page. [/snip] var_dumping the POST on the same page from which the data originates will not yield anything. Page A - contains data to be posted. Page B - receives posted data (do var_dump here) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST issues
On 1 December 2010 14:50, Bundhoo M Nadim wrote:
> Hello,
>
> Can someone explain me what this piece of code basically does ?
>
> header("Expires: " . gmdate("D, d M Y H:i:s", time() + (0*60)) . "GMT");
> header("Pragma: no-cache");
> print "REDIRECT=http://www.domaine.com/page.php?";;
> $param = http_build_query($_POST);
> print $param;
> exit(0);
> ?>
>
> Well, the code is redirecting to some page with query string constructed
> using the $_POST data.
>
> My problem is not the redirection; but all I want is to get the data in
> $_POST
>
> If I just put only this piece of code:
>
> var_dump($_POST);
> ?>
>
> i get nothing. But the above codes is successfully redirecting me to
> page.php with a properly constructed query string -> which means that $_POST
> was never empty. So why var_dump($_POST) is returning just array(0) { } ???
>
> nadim attari
> alienworkers.com
>
I'd start reading http://docs.php.net/manual/en/reserved.variables.php
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST issues
The function http_build_query() is turning your $_POST array into a query string ($_GET), so the answer to this really depends where you're trying to dump the array. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST issues
On 12/01/2010 07:18 PM, Jay Blanchard wrote: [snip] If I just put only this piece of code: i get nothing. [/snip] Where are you putting this var_dump? That's the only code on the page. Otherwise, the other codes - header(), print, etc. are on the page. nadim -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST issues
On 1 December 2010 15:18, Marc Guay wrote: >>> var_dump($_POST); ?> > > Where exactly are you putting this line? > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > If a script is ran via a url like ... http://www.site.com/script.php?var1=val1&var2=val2 then $_GET will contain the result. The same $_GET would hold the values from a $_POST is for POST-d data (either via or cURL/Streams). -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] $_POST issues
[snip] >> If I just put only this piece of code: >> >> > var_dump($_POST); >> ?> >> >> i get nothing. [/snip] Where are you putting this var_dump? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST issues
>>> >> var_dump($_POST); >>> ?> Where exactly are you putting this line? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST issues
On 01/12/2010 19:01, Daniel P. Brown wrote:
On Wed, Dec 1, 2010 at 09:50, Bundhoo M Nadim wrote:
If I just put only this piece of code:
i get nothing. But the above codes is successfully redirecting me to
page.php with a properly constructed query string -> which means that $_POST
was never empty. So why var_dump($_POST) is returning just array(0) { } ???
Are you actually posting data to it?
Actually this is the response page, i.e. a payment gateway is sending
the result of a transaction to this page. Normally I expect to catch the
data sent by the payment gateway using the $_POST array, i.e. $result =
$_POST['result'], etc.
So i wanted to check the data sent by the payment gateway using
var_dump($_POST); <--- this gives me array(0) { }
But if I put the other codes (lemme quote again here):
filename: response.php
header("Expires: " . gmdate("D, d M Y H:i:s", time() + (0*60)) . "GMT");
header("Pragma: no-cache");
print "REDIRECT=http://www.domaine.com/page.php?";;
$param = http_build_query($_POST);
print $param;
exit(0);
?>
It successfully redirects me to page.php + the properly constructed query string
e.g.: http://www.domain.com/page.php?var1=val1&var2=val2 ... etc
That's baffling me. Why can't I catch the $_POST data in this response.php but
I get them in page.php ??
Something weird.
nadim attari
alienworkers.com
Re: [PHP] $_POST issues
On Wed, Dec 1, 2010 at 09:50, Bundhoo M Nadim wrote:
>
> If I just put only this piece of code:
>
> var_dump($_POST);
> ?>
>
> i get nothing. But the above codes is successfully redirecting me to
> page.php with a properly constructed query string -> which means that $_POST
> was never empty. So why var_dump($_POST) is returning just array(0) { } ???
Are you actually posting data to it?
--
Dedicated Servers, Cloud and Cloud Hybrid Solutions, VPS, Hosting
(866-) 725-4321
http://www.parasane.net/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST issues
On 1 December 2010 14:50, Bundhoo M Nadim wrote:
> Hello,
>
> Can someone explain me what this piece of code basically does ?
>
> header("Expires: " . gmdate("D, d M Y H:i:s", time() + (0*60)) . "GMT");
> header("Pragma: no-cache");
> print "REDIRECT=http://www.domaine.com/page.php?";;
> $param = http_build_query($_POST);
> print $param;
> exit(0);
> ?>
>
> Well, the code is redirecting to some page with query string constructed
> using the $_POST data.
>
> My problem is not the redirection; but all I want is to get the data in
> $_POST
>
> If I just put only this piece of code:
>
> var_dump($_POST);
> ?>
>
> i get nothing. But the above codes is successfully redirecting me to
> page.php with a properly constructed query string -> which means that $_POST
> was never empty. So why var_dump($_POST) is returning just array(0) { } ???
>
> nadim attari
> alienworkers.com
>
Under normal circumstances, $_POST will only be populated from a
with a method="post".
So, loading a URL to a PHP script containing just the var_dump() will
never output anything for $_POST as the URL wasn't the result of a
POST'd form.
You can also use cURL or stream_contexts to construct the data for
POST-ing and your script would receive these correctly.
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
Op 2/24/10 11:18 AM, Ashley Sheridan schreef: > On Wed, 2010-02-24 at 07:55 +, Jochem Maas wrote: > >> Op 2/22/10 10:49 PM, John Black schreef: >>> On 02/22/2010 11:42 PM, Michael Shadle wrote: The difference here is you can at least have some control over the data and expect it in a certain fashion. Also the behavior of cookies vs. get vs. post are different (cookies have length and expiration limits, get has length limits, post has server confgured limits) >>> >>> The cookie and post/get part is all mixed up now :) >>> >>> I use $_COOKIE when I want cookie information but I know that the data >>> is not to be trusted and is easily fabricated. >>> >>> When reading get or post I just use $_REQUEST nowadays because I don't >>> have to care how the submitting form is written. This makes my form >>> handling data more portable. >> >> a. if your updating/inserting/storing data for the user you should require >> POST in order to mitigate CSRF et al - not to mention using a nonce in your >> forms. >> >> b. when you use $_REQUEST like you do you assume it's either GET or POST >> data, but >> it might be COOKIE data ... which will overwrite what is sent via GET or >> POST in the >> $_REQUEST array .. which creates a potential for a denial-of-service attack >> on the >> users of a site: >> >> imagine an 'id' parameter for displaying articles, then imagine a >> user was tricked into loading a cookie onto his machine for your domain with >> the >> name of 'id' and a value of 1 ... said user would only ever be able to see >> the >> article referred to be id=1 if you wrote code that took the 'id' parameter >> from the >> $_REQUEST var. >> >> ... I advocate not trusting any data *and* being explicit about the input >> vectors >> on which any particular piece of data is accepted in a given context. (GET, >> POST and COOKIE >> are 3 different vectors) >> >> >> > > > Which becomes a moot point if you use the request_order ini setting to > specify the ordering of the overriding of variables in $_REQUEST. which I think is another bit of magic I can do without. besides you don't always have control of the ini file (and you obviously can't change this value during the running of the script as $_REQUEST is already defined) > I do see what you're getting at, and yes there are concerns to be had > with one global array overriding another if you don't know to look out > for such a caveat. The thing is, there are many times where $_REQUEST is > just perfect. Imagine a stylesheet picker, that remembers the visitors > choice in a cookie. You can utilise $_REQUEST to handle the whole thing > very easily, and in a way that makes sense. which would require a request_order of CPG - the opposite of what it normally is, which is a complete WTF for any new developer of the code base, all so you can save a couple of lines of very simple code. I don't think it's worth it. BUT given that you do know what all the ramification are and can control the request_order in your environment then it's true to say that in your case there is no actual problem. > Thanks, > Ash > http://www.ashleysheridan.co.uk > > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
On Wed, 2010-02-24 at 12:34 +0100, Rene Veerman wrote: > sry i gotta disagree. > > a function that queries $_POST/$_GET first and then $_COOKIE seems > much wiser to me. > it consolidates all logic in the script, and making that logic obvious > by syntax, rather than relying on functionality being determined by > php.ini, which could well cause a new developer to lose heaps of time > if he/she has to work on it.. > > On Wed, Feb 24, 2010 at 11:18 AM, Ashley Sheridan > wrote: > > On Wed, 2010-02-24 at 07:55 +, Jochem Maas wrote: > > > >> Op 2/22/10 10:49 PM, John Black schreef: > >> > On 02/22/2010 11:42 PM, Michael Shadle wrote: > >> >> The difference here is you can at least have some control over the data > >> >> and expect it in a certain fashion. Also the behavior of cookies vs. get > >> >> vs. post are different (cookies have length and expiration limits, get > >> >> has length limits, post has server confgured limits) > >> > > >> > The cookie and post/get part is all mixed up now :) > >> > > >> > I use $_COOKIE when I want cookie information but I know that the data > >> > is not to be trusted and is easily fabricated. > >> > > >> > When reading get or post I just use $_REQUEST nowadays because I don't > >> > have to care how the submitting form is written. This makes my form > >> > handling data more portable. > >> > >> a. if your updating/inserting/storing data for the user you should require > >> POST in order to mitigate CSRF et al - not to mention using a nonce in > >> your forms. > >> > >> b. when you use $_REQUEST like you do you assume it's either GET or POST > >> data, but > >> it might be COOKIE data ... which will overwrite what is sent via GET or > >> POST in the > >> $_REQUEST array .. which creates a potential for a denial-of-service > >> attack on the > >> users of a site: > >> > >> imagine an 'id' parameter for displaying articles, then imagine a > >> user was tricked into loading a cookie onto his machine for your domain > >> with the > >> name of 'id' and a value of 1 ... said user would only ever be able to see > >> the > >> article referred to be id=1 if you wrote code that took the 'id' parameter > >> from the > >> $_REQUEST var. > >> > >> ... I advocate not trusting any data *and* being explicit about the input > >> vectors > >> on which any particular piece of data is accepted in a given context. > >> (GET, POST and COOKIE > >> are 3 different vectors) > >> > >> > >> > > > > > > Which becomes a moot point if you use the request_order ini setting to > > specify the ordering of the overriding of variables in $_REQUEST. > > > > I do see what you're getting at, and yes there are concerns to be had > > with one global array overriding another if you don't know to look out > > for such a caveat. The thing is, there are many times where $_REQUEST is > > just perfect. Imagine a stylesheet picker, that remembers the visitors > > choice in a cookie. You can utilise $_REQUEST to handle the whole thing > > very easily, and in a way that makes sense. > > > > Thanks, > > Ash > > http://www.ashleysheridan.co.uk > > > > > > > I don't think ini settings should be disregarded so easily though. There are plenty of other ini settings that affect global variables, and can all cause issues that can confuse the unwary developer! Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] $_POST vs $_REQUEST
sry i gotta disagree. a function that queries $_POST/$_GET first and then $_COOKIE seems much wiser to me. it consolidates all logic in the script, and making that logic obvious by syntax, rather than relying on functionality being determined by php.ini, which could well cause a new developer to lose heaps of time if he/she has to work on it.. On Wed, Feb 24, 2010 at 11:18 AM, Ashley Sheridan wrote: > On Wed, 2010-02-24 at 07:55 +, Jochem Maas wrote: > >> Op 2/22/10 10:49 PM, John Black schreef: >> > On 02/22/2010 11:42 PM, Michael Shadle wrote: >> >> The difference here is you can at least have some control over the data >> >> and expect it in a certain fashion. Also the behavior of cookies vs. get >> >> vs. post are different (cookies have length and expiration limits, get >> >> has length limits, post has server confgured limits) >> > >> > The cookie and post/get part is all mixed up now :) >> > >> > I use $_COOKIE when I want cookie information but I know that the data >> > is not to be trusted and is easily fabricated. >> > >> > When reading get or post I just use $_REQUEST nowadays because I don't >> > have to care how the submitting form is written. This makes my form >> > handling data more portable. >> >> a. if your updating/inserting/storing data for the user you should require >> POST in order to mitigate CSRF et al - not to mention using a nonce in your >> forms. >> >> b. when you use $_REQUEST like you do you assume it's either GET or POST >> data, but >> it might be COOKIE data ... which will overwrite what is sent via GET or >> POST in the >> $_REQUEST array .. which creates a potential for a denial-of-service attack >> on the >> users of a site: >> >> imagine an 'id' parameter for displaying articles, then imagine a >> user was tricked into loading a cookie onto his machine for your domain with >> the >> name of 'id' and a value of 1 ... said user would only ever be able to see >> the >> article referred to be id=1 if you wrote code that took the 'id' parameter >> from the >> $_REQUEST var. >> >> ... I advocate not trusting any data *and* being explicit about the input >> vectors >> on which any particular piece of data is accepted in a given context. (GET, >> POST and COOKIE >> are 3 different vectors) >> >> >> > > > Which becomes a moot point if you use the request_order ini setting to > specify the ordering of the overriding of variables in $_REQUEST. > > I do see what you're getting at, and yes there are concerns to be had > with one global array overriding another if you don't know to look out > for such a caveat. The thing is, there are many times where $_REQUEST is > just perfect. Imagine a stylesheet picker, that remembers the visitors > choice in a cookie. You can utilise $_REQUEST to handle the whole thing > very easily, and in a way that makes sense. > > Thanks, > Ash > http://www.ashleysheridan.co.uk > > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
On Wed, 2010-02-24 at 07:55 +, Jochem Maas wrote: > Op 2/22/10 10:49 PM, John Black schreef: > > On 02/22/2010 11:42 PM, Michael Shadle wrote: > >> The difference here is you can at least have some control over the data > >> and expect it in a certain fashion. Also the behavior of cookies vs. get > >> vs. post are different (cookies have length and expiration limits, get > >> has length limits, post has server confgured limits) > > > > The cookie and post/get part is all mixed up now :) > > > > I use $_COOKIE when I want cookie information but I know that the data > > is not to be trusted and is easily fabricated. > > > > When reading get or post I just use $_REQUEST nowadays because I don't > > have to care how the submitting form is written. This makes my form > > handling data more portable. > > a. if your updating/inserting/storing data for the user you should require > POST in order to mitigate CSRF et al - not to mention using a nonce in your > forms. > > b. when you use $_REQUEST like you do you assume it's either GET or POST > data, but > it might be COOKIE data ... which will overwrite what is sent via GET or POST > in the > $_REQUEST array .. which creates a potential for a denial-of-service attack > on the > users of a site: > > imagine an 'id' parameter for displaying articles, then imagine a > user was tricked into loading a cookie onto his machine for your domain with > the > name of 'id' and a value of 1 ... said user would only ever be able to see the > article referred to be id=1 if you wrote code that took the 'id' parameter > from the > $_REQUEST var. > > ... I advocate not trusting any data *and* being explicit about the input > vectors > on which any particular piece of data is accepted in a given context. (GET, > POST and COOKIE > are 3 different vectors) > > > Which becomes a moot point if you use the request_order ini setting to specify the ordering of the overriding of variables in $_REQUEST. I do see what you're getting at, and yes there are concerns to be had with one global array overriding another if you don't know to look out for such a caveat. The thing is, there are many times where $_REQUEST is just perfect. Imagine a stylesheet picker, that remembers the visitors choice in a cookie. You can utilise $_REQUEST to handle the whole thing very easily, and in a way that makes sense. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] $_POST vs $_REQUEST
Op 2/22/10 10:49 PM, John Black schreef: > On 02/22/2010 11:42 PM, Michael Shadle wrote: >> The difference here is you can at least have some control over the data >> and expect it in a certain fashion. Also the behavior of cookies vs. get >> vs. post are different (cookies have length and expiration limits, get >> has length limits, post has server confgured limits) > > The cookie and post/get part is all mixed up now :) > > I use $_COOKIE when I want cookie information but I know that the data > is not to be trusted and is easily fabricated. > > When reading get or post I just use $_REQUEST nowadays because I don't > have to care how the submitting form is written. This makes my form > handling data more portable. a. if your updating/inserting/storing data for the user you should require POST in order to mitigate CSRF et al - not to mention using a nonce in your forms. b. when you use $_REQUEST like you do you assume it's either GET or POST data, but it might be COOKIE data ... which will overwrite what is sent via GET or POST in the $_REQUEST array .. which creates a potential for a denial-of-service attack on the users of a site: imagine an 'id' parameter for displaying articles, then imagine a user was tricked into loading a cookie onto his machine for your domain with the name of 'id' and a value of 1 ... said user would only ever be able to see the article referred to be id=1 if you wrote code that took the 'id' parameter from the $_REQUEST var. ... I advocate not trusting any data *and* being explicit about the input vectors on which any particular piece of data is accepted in a given context. (GET, POST and COOKIE are 3 different vectors) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
Op 2/23/10 10:27 AM, Ashley Sheridan schreef: > On Tue, 2010-02-23 at 09:19 +, Richard wrote: > >> Hi, >> >> Well people better than me (how is that possible?!) have said that >> $_REQUEST has the potential to open your app up to security >> vulnerabilities, and that it should be avoided because of that. Here's >> a post from Stephan Esser about it on the PHP-Internals list: >> >> http://www.mail-archive.com/intern...@lists.php.net/msg32832.html >> >> Stephan heads up the Hardened-PHP project and when it comes to >> security, I don't know of anyone better. So, if he advises not to use >> _REQUEST, it's a good idea to follow that advice. >> >> -- >> Richard Heyes >> > > > Well, he's only saying there that it 'most probably vulnerable' and > mentions that cookies can overwrite post and get data. This isn't a > problem with $_REQUEST itself but rather an applications' use of it. So > what if someone crafts a cookie to send a bad value. If someone has the > gen to do that, then they are going to know how to send get and post > values as well. Only decent sanitisation will be able to protect against > this. > > If the order of override variables in $_REQUEST is such an issue too, > use the request_order ini setting to specify the order you'd prefer. > > I've never had any issues with using $_REQUEST, but found a lot of > advantages to using it, as I often use a mix of data sources in the same > app. and that is exactly Essers point. you use $_REQUEST and assume the data came from either GET or POST ... I'd hazard a guess your apps never expect such 'mixed' data to be coming via COOKIE ... so your app will work as 'advertised' but if some one happens to slip a cookie onto someone else machine whose name matches some rather important GET/POST input then it's that user who potentially has just suffered a denial of service - and you'll get the blame for the fact things don't work and you'll probably never be able to work out that it's a rogue cookie on the client putting a spanner in the works. (imagine you have an 'id' parameter and I managed to set a cookie on your users' machine called 'id' with a value of 1 ... have fun with that) you should be as strict with exceptable input vectors as you are with sanitisation of the actual input. use of $_REQUEST is rather lazy - if you want to except either POST or GET for a given input write a simple wrapper function for that specific requirement - this will also save you from unforeseen problems related to incorrect or changed values for the request_order ini setting. > > Thanks, > Ash > http://www.ashleysheridan.co.uk > > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
At 11:07 PM +0100 2/22/10, John Black wrote: On 02/22/2010 10:37 PM, Michael Shadle wrote: On Mon, Feb 22, 2010 at 1:30 PM, David Murphy wrote: Richard, The use of $_REQUEST it no more a security hole than $_GET or $_REQUEST, they should ALL be treats as bad data until normalized and sanitized. The claim that it opens a security hole is just false, that's like saying PHP is insecure, its not it just allows for lazy coding such as $_REQUEST. It represents a way for people to exploit coders who don't know any better. Expecting a cookie value to come through in $_REQUEST but you could override using a query string parameter makes for easy exploitation. And how is this more secure? I can create a cookie, send post or get on my client machine and send anything I want to the server. Just because you are getting a cookie does not mean that you created it :) So you might as well use request because the data can not be trusted either way. -- John It is true that you cannot trust any data coming from a client (i.e., POST, GET, COOKIE, REQUEST, Whatever). However, in trying to secure what you are doing it makes sense to know specifically the origin of your data. Additionally, if you know specifically where your data is coming from, then there are no surprises as there can be by using REQUEST. I am sure you realize that the data provided by a REQUEST can be overridden by processes you may have not accounted for. For example, while you are thinking that the data you're working on was provided by one super global it actually was overridden by another can lead to problems, including security. One security directive is to keep the process simple and under control. The more complicated you make it, the less secure it becomes regardless of the method of data collection. Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] $_POST vs $_REQUEST
From: Rene Veerman [mailto:rene7...@gmail.com]
> On Mon, Feb 22, 2010 at 9:39 PM, Slack-Moehrle
>>
>> Single quotes is best, correct to prevent sql injection?
>
> sql injection fixing is an evolving art, but you can start by pushing
> all variables that can be changed by end-users going into a database
> through a marshalling-function fixSQLinjectionToDB ($var) { return
> addslashes($var); };
> addslashes is the minimum fix i believe, but google around and give us
> back the up-to-date uber-fix-function please :)
Slash is the wrong character. The correct SQL escape character is the
single quote.
The best way to prepare text fields is to use the DB specific escape
functions on each text field before assembling the command string, i.e.
pg_escape_string(). But that is after all fields have been sanitized and
validated.
In addition, if magic_quotes is turned on, you also need to remove them
before doing the validation. The contributed notes in the online manual
have some good suggestions on how to accomplish this.
Bob McConnell
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
On Tue, 2010-02-23 at 09:19 +, Richard wrote: > Hi, > > Well people better than me (how is that possible?!) have said that > $_REQUEST has the potential to open your app up to security > vulnerabilities, and that it should be avoided because of that. Here's > a post from Stephan Esser about it on the PHP-Internals list: > > http://www.mail-archive.com/intern...@lists.php.net/msg32832.html > > Stephan heads up the Hardened-PHP project and when it comes to > security, I don't know of anyone better. So, if he advises not to use > _REQUEST, it's a good idea to follow that advice. > > -- > Richard Heyes > Well, he's only saying there that it 'most probably vulnerable' and mentions that cookies can overwrite post and get data. This isn't a problem with $_REQUEST itself but rather an applications' use of it. So what if someone crafts a cookie to send a bad value. If someone has the gen to do that, then they are going to know how to send get and post values as well. Only decent sanitisation will be able to protect against this. If the order of override variables in $_REQUEST is such an issue too, use the request_order ini setting to specify the order you'd prefer. I've never had any issues with using $_REQUEST, but found a lot of advantages to using it, as I often use a mix of data sources in the same app. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] $_POST vs $_REQUEST
Hi, Well people better than me (how is that possible?!) have said that $_REQUEST has the potential to open your app up to security vulnerabilities, and that it should be avoided because of that. Here's a post from Stephan Esser about it on the PHP-Internals list: http://www.mail-archive.com/intern...@lists.php.net/msg32832.html Stephan heads up the Hardened-PHP project and when it comes to security, I don't know of anyone better. So, if he advises not to use _REQUEST, it's a good idea to follow that advice. -- Richard Heyes -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
On Mon, 2010-02-22 at 23:49 +0100, John Black wrote: > On 02/22/2010 11:42 PM, Michael Shadle wrote: > > The difference here is you can at least have some control over the data > > and expect it in a certain fashion. Also the behavior of cookies vs. get > > vs. post are different (cookies have length and expiration limits, get > > has length limits, post has server confgured limits) > > The cookie and post/get part is all mixed up now :) > > I use $_COOKIE when I want cookie information but I know that the data > is not to be trusted and is easily fabricated. > > When reading get or post I just use $_REQUEST nowadays because I don't > have to care how the submitting form is written. This makes my form > handling data more portable. > > -- > John > You may say I'm a dreamer, but I'm not the only one, > I hope some day you'll join us, And the world will live as one. > [John Lennon] > As many people have mentioned already, there's absolutely no security risk of using $_REQUEST over $_POST or $_GET. I generally use $_REQUEST unless I am specifically coding something that needs me to send data over both post and get at the same time. The thing is, just make sure you sanitise all the data that comes from the browser. That includes cookie values, post data, etc. Proper sanitisation is crucial and necessary, and no amount of obscurity about how you are getting your data will help. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] $_POST vs $_REQUEST
On 02/22/2010 11:42 PM, Michael Shadle wrote: The difference here is you can at least have some control over the data and expect it in a certain fashion. Also the behavior of cookies vs. get vs. post are different (cookies have length and expiration limits, get has length limits, post has server confgured limits) The cookie and post/get part is all mixed up now :) I use $_COOKIE when I want cookie information but I know that the data is not to be trusted and is easily fabricated. When reading get or post I just use $_REQUEST nowadays because I don't have to care how the submitting form is written. This makes my form handling data more portable. -- John You may say I'm a dreamer, but I'm not the only one, I hope some day you'll join us, And the world will live as one. [John Lennon] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
Op 2/22/10 8:39 PM, Slack-Moehrle schreef: > Hi All, > > I have Forms that I submit for processing. I have seen examples of people > using either $_POST or $_REQUEST. > > When would I choose one over the other? use $_POST, $_REQUEST is normally an amalgam of GET, POST and COOKIE - as such using $_REQUEST can open you up to a denial of service attack (if someone manages to place cookies with the same names as your form fields they will always override what was in the POST). avoid using $_REQUEST. > Also, I see examples of these being used with and without the single quotes > > Like: > > $_POST[j_orderValue] this generates an E_NOTICE and is bad practice, it's also slower, essentially PHP sees the CONSTANT j_orderValue which it can't find and does it's best to accomodate sloppy code by tranlating it into the string 'j_orderValue' try turning up the ini setting 'error_reporting' to include E_NOTICE warnings (and everything else) and see what else your code might be doing which isn't quite right ... it can be very helpful, I'm assuming you're running a local webserver, as running that in production is a bit pointless in my view (additionally having the ini setting 'display_errors' turned on in production is a security issue) > or > $_POST['j_orderValue'] > > Single quotes is best, correct to prevent sql injection? this does nothing for SQL injection prevention, for that you need the escaping function for the DB you use ... for MySQL that would be mysql_real_escape_string(). > -ML > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
The difference here is you can at least have some control over the data and expect it in a certain fashion. Also the behavior of cookies vs. get vs. post are different (cookies have length and expiration limits, get has length limits, post has server confgured limits) Like I said a properly coded app won't really suffer much but why allow for lazy coding practices and non properly coded apps to be exploited as easy? The great deal of apps out there are not properly coded. Again I reference my metaphor about dying. At least try to put effort into something. On Feb 22, 2010, at 2:26 PM, John Black technologies.org> wrote: On 02/22/2010 11:17 PM, Michael Shadle wrote: "Secure" might be the wrong term here. As you can easily change GET to POST and vice-versa and send any cookies you like, this is why I tried to revise my statement and quantify it better... in a properly coded app it doesn't present much issue. However, it encourages laziness and PHP's barrier to entry is so easy that there is a lot of people who consider a cookie to be trusted, and overriding it with a simple GET parameter is too easy of an attack vector. At least make it difficult. Just because someone believes that a cookie is something that can be trusted does not make it so. A properly coded app should not care how the client sends the information, only that the information is it valid and expected. A cookie is the same thing as $_POST or $_GET data but it can be stored for a period of time, what happens to the stored data is out of our control. Treating one any different from the other is just wrong and will create apps with security holes. For anybody who would like to try the GUI version of tampering with data sent to the server checkout TamperData for FireFox. -- John Klarmachen zum Ändern! http://www.youtube.com/v/AYM-_qfytfA -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
On Mon, Feb 22, 2010 at 22:37, Michael Shadle wrote: > On Mon, Feb 22, 2010 at 1:30 PM, David Murphy wrote: >> Richard, >> >> >> The use of $_REQUEST it no more a security hole than $_GET or $_REQUEST, >> they should ALL be treats as bad data until normalized and sanitized. The >> claim that it opens a security hole is just false, that’s like saying PHP >> is insecure, its not it just allows for lazy coding such as $_REQUEST. > > It represents a way for people to exploit coders who don't know any better. > > Expecting a cookie value to come through in $_REQUEST but you could > override using a query string parameter makes for easy exploitation. > Probably not catastrophic but much easier to brute force things if you > don't have to bother with cookies, or can fake a user identity easier; > things of that nature. > > If you coded your app well, in theory it won't make much difference, > however, why keep something out there that makes it easier for people > to mess with your site, period? Using $_REQUEST poses no security issues whatsoever. Just because there are incompetent programmers doesn't mean that a language feature is inherently insecure. It's entirely dependent on how you use it. A pen is also dangerous if you stab someone in the eye with it. Certain features in PHP may be dangerous if you give them to incompetent people who don't know what they're doing. Besides, whether or not you can "override" cookie values depends on whether the programmer also uses $_REQUEST for cookie values and the request_order php.ini directive. The value in the php.ini files that ship with PHP 5.3 default to only including GET and POST data for instance: http://svn.php.net/viewvc/php/php-src/tags/php_5_3_1/php.ini-production?view=markup#l671 If an attacker can do an HTTP GET request, he can most likely also do an HTTP POST request (and vice versa) and the input value will be no more (in)secure regardless of the source. Using $_GET/$_POST in place of $_REQUEST is no more than security theater in my opinion. -- Daniel Egeberg -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
On 02/22/2010 11:17 PM, Michael Shadle wrote: "Secure" might be the wrong term here. As you can easily change GET to POST and vice-versa and send any cookies you like, this is why I tried to revise my statement and quantify it better... in a properly coded app it doesn't present much issue. However, it encourages laziness and PHP's barrier to entry is so easy that there is a lot of people who consider a cookie to be trusted, and overriding it with a simple GET parameter is too easy of an attack vector. At least make it difficult. Just because someone believes that a cookie is something that can be trusted does not make it so. A properly coded app should not care how the client sends the information, only that the information is it valid and expected. A cookie is the same thing as $_POST or $_GET data but it can be stored for a period of time, what happens to the stored data is out of our control. Treating one any different from the other is just wrong and will create apps with security holes. For anybody who would like to try the GUI version of tampering with data sent to the server checkout TamperData for FireFox. -- John Klarmachen zum Ändern! http://www.youtube.com/v/AYM-_qfytfA -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
On Mon, Feb 22, 2010 at 5:02 PM, Slack-Moehrle wrote: > John, > >>>Then if you use a MySQL database you would escape the string like this >>>$tmp = mysql_real_escape_string($_REQUEST['yyy']); > > >>>mysql_real_escape_string() protect from SQL injection by escaping your >>>string according to what your charset requires. > > Good point, I should be doing that. But only to String, not data stored in > MySQL as Int or Date, etc. > > -ML Just to clarify, while you would not use mysql_real_escape_string() for datatypes other than strings, you still need to do filtering, validation, and sanity checking on other datatypes as well. As I pointed out in another thread recently, these are just as vulnerable to SQL injection even though the variable values are expected to be integers or dates: $sql = "SELECT `my_id`, `my_message` FROM `my_comments` WHERE `my_id` = $my_id"; $sql = "SELECT `post_id`, `post_text`, `post_date` FROM `blog_posts` WHERE `post_date` BETWEEN '$first_post_date' AND '$last_post_date'"; IMO mysql_real_escape_string() (or any similar function used for different db vendors) is just a method to escape sequences that have special meaning in a SQL query. It is the LAST step you should perform when processing input to be saved in a MySQL database (when parameterized queries are not available), after you have done everything you can to ensure that ALL the values being passed in the query are valid. Andrew -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
On Mon, Feb 22, 2010 at 2:07 PM, John Black wrote: > And how is this more secure? I can create a cookie, send post or get on my > client machine and send anything I want to the server. Just because you are > getting a cookie does not mean that you created it :) > > So you might as well use request because the data can not be trusted either > way. Kind of like saying "why bother exercising and keeping healthy - we're going to die anyway" "Secure" might be the wrong term here. As you can easily change GET to POST and vice-versa and send any cookies you like, this is why I tried to revise my statement and quantify it better... in a properly coded app it doesn't present much issue. However, it encourages laziness and PHP's barrier to entry is so easy that there is a lot of people who consider a cookie to be trusted, and overriding it with a simple GET parameter is too easy of an attack vector. At least make it difficult. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
On 02/22/2010 10:37 PM, Michael Shadle wrote: On Mon, Feb 22, 2010 at 1:30 PM, David Murphy wrote: Richard, The use of $_REQUEST it no more a security hole than $_GET or $_REQUEST, they should ALL be treats as bad data until normalized and sanitized. The claim that it opens a security hole is just false, that’s like saying PHP is insecure, its not it just allows for lazy coding such as $_REQUEST. It represents a way for people to exploit coders who don't know any better. Expecting a cookie value to come through in $_REQUEST but you could override using a query string parameter makes for easy exploitation. And how is this more secure? I can create a cookie, send post or get on my client machine and send anything I want to the server. Just because you are getting a cookie does not mean that you created it :) So you might as well use request because the data can not be trusted either way. -- John Gerechtigkeit entspringt dem Neid; denn ihr oberster Grundsatz ist: Allen das Gleiche. [Walther Rathenau] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
John, >>Then if you use a MySQL database you would escape the string like this >>$tmp = mysql_real_escape_string($_REQUEST['yyy']); >>mysql_real_escape_string() protect from SQL injection by escaping your >>string according to what your charset requires. Good point, I should be doing that. But only to String, not data stored in MySQL as Int or Date, etc. -ML -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
On Mon, Feb 22, 2010 at 1:30 PM, David Murphy wrote: > Richard, > > > The use of $_REQUEST it no more a security hole than $_GET or $_REQUEST, > they should ALL be treats as bad data until normalized and sanitized. The > claim that it opens a security hole is just false, that’s like saying PHP > is insecure, its not it just allows for lazy coding such as $_REQUEST. It represents a way for people to exploit coders who don't know any better. Expecting a cookie value to come through in $_REQUEST but you could override using a query string parameter makes for easy exploitation. Probably not catastrophic but much easier to brute force things if you don't have to bother with cookies, or can fake a user identity easier; things of that nature. If you coded your app well, in theory it won't make much difference, however, why keep something out there that makes it easier for people to mess with your site, period? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] $_POST vs $_REQUEST
Richard, The use of $_REQUEST it no more a security hole than $_GET or $_REQUEST, they should ALL be treats as bad data until normalized and sanitized. The claim that it opens a security hole is just false, thats like saying PHP is insecure, its not it just allows for lazy coding such as $_REQUEST. David Murphy -Original Message- From: richard.he...@gmail.com [mailto:richard.he...@gmail.com] On Behalf Of Richard Sent: Monday, February 22, 2010 3:03 PM To: Joseph Thayne Cc: Slack-Moehrle; php-general Subject: Re: [PHP] $_POST vs $_REQUEST Hi, > I am not sure what the security issues are you are referring to as the > $_REQUEST superglobal contains both $_GET and $_POST values. Could you > expound on that? Thanks. Not really, do a search. -- Richard Heyes HTML5 canvas graphing: RGraph - http://www.rgraph.net (updated 20th February) Lots of PHP and Javascript code - http://www.phpguru.org -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
On Mon, Feb 22, 2010 at 12:55 PM, Joseph Thayne wrote: > I am not sure what the security issues are you are referring to as the > $_REQUEST superglobal contains both $_GET and $_POST values. Could you > expound on that? Thanks. $_REQUEST opens you up to POST/GET values overriding cookie values or vice versa. It's best to choose your source of data specifically. I unset($_REQUEST) wherever I can to enforce stricter coding practices. To me it's lazy. If you really need to mix POST and GET, then you can always array_merge($_POST, $_GET) >> Use quoted strings - either single or double quotes. Eg: >> >> $myArray['myKey'] >> $myArray["myKey"] single quotes are better (by a marginal fraction) as it won't look for interpolated strings :) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
> I have Forms that I submit for processing. I have seen examples of people > using either $_POST or $_REQUEST. > Look at this example: Now what do you thing $_REQUEST will return? You had better not even think. Just use $_POST or $_GET as you _know_ what they will return. Don't forget, there might even be a cookie with the name "foo". -- Dotan Cohen http://bido.com http://what-is-what.com Please CC me if you want to be sure that I read your message. I do not read all list mail. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
Hi Slack-Moehrle
Slack-Moehrle wrote on 22/02/2010 21:39:
Hi All,
I have Forms that I submit for processing. I have seen examples of people using
either $_POST or $_REQUEST.
When would I choose one over the other?
$_REQUEST['test'] is true on both $_GET['test'] and $_POST['test']
I use it from time to time if I have a edit link followed by a form
posting (where I use method=post), if I decide to have all editing in
one statement, IE:
if($_REQUEST['test']) {
if($_GET['test']) {
// make the form here
}
elseif($_POST['test']) {
// get posting from the form
}
}
Also, I see examples of these being used with and without the single quotes
Like:
$_POST[j_orderValue]
or
$_POST['j_orderValue']
Single quotes is best, correct to prevent sql injection?
Best practice is with '', if you have E_NOTICE on you'll get notices if
you use $_POST[test] instead of $_POST['test']
It has nothing to do with SQL injection here. But when dealing with SQL
statements it's best practice to use '', for instance if you are about
to insert and a number at some point could be inserted as part of the
statement: "price = 250" will do fine, but if price ain't entered "price
= " will cause an error, while "price = ''" will not make the sql insert
fail.
Regarding SQL injection, run all inputs through the function
mysql_real_escape_string()
--
Kind regards
Kim Emax - masterminds.dk
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
Hi, > I am not sure what the security issues are you are referring to as the > $_REQUEST superglobal contains both $_GET and $_POST values. Could you > expound on that? Thanks. Not really, do a search. -- Richard Heyes HTML5 canvas graphing: RGraph - http://www.rgraph.net (updated 20th February) Lots of PHP and Javascript code - http://www.phpguru.org -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
> i'd expect without quotes to query a define('j_orderValue','??')..
oh, and that, if not defined, defaults to the string 'j_orderValue'.
So while your $_POST[] with or without quotes will "do the same", use
single-quotes anyway because it's "the right thing to do" ;)
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
On 02/22/2010 09:39 PM, Slack-Moehrle wrote:
Hi All,
I have Forms that I submit for processing. I have seen examples of people using
either $_POST or $_REQUEST.
When would I choose one over the other?
When you don't care how you get the data use $_REQUEST.
$_REQUEST will contain $_GET,$_POST,$_COOKIE in the order specified in
php.ini. Don't know what the default is.
$_POST[j_orderValue]
Don't do that, PHP will bitch that you are attempting to use a constant
as a string or something like that. Make sure you enable error reporting
in php.ini and use
display_errors = On
error_reporting = E_ALL | E_STRICT
for development but not on your server unless you log only.
$_POST['j_orderValue']
There are a few ways to write this properly, depending on how you use
it. The above is how I usually use it but this is also possible.
x = $_POST['j_orderValue'] <= that is how I write it
x = $_POST["j_orderValue"] <= also ok because it is a stirng
for $x=0; $x < 10, $x++ )
$foo[$x] = $_POST["j_orderValue$x"]
is also possible
echo "foo $_POST[j_orderValue]";
echo "foo {$_POST['j_orderValue']}";
and a few more, there was a great thread a while back which listed
every possible combination.
Single quotes is best, correct to prevent sql injection?
SQL injects happen when you use the $_RESQUEST[] information, as is, in
your SQL string.
SELECT * FROM foo WHERE XXX=$_REQUEST['yyy'] <= very bad!
You should be doing:
... code sanity check here.
- is a number really number, length and so on ...
Then if you use a MySQL database you would escape the string like this
$tmp = mysql_real_escape_string($_REQUEST['yyy']);
and use it like this.
SELECT * FROM foo WHERE XXX=$tmp
mysql_real_escape_string() protect from SQL injection by escaping your
string according to what your charset requires.
--
John
Nur wer im Wohlstand lebt, schimpft auf ihn.
[Ludwig Marcuse]
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
On Mon, Feb 22, 2010 at 9:39 PM, Slack-Moehrle
wrote:
> Hi All,
>
> I have Forms that I submit for processing. I have seen examples of people
> using either $_POST or $_REQUEST.
>
> When would I choose one over the other?
I like to be specific and go for $_POST, but some people want
flexibility in their code and use $_REQUEST.
It's usually no big deal to me.
>
> Also, I see examples of these being used with and without the single quotes
>
> Like:
>
> $_POST[j_orderValue]
> or
> $_POST['j_orderValue']
i'd expect without quotes to query a define('j_orderValue','??')..
and yea, use single quotes whereever possible..
it's my exp that
'bla bla $var da da' is harder to read (in syntax-highlighted source
editors) than
'bla bla '.$var.' da da'
that's aside from speed improvements, which do add up quickly in high
load situations.
> Single quotes is best, correct to prevent sql injection?
sql injection fixing is an evolving art, but you can start by pushing
all variables that can be changed by end-users going into a database
through a marshalling-function fixSQLinjectionToDB ($var) { return
addslashes($var); };
addslashes is the minimum fix i believe, but google around and give us
back the up-to-date uber-fix-function please :)
Might be wise to look ahead and use a unmarshalling function
placeholder fixSQLinjectionFromDB() for any (varchar/text) variable
coming from the database and being used by your program for anything.
You'll have to look ahead; if you allow endusers to store any text in
your database, you can't just re-use that text in your output HTML
another time. you will need something that strips bad html, s,
flash, and javascript, to be completely secure. I've once been
infected with a piece of very cryptic js (that loaded quite a bit more
into the browser) that caused my site to be blacklisted by google..
Big fat red-black warnings by firefox about it too..
lastly, it also helps to use something like adodb.sf.net as a database
abstraction engine, btw.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
Richard wrote: It's a wise choice to go with $_POST, unless your form is a GET form, in which case use $_GET. $_REQUEST has the potential to open your script(s) up to security issues. I am not sure what the security issues are you are referring to as the $_REQUEST superglobal contains both $_GET and $_POST values. Could you expound on that? Thanks. Use quoted strings - either single or double quotes. Eg: $myArray['myKey'] $myArray["myKey"] To answer your question though, the quotes will not protect you from SQL injection at all. It simply has to do with processing the values. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
On Tue, Feb 23, 2010 at 2:39 AM, Slack-Moehrle wrote: > Hi All, > > I have Forms that I submit for processing. I have seen examples of people > using either $_POST or $_REQUEST. > > When would I choose one over the other? > > Also, I see examples of these being used with and without the single quotes > > Like: > > $_POST[j_orderValue] > or > $_POST['j_orderValue'] > > Single quotes is best, correct to prevent sql injection? You must use quote. either single or double. It wont affect sql injection. Sanitize your data before using it in any sql. $_REQUEST['var'] means a variable var was passed in http request. $_POST['var'] means a post variable var was passed in http request. A get or cookie variable var2 will set $_REQUEST['var2']. When you are strictly expecting a Post variable 'var3' use $_POST['var3'], not $_REQEUST['var3']. This is because a $_GET['var3'] will make $_REQEUST['var3'] available to you which is not what you want. Correct me if I am wrong. -- Shiplu Mokaddim My talks, http://talk.cmyweb.net Follow me, http://twitter.com/shiplu SUST Programmers, http://groups.google.com/group/p2psust Innovation distinguishes bet ... ... (ask Steve Jobs the rest) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
Hi, > I have Forms that I submit for processing. I have seen examples of people > using either $_POST or $_REQUEST. > > When would I choose one over the other? It's a wise choice to go with $_POST, unless your form is a GET form, in which case use $_GET. $_REQUEST has the potential to open your script(s) up to security issues. > ... Use quoted strings - either single or double quotes. Eg: $myArray['myKey'] $myArray["myKey"] -- Richard Heyes HTML5 canvas graphing: RGraph - http://www.rgraph.net (updated 20th February) Lots of PHP and Javascript code - http://www.phpguru.org -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST is empty , but were are the variables posted??
On Thu, 2009-12-17 at 13:30 -0800, Steve wrote: > On 12/17/2009 1:21 PM, gato chlr wrote: > > Hi, > > sorry for ask this again, but i really can't solve it. > > It must be easy but i can't find the solution > > > > this is my code: > > //form.php > > > > name : > > > > > > > > //and this is the mail.php > > $name = $_POST["myname"]; > > var_dump($name); > > > > and the result is: > > NULL > > > > i'm using php 5, i don'd know what is wrong and i have readed a lot of blogs > > and forums, there is a lot of people with this problem , but i have not > > found a solution. thanks for the help > > > > > You need to name your field with name="myname" > > //form.php > > name : > > > > The id attribute is used to attach the element to a or to interact with it with CSS or Javascript. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] $_POST is empty , but were are the variables posted??
THANKS A LOT!!! to every one!!! . it works. 2009/12/17 Joseph Thayne > Give your input a name. (i.e. name="myname") > > -Original Message- > From: gato chlr [mailto:dany...@gmail.com] > Sent: Thursday, December 17, 2009 3:22 PM > To: php-general@lists.php.net > Subject: [PHP] $_POST is empty , but were are the variables posted?? > > Hi, > sorry for ask this again, but i really can't solve it. > It must be easy but i can't find the solution > > this is my code: > //form.php > > name : > > > > //and this is the mail.php > $name = $_POST["myname"]; > var_dump($name); > > and the result is: > NULL > > i'm using php 5, i don'd know what is wrong and i have readed a lot of > blogs > and forums, there is a lot of people with this problem , but i have not > found a solution. thanks for the help > >
Re: [PHP] $_POST is empty , but were are the variables posted??
On 12/17/2009 1:21 PM, gato chlr wrote: Hi, sorry for ask this again, but i really can't solve it. It must be easy but i can't find the solution this is my code: //form.php name : //and this is the mail.php $name = $_POST["myname"]; var_dump($name); and the result is: NULL i'm using php 5, i don'd know what is wrong and i have readed a lot of blogs and forums, there is a lot of people with this problem , but i have not found a solution. thanks for the help You need to name your field with name="myname" //form.php name : -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] @$_POST[...]
Chris wrote:
> Luke wrote:
>> 2009/4/22 PJ
>>
>>> Could somebody explain to me the meaning of @ in $var =
>>> @$_POST['title'] ;
>>> where could I find a cheat sheet for those kinds of symbols or what are
>>> they called?
>>> Sorry for my ignorance, but maybe this will take the fog filter our of
>>> my neurons. :-\
>> I believe placing an @ in front of a statement suppresses any error
>> messages
>> it generates.
>>
>
> It does - in this case if 'title' is not posted as part of the form,
> it would have generated a warning or notice (can't remember which).
>
> A longer path is:
>
> $var = '';
> if (isset($_POST['title'])) {
> $var = $_POST['title'];
> }
>
> The shortcut works but it makes it extremely difficult to find
> problems with your scripts (think of 50 @'s being used in one script..
> eek).
>
Thanks for refreshing my memory... I had run across this but forgot as I
usually do not use it. I turn on all error checking and stumble through
prin_r() and var_dump() ... whatever. :-D
--
unheralded genius: "A clean desk is the sign of a dull mind. "
-
Phil Jourdan --- p...@ptahhotep.com
http://www.ptahhotep.com
http://www.chiccantine.com/andypantry.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] @$_POST[...]
On Thu, Apr 23, 2009 at 5:26 AM, PJ wrote: > 9el wrote: >> Rather than looking for cheatsheets you should read the ZCE >> preparation guide book and PHP manual. >> >> > That's a lame duck response. I'm not stupid enough to not search and try > to find answers on G and in the manuals & tutorials. They are not always > obvious so I often rely on the great guys on this list to clear things > up. And I have no ide what ZCE is nor do I really care. I'd call you a lame duck just for now. Cause, you could have asked Google what ZCE is. And if you should like programming in PHP you should care about the ZCE as well. ZCE means Zend Certified Engineer. And I refered to that book because that book helped me preparing for that exam. Which covers really important best practices PHP Developers should be aware of. I am not giving you more info as you said you can use Google. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] @$_POST[...]
Luke wrote:
2009/4/22 PJ
Could somebody explain to me the meaning of @ in $var = @$_POST['title'] ;
where could I find a cheat sheet for those kinds of symbols or what are
they called?
Sorry for my ignorance, but maybe this will take the fog filter our of
my neurons. :-\
I believe placing an @ in front of a statement suppresses any error messages
it generates.
It does - in this case if 'title' is not posted as part of the form, it
would have generated a warning or notice (can't remember which).
A longer path is:
$var = '';
if (isset($_POST['title'])) {
$var = $_POST['title'];
}
The shortcut works but it makes it extremely difficult to find problems
with your scripts (think of 50 @'s being used in one script.. eek).
--
Postgresql & php tutorials
http://www.designmagick.com/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] @$_POST[...]
9el wrote: > Rather than looking for cheatsheets you should read the ZCE > preparation guide book and PHP manual. > > That's a lame duck response. I'm not stupid enough to not search and try to find answers on G and in the manuals & tutorials. They are not always obvious so I often rely on the great guys on this list to clear things up. And I have no ide what ZCE is nor do I really care. -- unheralded genius: "A clean desk is the sign of a dull mind. " - Phil Jourdan --- p...@ptahhotep.com http://www.ptahhotep.com http://www.chiccantine.com/andypantry.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] @$_POST[...]
Rather than looking for cheatsheets you should read the ZCE preparation guide book and PHP manual. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] @$_POST[...]
2009/4/22 PJ > Could somebody explain to me the meaning of @ in $var = @$_POST['title'] ; > where could I find a cheat sheet for those kinds of symbols or what are > they called? > Sorry for my ignorance, but maybe this will take the fog filter our of > my neurons. :-\ > > -- > unheralded genius: "A clean desk is the sign of a dull mind. " > - > Phil Jourdan --- p...@ptahhotep.com > http://www.ptahhotep.com > http://www.chiccantine.com/andypantry.php > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > I believe placing an @ in front of a statement suppresses any error messages it generates. -- Luke Slater :O)
Re: [PHP] $_POST suddenly empty; $_GET and _$REQUEST fine
Quoting "Daniel P. Brown" <[EMAIL PROTECTED]>: On Wed, Dec 3, 2008 at 6:03 PM, Alex Kirk <[EMAIL PROTECTED]> wrote: It works like a charm on a different machine with an essentially identical config (it's a newer version of FreeBSD, but that's about it); however, it never displays the contents of $_POST['testvar'] on the machine that suddenly quit functioning right last night. Check your php.ini and make sure your EGPCS (variables_order) is okay. It is. In fact, my config is virtually default: [EMAIL PROTECTED] /usr/local/etc]$ diff -u php.ini php.ini-dist --- php.ini Wed Dec 3 16:08:31 2008 +++ php.ini-distTue Jul 22 11:00:49 2008 @@ -328,7 +328,7 @@ ; ; stdout (On) - Display errors to STDOUT ; -;display_errors = On +display_errors = On ; Even when display_errors is on, errors that occur during PHP's startup ; sequence are not displayed. It's strongly recommended to keep @@ -338,7 +338,7 @@ ; Log errors into a log file (server-specific log, stderr, or error_log (below)) ; As stated above, you're strongly advised to use error logging in place of ; error displaying on production web sites. -log_errors = On +log_errors = Off ; Set maximum length of log_errors. In error_log information about the source is ; added. The default is 1024 and 0 allows to not apply any maximum length at all. @@ -384,7 +384,7 @@ ;error_append_string = "" ; Log errors to specified file. -error_log = /var/log/php.err +;error_log = filename ; Log errors to syslog (Event Log on NT, not valid in Windows 95). ;error_log = syslog This message was sent using IMP, the Internet Messaging Program. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST suddenly empty; $_GET and _$REQUEST fine
On Wed, Dec 3, 2008 at 6:03 PM, Alex Kirk <[EMAIL PROTECTED]> wrote: > > It works like a charm on a different machine with an essentially identical > config (it's a newer version of FreeBSD, but that's about it); however, it > never displays the contents of $_POST['testvar'] on the machine that > suddenly quit functioning right last night. Check your php.ini and make sure your EGPCS (variables_order) is okay. -- http://www.parasane.net/ [EMAIL PROTECTED] || [EMAIL PROTECTED] 50% Off Hosting! http://www.pilotpig.net/specials.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST suddenly empty; $_GET and _$REQUEST fine
[EMAIL PROTECTED] wrote: There are httpd.conf settings to reject POST requests, but I don't think it would behave like that... But maybe it's a bit more complicated than what I've ever seen for httpd.conf Could be mod_security getting in the way and killing some content. -- Postgresql & php tutorials http://www.designmagick.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST suddenly empty; $_GET and _$REQUEST fine
There are httpd.conf settings to reject POST requests, but I don't think it would behave like that... But maybe it's a bit more complicated than what I've ever seen for httpd.conf -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] $_POST suddenly empty; $_GET and _$REQUEST fine
-Original Message- From: Alex Kirk I've got an Apache 2.2.3 server running PHP 5.2.6 on top of FreeBSD 6.2. It's worked quite well for over a year now. However, as of some time last night, phpBB broke; upon investigation, I realized that the problem was that $_POST was never getting populated, even on properly formed HTML forms. Testing this to try to find the issue, I used the following script: \n"; ?> http://www.newmars.com/test.php name=formname enctype="multipart/form-data"> It works like a charm on a different machine with an essentially identical config (it's a newer version of FreeBSD, but that's about it); however, it never displays the contents of $_POST['testvar'] on the machine that suddenly quit functioning right last night. Meanwhile, the rest of PHP seems to be working fine, as the phpBB forum is accessible in a read-only fashion. I've searched all over, and done things like restarting Apache; checking phpinfo() for the POST data (it's not there on the broken server, but it is on the functional one); writting a quick Perl script that took POST input to verify that my browser was sending such data properly (it is); and scouring the Apache/PHP error logs. The worst part is, I didn't touch the config at all between when it worked and when it didn't. So now I'm at a total loss as to what could be causing this, or how I should go about troubleshooting... == Did you check the apache logs or the php error logs? How about disk space on the server location where it is storing it's temp files for the server? I've seen something similar when disk space was nil after some scripts ran amok. HTH, Wolf -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST in header
Hi Alain,
In short, you can't. It's the users computer that remembers what headers
it sent last time, and when you refresh, it WILL ask them to send those
headers again.
The way this is typically handled from a programming perspective is to
do all your processing on one page, and then jump away [via
header("Location: ") ] to another page for display. This is the only
way I have come across to solve this problem.
You could use a Switch statement on the page to handle this, by passing
it's case via querystring. e.g. Case 1: Process; Case 2: display;
Hope this helps,
- Craige
Alain Roger wrote:
Hi,
i have a PHP page with a form.
when user click on submit button, it sends form data to itself (so it sends
data $_POST to itself).
i would like to access to header itself to reset those $_POST data to avoid
(in case of F5 under windows system) to resend the same data serveral time.
therefore how can i get the header data and change them ?
thx
F.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] $_POST in header
[snip] i have a PHP page with a form. when user click on submit button, it sends form data to itself (so it sends data $_POST to itself). i would like to access to header itself to reset those $_POST data to avoid (in case of F5 under windows system) to resend the same data serveral time. therefore how can i get the header data and change them ?[/snip] That is not really a good way to handle it. Use session data and check if the data exists for the submission...if it does do nothing with the data, if it doesn't you can process normally. And always sanitize user input! -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST Array and Cleaning
> On Jan 21, 2008 3:22 AM, nihilism machine <[EMAIL PROTECTED]> wrote: > > I'm trying to create a function that will first take an array of > > $_POSTs and give them key/value pairs like variables. For instance, if > > i had $_POST['whatever'] = "whatever", that would be made into > > $whatever = "whatever", then i can clean for sql injection and xss. > > any ideas here? i use a combination of php.net/filter, bounds checking for integers/etc, appropriate text escaping (i.e. like mysql_escape_string) prior to any db queries with text data, intval($var) on anything needing to be converted to integer (although filter will do that for you too) also - suhosin might help with some things. i run both the patch and the module. > Consider usage of a 3rd party lib like Inspekt: > http://code.google.com/p/inspekt/ i'll look at this too, thanks -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST Array and Cleaning
On Jan 21, 2008 3:22 AM, nihilism machine <[EMAIL PROTECTED]> wrote: > I'm trying to create a function that will first take an array of > $_POSTs and give them key/value pairs like variables. For instance, if > i had $_POST['whatever'] = "whatever", that would be made into > $whatever = "whatever", then i can clean for sql injection and xss. > any ideas here? Consider usage of a 3rd party lib like Inspekt: http://code.google.com/p/inspekt/ -- Manuel -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST Array and Cleaning
On Jan 20, 2008 9:22 PM, nihilism machine <[EMAIL PROTECTED]> wrote:
> I'm trying to create a function that will first take an array of
> $_POSTs and give them key/value pairs like variables. For instance, if
> i had $_POST['whatever'] = "whatever", that would be made into
> $whatever = "whatever", then i can clean for sql injection and xss.
> any ideas here?
>
foreach($_POST as $curPostKey => $curPostVal) {
cleanPost($curPostKey); // <-- todo: implement me
$$curPostKey = $curPostVal;
}
-nathan
Re: [PHP] $_POST superglobal empty, while readfile("php://input")does return data.
On 11/4/07, Mackatack <[EMAIL PROTECTED]> wrote: > > I have not defined any tags in my httpd.conf and by default > apache should accept all request methods. I've stripped my apache config > down to: > > Listen 80 > NameVirtualHost *:80 > > ServerName my.server.com > DocumentRoot "/var/www/ > > AllowOverride All > Order allow,deny > Allow from all > > > > Also, im guessing it's not apache related because the readfile() > function does return the form data. Any other thoughts? > what happens when you change the request method to get? also, just curious, when you disable zend optimizer and suhosin, how exactly are you doing that? my feeling is that you may have to unmerge them and completely recompile php. have you looked in the php error logs? i would enable NOTICE and STRICT for testing, error_reporting = E_ALL | E_STRICT perhaps something will turn up there. have you hopped on the irc channel for gentoo-php? irc://irc.freenode.net/gentoo-php it takes a while to get a response sometimes, but this group knows the most about php on gentoo. -nathan
Re: [PHP] $_POST superglobal empty, while readfile("php://input")does return data.
Jim Lucas schreef:
Mackatack wrote:
Nathan Nobbe schreef:
On 11/3/07, Mackatack <[EMAIL PROTECTED]> wrote:
Hey all!
Im trying to submit a very basic form to phpinfo():
readfile: ';
readfile("php://input")
phpinfo();
?>
When i use the button to submit the form and it loads the new page I
get:
var_dump: array(0) { }
readfile: foo=bar
I would expect the $_POST var to be filled cause the readfile does
work.
Also, get requests, cookies and sessions do work... all cept for the
POST data. I couldn't find any errors in the apache error_log.
I think it's not browser related because I tested it another server and
it did work using FF and IE7.
Im using PHP Version 5.2.4_p20070914-pl2-gentoo, with suhosin and the
ZendOptimizer on Linux AMD64. I've also set the max_post and max_upload
to 1024M for testing... Nothing works... :(
Does anyone have a direction for me? Been using php for years but have
never seen anything like this...
is this a new box?
have you tried w/o suhosin and / or zend optimizer?
did the other box you tested on have suhosin?
-nathan
Yes, this is a new box, but i did try without suhosin and the
ZendOptimizer. No dice.
-Mackatack
What about checking to see if Apache has the the POST option disabled.
Make sure the apache is allowing posts to the domain/directory/file/etc...
I have not defined any tags in my httpd.conf and by default
apache should accept all request methods. I've stripped my apache config
down to:
Listen 80
NameVirtualHost *:80
ServerName my.server.com
DocumentRoot "/var/www/
AllowOverride All
Order allow,deny
Allow from all
Also, im guessing it's not apache related because the readfile()
function does return the form data. Any other thoughts?
-Mackatack
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST superglobal empty, while readfile("php://input") does return data.
Mackatack wrote:
Nathan Nobbe schreef:
On 11/3/07, Mackatack <[EMAIL PROTECTED]> wrote:
Hey all!
Im trying to submit a very basic form to phpinfo():
readfile: ';
readfile("php://input")
phpinfo();
?>
When i use the button to submit the form and it loads the new page I
get:
var_dump: array(0) { }
readfile: foo=bar
I would expect the $_POST var to be filled cause the readfile does work.
Also, get requests, cookies and sessions do work... all cept for the
POST data. I couldn't find any errors in the apache error_log.
I think it's not browser related because I tested it another server and
it did work using FF and IE7.
Im using PHP Version 5.2.4_p20070914-pl2-gentoo, with suhosin and the
ZendOptimizer on Linux AMD64. I've also set the max_post and max_upload
to 1024M for testing... Nothing works... :(
Does anyone have a direction for me? Been using php for years but have
never seen anything like this...
is this a new box?
have you tried w/o suhosin and / or zend optimizer?
did the other box you tested on have suhosin?
-nathan
Yes, this is a new box, but i did try without suhosin and the
ZendOptimizer. No dice.
-Mackatack
What about checking to see if Apache has the the POST option disabled.
Make sure the apache is allowing posts to the domain/directory/file/etc...
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST superglobal empty, while readfile("php://input") does return data.
Nathan Nobbe schreef:
On 11/3/07, Mackatack <[EMAIL PROTECTED]> wrote:
Hey all!
Im trying to submit a very basic form to phpinfo():
readfile: ';
readfile("php://input")
phpinfo();
?>
When i use the button to submit the form and it loads the new page I get:
var_dump: array(0) { }
readfile: foo=bar
I would expect the $_POST var to be filled cause the readfile does work.
Also, get requests, cookies and sessions do work... all cept for the
POST data. I couldn't find any errors in the apache error_log.
I think it's not browser related because I tested it another server and
it did work using FF and IE7.
Im using PHP Version 5.2.4_p20070914-pl2-gentoo, with suhosin and the
ZendOptimizer on Linux AMD64. I've also set the max_post and max_upload
to 1024M for testing... Nothing works... :(
Does anyone have a direction for me? Been using php for years but have
never seen anything like this...
is this a new box?
have you tried w/o suhosin and / or zend optimizer?
did the other box you tested on have suhosin?
-nathan
Yes, this is a new box, but i did try without suhosin and the
ZendOptimizer. No dice.
-Mackatack
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
