[PHP] _POST and Session ending Problem

2011-08-26 Thread can kalyoncu
Hello,

I created a membership script. It was working fine. Members can fill out
form and send it and they can continue to use site. But after a while I had
to change host. On the new server when the members fill out form and then
session ends. According to my tests when i delete $var = $_POST['variable']
; session continues as it should be but  this time i can't import variables
value ...

$_POST method usage changed ? because there is unneeded or hidden form
fields variable $_POST imports .

Please note that I am using a new version of apache server now.


Re: [PHP] $_POST value disappearing?

2011-08-02 Thread Donovan Brooke

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?

2011-08-02 Thread Steve Staples
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?

2011-08-02 Thread Richard Quadling
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?

2011-08-02 Thread Richard Quadling
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?

2011-08-02 Thread Florian Lemaitre

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?

2011-08-02 Thread Jônatas Zechim
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
>
>


[PHP] $_POST value disappearing?

2011-08-02 Thread Donovan Brooke

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

2011-04-14 Thread Jim Giner
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

2011-04-14 Thread Stuart Dallas
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

2011-04-14 Thread Nathan Nobbe
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

2011-04-14 Thread Stuart Dallas
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

2011-04-13 Thread Nathan Nobbe
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

2011-04-13 Thread Stuart Dallas
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

2011-04-13 Thread Kirk . Johnson
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

2011-04-13 Thread Jim Giner
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

2011-04-13 Thread Nathan Nobbe
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

2011-04-13 Thread Stuart Dallas
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

2011-04-13 Thread Stuart Dallas
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

2011-04-13 Thread Nathan Nobbe
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

2011-04-13 Thread Jim Giner
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

2011-04-13 Thread Nathan Nobbe
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

2011-04-13 Thread Jim Giner
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

2011-04-13 Thread Stuart Dallas
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

2011-04-13 Thread Eli Orr
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

2011-04-13 Thread Stuart Dallas
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

2011-04-13 Thread Nathan Nobbe
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

2011-04-13 Thread Adam Richardson
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

2011-04-13 Thread Stuart Dallas
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



[PHP] $_POST vars

2011-04-13 Thread Jim Giner
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



Re: [PHP] $_POST variable

2011-03-12 Thread tedd

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

2011-03-12 Thread Shawn McKenzie
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

2011-03-12 Thread tedd

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

2011-03-11 Thread richard gray

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

2011-03-11 Thread Steve Staples
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

2011-03-11 Thread Daniel Brown
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



[PHP] $_POST variable

2011-03-11 Thread Danny
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

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] $_POST issues

2010-12-01 Thread Steve Staples
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

2010-12-01 Thread Marc Guay
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

2010-12-01 Thread Jay Blanchard
[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

2010-12-01 Thread Richard Quadling
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

2010-12-01 Thread Marc Guay
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

2010-12-01 Thread Nadim Attari

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

2010-12-01 Thread Richard Quadling
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

2010-12-01 Thread Jay Blanchard
[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

2010-12-01 Thread Marc Guay
>>> >>    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

2010-12-01 Thread Bundhoo M Nadim

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

2010-12-01 Thread Daniel P. Brown
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

2010-12-01 Thread Richard Quadling
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



[PHP] $_POST issues

2010-12-01 Thread Bundhoo M Nadim

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:



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


Re: [PHP] $_POST vs $_REQUEST

2010-02-25 Thread Jochem Maas
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

2010-02-24 Thread Ashley Sheridan
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

2010-02-24 Thread Rene Veerman
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

2010-02-24 Thread Ashley Sheridan
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

2010-02-23 Thread Jochem Maas
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

2010-02-23 Thread Jochem Maas
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

2010-02-23 Thread tedd

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

2010-02-23 Thread Bob McConnell
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

2010-02-23 Thread Ashley Sheridan
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

2010-02-23 Thread Richard
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

2010-02-22 Thread Ashley Sheridan
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

2010-02-22 Thread John Black

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

2010-02-22 Thread Jochem Maas
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

2010-02-22 Thread Michael Shadle
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

2010-02-22 Thread Daniel Egeberg
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

2010-02-22 Thread John Black

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

2010-02-22 Thread Andrew Ballard
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

2010-02-22 Thread Michael Shadle
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

2010-02-22 Thread John Black

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

2010-02-22 Thread Slack-Moehrle
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

2010-02-22 Thread Michael Shadle
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

2010-02-22 Thread David Murphy
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. 


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

2010-02-22 Thread Michael Shadle
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

2010-02-22 Thread Dotan Cohen
> 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

2010-02-22 Thread Kim Madsen

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

2010-02-22 Thread Richard
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

2010-02-22 Thread Rene Veerman
> 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

2010-02-22 Thread John Black

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

2010-02-22 Thread Rene Veerman
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

2010-02-22 Thread Joseph Thayne



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

2010-02-22 Thread shiplu
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

2010-02-22 Thread Richard
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



[PHP] $_POST vs $_REQUEST

2010-02-22 Thread Slack-Moehrle
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?

-ML

-- 
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??

2009-12-17 Thread Ashley Sheridan
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??

2009-12-17 Thread gato chlr
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??

2009-12-17 Thread Steve

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



[PHP] $_POST is empty , but were are the variables posted??

2009-12-17 Thread gato chlr
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[...]

2009-04-23 Thread PJ
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[...]

2009-04-22 Thread 9el
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[...]

2009-04-22 Thread Chris

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[...]

2009-04-22 Thread PJ
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[...]

2009-04-22 Thread 9el
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-04-22 Thread Luke
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)


[PHP] @$_POST[...]

2009-04-22 Thread 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



Re: [PHP] $_POST suddenly empty; $_GET and _$REQUEST fine

2008-12-03 Thread Alex Kirk

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

2008-12-03 Thread Daniel P. Brown
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

2008-12-03 Thread Chris

[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

2008-12-03 Thread ceo

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

2008-12-03 Thread Wolf
-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



[PHP] $_POST suddenly empty; $_GET and _$REQUEST fine

2008-12-03 Thread 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.


Any thoughts on this would be greatly appreciated.

Alex Kirk



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



  1   2   3   >