Keeping form elements in place after redirect

I have a form that is processed by a php page and then redirected by
the same php page back to the form page again.

After the page has redirected back it clears the data entered in the
form's textfield and combo selections. Is there a simple way of
mainting the user's text/selections after the form has been
redirected?

Cheers,

Chris

Re: Keeping form elements in place after redirect

Chris wrote (a question for a php group):

> I have a form that is processed by a php page and then redirected by
> the same php page back to the form page again.

...as you would do if there were errors or omissions in the filled-in
form.

> After the page has redirected back it clears the data entered in the
> form's textfield and combo selections. Is there a simple way of
> mainting the user's text/selections after the form has been
> redirected?

You have to send back the values and re-display them.

Example:
$contactname = $_POST['contactname'];
$email = $_POST['email'];

........

Re: Keeping form elements in place after redirect

Well bust mah britches and call me cheeky, on Wed, 21 Nov 2007 19:57:57 GMT
Chris scribed:

> I have a form that is processed by a php page and then redirected by
> the same php page back to the form page again.
>
> After the page has redirected back it clears the data entered in the
> form's textfield and combo selections. Is there a simple way of
> mainting the user's text/selections after the form has been
> redirected?

Use session variables, but do so carefully.

--
Bone Ur
Cavemen have formidable pheromones.

Re: Keeping form elements in place after redirect

Gazing into my crystal ball I observed Chris @googlemail.com> writing in news:d195e1c1-60d0-426f-8b7c-e56c0f6b4881
@c30g2000hsa.googlegroups.com:

> I have a form that is processed by a php page and then redirected by
> the same php page back to the form page again.
>
> After the page has redirected back it clears the data entered in the
> form's textfield and combo selections. Is there a simple way of
> mainting the user's text/selections after the form has been
> redirected?
>
> Cheers,
>
> Chris

Is the form posting to itself? If it is, you _should_ have those values
already available, and just show them. If not, then you are going to
have to put those values into a querystring or session variables, and
read them that way. A form posting to itself, and not _redirecting_ to
itself is a lot easier.


--
Adrienne Boswell at Home
Arbpen Web Site Design Services
http://www.cavalcade-of-coding.info
Please respond to the group so others can share

Re: Keeping form elements in place after redirect

Adrienne Boswell wrote:

> .. A form posting to itself, and not _redirecting_ to itself is a lot
> easier.

Absolutely.

Re: Keeping form elements in place after redirect

"Beauregard T. Shagnasty" wrote:
news:3Nh1j.133290$kj1.99640@bgtnsc04-news.ops.worldnet.att.n et:

> Adrienne Boswell wrote:
>
>> .. A form posting to itself, and not _redirecting_ to itself is a lot
>> easier.
>
> Absolutely.
>
>

$_SERVER['SCRIPT_NAME'] would be a better option over $_SERVER['PHP_SELF']

--
BootNic Thursday November 22, 2007 11:22 AM
Don't worry about people stealing an idea. If it's original, you will
have to ram it down their throats.
*Howard Aiken*

Re: Keeping form elements in place after redirect

BootNic wrote:

> "Beauregard T. Shagnasty" wrote:
>>
>
> $_SERVER['SCRIPT_NAME'] would be a better option over $_SERVER['PHP_SELF']

I see they return identical results. Is there a reason you think
SCRIPT_NAME is better? I'm willing to listen, though I've been using
PHP_SELF for many years.

http://us3.php.net/reserved.variables

'PHP_SELF'
The filename of the currently executing script, relative to the document
root. For instance, $_SERVER['PHP_SELF'] in a script at the address
http://example.com/test.php/foo.bar would be /test.php/foo.bar. The
__FILE__ constant contains the full path and filename of the current
(i.e. included) file.

'SCRIPT_NAME'
Contains the current script's path. This is useful for pages which need
to point to themselves. The __FILE__ constant contains the full path and
filename of the current (i.e. included) file.

--
-bts
-Motorcycles defy gravity; cars just suck

Re: Keeping form elements in place after redirect

Beauregard T. Shagnasty wrote:
> BootNic wrote:
>
>> "Beauregard T. Shagnasty" wrote:
>>>
>> $_SERVER['SCRIPT_NAME'] would be a better option over $_SERVER['PHP_SELF']
>
> I see they return identical results. Is there a reason you think
> SCRIPT_NAME is better? I'm willing to listen, though I've been using
> PHP_SELF for many years.
>
> http://us3.php.net/reserved.variables
>
> 'PHP_SELF'
> The filename of the currently executing script, relative to the document
> root. For instance, $_SERVER['PHP_SELF'] in a script at the address
> http://example.com/test.php/foo.bar would be /test.php/foo.bar. The
> __FILE__ constant contains the full path and filename of the current
> (i.e. included) file.
>
> 'SCRIPT_NAME'
> Contains the current script's path. This is useful for pages which need
> to point to themselves. The __FILE__ constant contains the full path and
> filename of the current (i.e. included) file.
>


http://www.google.com/search?hl=en&sa=X&oi=spell&resnum=0&ct =result&cd=1&q=PHP_SELF+xss+vulnerability&spell=1
PHP_SELF xss vulnerability - Google Search

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

Re: Keeping form elements in place after redirect

"Beauregard T. Shagnasty" wrote:
news:TBi1j.41100$if6.20699@bgtnsc05-news.ops.worldnet.att.ne t:

> BootNic wrote:
>
>> "Beauregard T. Shagnasty" wrote:
>>>
>>
>> $_SERVER['SCRIPT_NAME'] would be a better option over
>> $_SERVER['PHP_SELF']
>
> I see they return identical results. Is there a reason you think
> SCRIPT_NAME is better? I'm willing to listen, though I've been using
> PHP_SELF for many years.

They may return the same results under some conditions.

Jonathan has given a link for more information. He has also given an
example in another thread

[url]
http://groups.google.com/group/alt.html/browse_thread/thread /91253a1c3a5844
ff [/url]

[url] http://groups.google.com/group/alt.html/msg/b6e9aebddbae21b3 [/url]

> http://us3.php.net/reserved.variables
>
> 'PHP_SELF'
> The filename of the currently executing script, relative to the
> document root. For instance, $_SERVER['PHP_SELF'] in a script at the
> address http://example.com/test.php/foo.bar would be
> /test.php/foo.bar. The __FILE__ constant contains the full path and
> filename of the current (i.e. included) file.
>
> 'SCRIPT_NAME'
> Contains the current script's path. This is useful for pages which
> need to point to themselves. The __FILE__ constant contains the full
> path and filename of the current (i.e. included) file.

http://example.com/test.php/foo.bar would return
/test.php

--
BootNic Thursday November 22, 2007 1:38 PM
Behind every successful woman...is a basket of dirty laundry.
*Sally Poe*

Re: Keeping form elements in place after redirect

Jonathan N. Little wrote:

> Beauregard T. Shagnasty wrote:
>> BootNic wrote:
>>
>>> "Beauregard T. Shagnasty" wrote:
>>>>
>>> $_SERVER['SCRIPT_NAME'] would be a better option over $_SERVER['PHP_SELF']
>>
>> I see they return identical results. Is there a reason you think
>> SCRIPT_NAME is better? I'm willing to listen, though I've been using
>> PHP_SELF for many years.
>>
>> http://us3.php.net/reserved.variables
>>
>> 'PHP_SELF'
>> The filename of the currently executing script, relative to the document
>> root. For instance, $_SERVER['PHP_SELF'] in a script at the address
>> http://example.com/test.php/foo.bar would be /test.php/foo.bar. The
>> __FILE__ constant contains the full path and filename of the current
>> (i.e. included) file.
>>
>> 'SCRIPT_NAME'
>> Contains the current script's path. This is useful for pages which need
>> to point to themselves. The __FILE__ constant contains the full path and
>> filename of the current (i.e. included) file.
>>
>
> http://www.google.com/search?hl=en&sa=X&oi=spell&resnum=0&ct =result&cd=1&q=PHP_SELF+xss+vulnerability&spell=1
> PHP_SELF xss vulnerability - Google Search

Most of the remarks there seem to refer to Wordpress. Is that the only
place the vulnerability exists?

One page said to append: /">
to your URL. "If you receive a JavaScript popup your template is
vulnerable to this attack." None of my sites return a popup. Should I
worry? (No Wordpress in use.)

--
-bts
-Motorcycles defy gravity; cars just suck

Re: Keeping form elements in place after redirect

BootNic wrote:

> "Beauregard T. Shagnasty" wrote:
>> I see they return identical results. Is there a reason you think
>> SCRIPT_NAME is better? I'm willing to listen, though I've been
>> using PHP_SELF for many years.
>
> They may return the same results under some conditions.
>
> Jonathan has given a link for more information. He has also given an
> example in another thread
>
> [url] http://groups.google.com/group/alt.html/browse_thread/thread /91253a1c3a5844
> ff [/url]
>
> [url] http://groups.google.com/group/alt.html/msg/b6e9aebddbae21b3
> [/url]

Ah yes. I remember that now. Thanks.

--
-bts
-Motorcycles defy gravity; cars just suck

Re: Keeping form elements in place after redirect

Beauregard T. Shagnasty wrote:
> Jonathan N. Little wrote:

>> http://www.google.com/search?hl=en&sa=X&oi=spell&resnum=0&ct =result&cd=1&q=PHP_SELF+xss+vulnerability&spell=1
>> PHP_SELF xss vulnerability - Google Search
>
> Most of the remarks there seem to refer to Wordpress. Is that the only
> place the vulnerability exists?
>
> One page said to append: /">
> to your URL. "If you receive a JavaScript popup your template is
> vulnerable to this attack." None of my sites return a popup. Should I
> worry? (No Wordpress in use.)
>

No, it is PHP specific. But is also depends on the server security
settings and magic-quotes. But if you use SCRIPT_NAME you will only get
the script name and not anything trailing as with PHP_SELF. That way is
some other clever bastard finds away around the escaping of the trailing
bits it would matter because SCRIPT_NAME doesn't parse it...

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com