Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #10320 > unrolled thread

Validate Radio Buttons?

Back to article view | Back to comp.lang.php

Contents

  Validate Radio Buttons? Twayne <nobody@spamcop.net> - 2013-07-31 14:20 -0400
    Re: Validate Radio Buttons? The Natural Philosopher <tnp@invalid.invalid> - 2013-07-31 20:00 +0100
      Re: Validate Radio Buttons? Twayne <nobody@spamcop.net> - 2013-08-01 17:11 -0400
    Re: Validate Radio Buttons? Jerry Stuckle <jstucklex@attglobal.net> - 2013-07-31 15:07 -0400
      Re: Validate Radio Buttons? Denis McMahon <denismfmcmahon@gmail.com> - 2013-07-31 21:37 +0000
        Re: Validate Radio Buttons? Twayne <nobody@spamcop.net> - 2013-08-01 16:47 -0400
          Re: Validate Radio Buttons? Jerry Stuckle <jstucklex@attglobal.net> - 2013-08-01 17:25 -0400
            Re: Validate Radio Buttons? Twayne <nobody@spamcop.net> - 2013-08-01 17:53 -0400
              Re: Validate Radio Buttons? Jerry Stuckle <jstucklex@attglobal.net> - 2013-08-01 19:50 -0400
      Re: Validate Radio Buttons? Twayne <nobody@spamcop.net> - 2013-08-01 17:16 -0400
        Re: Validate Radio Buttons? The Natural Philosopher <tnp@invalid.invalid> - 2013-08-02 00:40 +0100
          Re: Validate Radio Buttons? Jerry Stuckle <jstucklex@attglobal.net> - 2013-08-01 20:09 -0400
          Re: Validate Radio Buttons? Twayne <nobody@spamcop.net> - 2013-08-02 19:42 -0400
            Re: Validate Radio Buttons? Jerry Stuckle <jstucklex@attglobal.net> - 2013-08-02 19:56 -0400
              Re: Validate Radio Buttons? Twayne <nobody@spamcop.net> - 2013-08-04 11:57 -0400
                Re: Validate Radio Buttons? Jerry Stuckle <jstucklex@attglobal.net> - 2013-08-04 22:06 -0400
                  Re: Validate Radio Buttons? Twayne <nobody@spamcop.net> - 2013-08-05 11:17 -0400
                    Re: Validate Radio Buttons? Jerry Stuckle <jstucklex@attglobal.net> - 2013-08-05 11:33 -0400
        Re: Validate Radio Buttons? Jerry Stuckle <jstucklex@attglobal.net> - 2013-08-01 19:53 -0400
          Re: Validate Radio Buttons? Christoph Michael Becker <cmbecker69@arcor.de> - 2013-08-02 03:25 +0200
            Re: Validate Radio Buttons? Jerry Stuckle <jstucklex@attglobal.net> - 2013-08-01 22:10 -0400
              Re: Validate Radio Buttons? Twayne <nobody@spamcop.net> - 2013-08-02 20:06 -0400
                Re: Validate Radio Buttons? Jerry Stuckle <jstucklex@attglobal.net> - 2013-08-02 20:20 -0400
            Re: Validate Radio Buttons? - LiveHTTP headers bill <william@TechServSys.com> - 2013-08-02 08:05 -0400
              Re: Validate Radio Buttons? - LiveHTTP headers The Natural Philosopher <tnp@invalid.invalid> - 2013-08-02 13:21 +0100
              Re: Validate Radio Buttons? - LiveHTTP headers Jerry Stuckle <jstucklex@attglobal.net> - 2013-08-02 08:44 -0400
            Re: Validate Radio Buttons? Twayne <nobody@spamcop.net> - 2013-08-02 19:51 -0400
          Re: Validate Radio Buttons? Twayne <nobody@spamcop.net> - 2013-08-02 19:47 -0400
            Re: Validate Radio Buttons? Jerry Stuckle <jstucklex@attglobal.net> - 2013-08-02 19:54 -0400
        Re: Validate Radio Buttons? Scott Johnson <noonehome@chalupasworld.com> - 2013-08-01 16:54 -0700
          Re: Validate Radio Buttons? Twayne <nobody@spamcop.net> - 2013-08-02 20:10 -0400
            Re: Validate Radio Buttons? Scott Johnson <noonehome@chalupasworld.com> - 2013-08-02 17:21 -0700
    Re: Validate Radio Buttons? RESOLVED Twayne <nobody@spamcop.net> - 2013-08-04 16:17 -0400

Page 2 of 2 — ← Prev page 1 [2]

#10338

On 8/1/2013 9:25 PM, Christoph Michael Becker wrote:
> Jerry Stuckle wrote:
>
>> On 8/1/2013 5:16 PM, Twayne wrote:
>>> On 2013-07-31 3:07 PM, Jerry Stuckle wrote:
>>>> On 7/31/2013 2:20 PM, Twayne wrote:
>>>>> Hi all,
>>>>>
>>>>> I was wondering what the general consensus might be on this:
>>>>>
>>>>> Should one Validate Radio Buttons for an online website contact form?
>>>>>
>>> ...
>>>
>>>>
>>>> Good practice means you ALWAYS validate ALL information from the user.
>>>> You may have a radio button on your form - but there is no guarantee the
>>>> request comes on from your form.
>>>>
>>>> I can easily build a page which has invalid information and submit it to
>>>> your site.  Or even use tools like cURL to feed your site invalid
>>>> information.
>>>>
>>>
>>> Care to share the "how" of doing that, or better yet some code? This
>>> particular form isn't "live" yet or I'd put it somewhere and let you at
>>> it if I didn't have orders to the contrary from on-high :)
>>>      I've done my best but it's obviously not enough or my questions
>>> wouldn't exist.
>
> To better understand potential exploits, you may start with RFC 2616,
> the specification of HTTP/1.1[1].  Then you may go along doing some
> simple telnet sessions, e.g.
>
>    $ telnet example.com 80
>    Trying 93.184.216.119...
>    Connected to example.com.
>    Escape character is '^]'.
>    GET / HTTP/1.1
>    Host: example.com
>
>    HTTP/1.1 200 OK
>    [...]
>
> You may augment your understanding of the HTTP protocol by inspecting
> the HTTP headers that are actually sent and received by a browser (for
> instance, Firefox has Tools->Live HTTP headers).  You may reconstruct
> some requests done from the browser with telnet, where you may change
> some of the header fields, watching the results.  A trivial example:
> create a file test.php and put it in the web root of your localhost:
>

I am *quite* familiar with the HTTP protocol, having worked with it for 
close to 20 years.  But there is no need to get into that level, 
especially with a relative newbie like Twayne.  It only confuses the issue.

A simple page with an HTML form what directs to the page is sufficient 
to show how the page can be exploited.


>    <?php
>
>    echo $_SERVER['HTTP_HOST'];
>
> Then do:
>
>    $ telnet localhost 80
>    Trying 127.0.0.1...
>    Connected to localhost.
>    Escape character is '^]'.
>    GET /test.php HTTP/1.1
>    Host: surprise
>
>    HTTP/1.1 200 OK
>    Date: Fri, 02 Aug 2013 01:13:23 GMT
>    Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7
>    X-Powered-By: PHP/5.4.7
>    Content-Length: 8
>    Content-Type: text/html
>
>    surprise
>
> Finally you may simplify and automate such requests by using cURL[2] or
> the PHP cURL extension[3], for example.
>
>> No problem at all.  I just build a page on my site (or locally if I have
>> a web server installed) and have the form's action= point at the script
>> on your site.  I can place anything I want on the page and it will be
>> sent to your script.
>>
>> There is nothing which requires input to your site to come from a form
>> on your site.  It can come from anywhere - something hackers use to
>> their advantage.
>
> As Twayne is checking the referrer, you'd have to spoof that too.  Of
> course that is no big deal either, but it should be noted.
>
> [1] <http://tools.ietf.org/html/rfc2616>
> [2] <http://curl.haxx.se/>
> [3] <http://php.net/manual/en/book.curl.php>
>

Yes, it is quite simple to check the referrer.  However, that's a poor 
thing to check, because it isn't a required field and may not be set. 
Additionally, some firewalls/security products will strip the 
HTTP_REFERER before sending the data (Norton has been famous for this in 
the past - I don't know if they still do it).

The result is checking HTTP_REFERER will keep out more valid users than 
it will block hackers.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#10351

On 2013-08-01 10:10 PM, Jerry Stuckle wrote:
> On 8/1/2013 9:25 PM, Christoph Michael Becker wrote:
>> Jerry Stuckle wrote:
...
>
> Yes, it is quite simple to check the referrer.  However, that's a poor
> thing to check, because it isn't a required field and may not be set.
> Additionally, some firewalls/security products will strip the
> HTTP_REFERER before sending the data (Norton has been famous for this in
> the past - I don't know if they still do it).

Yup!  No Referrer, no access! Wrong referrer, still no access. Spoof it 
properly or forget it. Along with other checks &k balances along the way 
of course.

>
> The result is checking HTTP_REFERER will keep out more valid users than
> it will block hackers.

That sounds like a bunch of bologna unless you can cite something 
verifiable to support it.
    I have never, in over a decade, seen Referrer ever block anyone and 
I receive host reports of every single contact attempt on my site, 
successful or not. Daily.
    The only reason I don't have anything more cohesive to support my 
claim is that I lost a lot of memory due to a serious brain concussion a 
few years back, necessitating   re-learing a LOT of things, but I still 
have all my records in archive.
    Every contact is and was evaluated to see if I care why a contact 
attempt failed.  Being so near a college town, there are a lot of 
abandoned and unsuccessful access attempts. So far none have succeeded 
although it's been a long trip getting my knowledge back!

So if you can, please cite something to support your claim that it keeps 
out more valid users than bots & hackers & crackers.





>

[toc] | [prev] | [next] | [standalone]

#10353

On 8/2/2013 8:06 PM, Twayne wrote:
> On 2013-08-01 10:10 PM, Jerry Stuckle wrote:
>> On 8/1/2013 9:25 PM, Christoph Michael Becker wrote:
>>> Jerry Stuckle wrote:
> ...
>>
>> Yes, it is quite simple to check the referrer.  However, that's a poor
>> thing to check, because it isn't a required field and may not be set.
>> Additionally, some firewalls/security products will strip the
>> HTTP_REFERER before sending the data (Norton has been famous for this in
>> the past - I don't know if they still do it).
>
> Yup!  No Referrer, no access! Wrong referrer, still no access. Spoof it
> properly or forget it. Along with other checks &k balances along the way
> of course.
>

Then you will lock out a number of valid users.  HTTP_REFERER is not a 
required field, and some firewalls will strip it from the header (Norton 
used to do this).

Plus it is so easy to spoof it isn't even funny.  I don't even need to 
use cURL to do it - I can do it with simple HTML.

>>
>> The result is checking HTTP_REFERER will keep out more valid users than
>> it will block hackers.
>
> That sounds like a bunch of bologna unless you can cite something
> verifiable to support it.

Please see above.

>     I have never, in over a decade, seen Referrer ever block anyone and
> I receive host reports of every single contact attempt on my site,
> successful or not. Daily.

Not that you know of, anyway.  But how do you know it was never blocked?

I've had some sites where the customer wants the referrer tracked.  We 
do, sand sometimes it comes up empty (even on a POST operation).

>     The only reason I don't have anything more cohesive to support my
> claim is that I lost a lot of memory due to a serious brain concussion a
> few years back, necessitating   re-learing a LOT of things, but I still
> have all my records in archive.

Which does not mean it does not occur.

>     Every contact is and was evaluated to see if I care why a contact
> attempt failed.  Being so near a college town, there are a lot of
> abandoned and unsuccessful access attempts. So far none have succeeded
> although it's been a long trip getting my knowledge back!
>

And you don't know how many spoofed entries there are, either.

> So if you can, please cite something to support your claim that it keeps
> out more valid users than bots & hackers & crackers.
>
>

See above.  HTTP_REFERER is NOT to be trusted.

Or google for it and see what else you find.

However, this is also off-topic in a PHP newsgroup.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#10340 — Re: Validate Radio Buttons? - LiveHTTP headers

On 8/1/2013 9:25 PM, Christoph Michael Becker wrote:
> You may augment your understanding of the HTTP protocol by inspecting
> the HTTP headers that are actually sent and received by a browser (for
> instance, Firefox has Tools->Live HTTP headers).

I am running Firefox 22.0.

alt->tools does not have live HPPT headers in the pull down.

activating the menu bar: tools goes to the same place.

where do you find live http headers ?

thanks in advance

bill

[toc] | [prev] | [next] | [standalone]

#10341 — Re: Validate Radio Buttons? - LiveHTTP headers

On 02/08/13 13:05, bill wrote:
> On 8/1/2013 9:25 PM, Christoph Michael Becker wrote:
>> You may augment your understanding of the HTTP protocol by inspecting
>> the HTTP headers that are actually sent and received by a browser (for
>> instance, Firefox has Tools->Live HTTP headers).
>
> I am running Firefox 22.0.
>
> alt->tools does not have live HPPT headers in the pull down.
>
> activating the menu bar: tools goes to the same place.
>
> where do you find live http headers ?
>
> thanks in advance
>
> bill
the most convenient tool I have found is 'curl'

curl -I [url] will show what the remote server is sending.

For firefox there exists an addon

https://addons.mozilla.org/en-US/firefox/addon/live-http-headers/

-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#10342 — Re: Validate Radio Buttons? - LiveHTTP headers

On 8/2/2013 8:05 AM, bill wrote:
> On 8/1/2013 9:25 PM, Christoph Michael Becker wrote:
>> You may augment your understanding of the HTTP protocol by inspecting
>> the HTTP headers that are actually sent and received by a browser (for
>> instance, Firefox has Tools->Live HTTP headers).
>
> I am running Firefox 22.0.
>
> alt->tools does not have live HPPT headers in the pull down.
>
> activating the menu bar: tools goes to the same place.
>
> where do you find live http headers ?
>
> thanks in advance
>
> bill

It's an extension to FF you have to add on.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#10348

On 2013-08-01 9:25 PM, Christoph Michael Becker wrote:
> Jerry Stuckle wrote:
>
>> On 8/1/2013 5:16 PM, Twayne wrote:
>>> On 2013-07-31 3:07 PM, Jerry Stuckle wrote:
>>>> On 7/31/2013 2:20 PM, Twayne wrote:
>>>>> Hi all,
>>>>>
>>>>> I was wondering what the general consensus might be on this:
>>>>>
>>>>> Should one Validate Radio Buttons for an online website contact form?
>>>>>
>>> ...

...

>
> To better understand potential exploits, you may start with RFC 2616,
> the specification of HTTP/1.1[1].  Then you may go along doing some
> simple telnet sessions, e.g.
>
>    $ telnet example.com 80
>    Trying 93.184.216.119...
>    Connected to example.com.
>    Escape character is '^]'.
>    GET / HTTP/1.1
>    Host: example.com
>
>    HTTP/1.1 200 OK
>    [...]
>
> You may augment your understanding of the HTTP protocol by inspecting
> the HTTP headers that are actually sent and received by a browser (for
> instance, Firefox has Tools->Live HTTP headers).  You may reconstruct
> some requests done from the browser with telnet, where you may change
> some of the header fields, watching the results.  A trivial example:
> create a file test.php and put it in the web root of your localhost:
>
>    <?php
>
>    echo $_SERVER['HTTP_HOST'];
>
> Then do:
>
>    $ telnet localhost 80
>    Trying 127.0.0.1...
>    Connected to localhost.
>    Escape character is '^]'.
>    GET /test.php HTTP/1.1
>    Host: surprise
>
>    HTTP/1.1 200 OK
>    Date: Fri, 02 Aug 2013 01:13:23 GMT
>    Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7
>    X-Powered-By: PHP/5.4.7
>    Content-Length: 8
>    Content-Type: text/html
>
>    surprise
>
> Finally you may simplify and automate such requests by using cURL[2] or
> the PHP cURL extension[3], for example.
>
>> No problem at all.  I just build a page on my site (or locally if I have
>> a web server installed) and have the form's action= point at the script
>> on your site.  I can place anything I want on the page and it will be
>> sent to your script.
>>
>> There is nothing which requires input to your site to come from a form
>> on your site.  It can come from anywhere - something hackers use to
>> their advantage.
>
> As Twayne is checking the referrer, you'd have to spoof that too.  Of
> course that is no big deal either, but it should be noted.
>
> [1] <http://tools.ietf.org/html/rfc2616>
> [2] <http://curl.haxx.se/>
> [3] <http://php.net/manual/en/book.curl.php>
>


Hmm, good post Chris!  I'll see where that takes me.

Thanks

[toc] | [prev] | [next] | [standalone]

#10347

On 2013-08-01 7:53 PM, Jerry Stuckle wrote:
> On 8/1/2013 5:16 PM, Twayne wrote:
>> On 2013-07-31 3:07 PM, Jerry Stuckle wrote:
>>> On 7/31/2013 2:20 PM, Twayne wrote:
>>>> Hi all,
>>>>
>>>> I was wondering what the general consensus might be on this:
>>>>
>>>> Should one Validate Radio Buttons for an online website contact form?

...

>
> No problem at all.  I just build a page on my site (or locally if I have
> a web server installed) and have the form's action= point at the script
> on your site.  I can place anything I want on the page and it will be
> sent to your script.
>
> There is nothing which requires input to your site to come from a form
> on your site.  It can come from anywhere - something hackers use to
> their advantage.
>

Nah, you'd have to do a more than that. That much I can test for myself.

[toc] | [prev] | [next] | [standalone]

#10349

On 8/2/2013 7:47 PM, Twayne wrote:
> On 2013-08-01 7:53 PM, Jerry Stuckle wrote:
>> On 8/1/2013 5:16 PM, Twayne wrote:
>>> On 2013-07-31 3:07 PM, Jerry Stuckle wrote:
>>>> On 7/31/2013 2:20 PM, Twayne wrote:
>>>>> Hi all,
>>>>>
>>>>> I was wondering what the general consensus might be on this:
>>>>>
>>>>> Should one Validate Radio Buttons for an online website contact form?
>
> ...
>
>>
>> No problem at all.  I just build a page on my site (or locally if I have
>> a web server installed) and have the form's action= point at the script
>> on your site.  I can place anything I want on the page and it will be
>> sent to your script.
>>
>> There is nothing which requires input to your site to come from a form
>> on your site.  It can come from anywhere - something hackers use to
>> their advantage.
>>
>
> Nah, you'd have to do a more than that. That much I can test for myself.
>
>
>
>

What more do you want?  I described exactly how an HTML page (no PHP at 
all) could be built which can cause you a problem.

If you want the HTML to do it, try alt.html.  That would be off-topic in 
this newsgroup.

And BTW - HTTP_REFERER is another user-supplied field, and cannot be 
trusted.  It may easily be spoofed or could be absent.  It is not to be 
trusted.



-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#10335

On 8/1/2013 2:16 PM, Twayne wrote:
> On 2013-07-31 3:07 PM, Jerry Stuckle wrote:
>> On 7/31/2013 2:20 PM, Twayne wrote:
>>> Hi all,
>>>
>>> I was wondering what the general consensus might be on this:
>>>
>>> Should one Validate Radio Buttons for an online website contact form?
>>>
> ...
>
>>
>> Good practice means you ALWAYS validate ALL information from the user.
>> You may have a radio button on your form - but there is no guarantee the
>> request comes on from your form.
>>
>> I can easily build a page which has invalid information and submit it to
>> your site.  Or even use tools like cURL to feed your site invalid
>> information.
>>
>
> Care to share the "how" of doing that, or better yet some code? This
> particular form isn't "live" yet or I'd put it somewhere and let you at
> it if I didn't have orders to the contrary from on-high :)
>     I've done my best but it's obviously not enough or my questions
> wouldn't exist.
>
> Regards,
>
> Twayne`

Wasn't the point Jerry was making is that you 'should' validate anything 
coming from the public?  Does not mean you have to.

Not sure the need to challenge his ability to corrupt your form since I 
think it is well known that a form can be spoofed.....or maybe not well 
known.

I think the premise is that you can ignore the need to validate your 
data but you cannot ignore the consequences of not validating your data.

Just saying. :)

Scotty

[toc] | [prev] | [next] | [standalone]

#10352

On 2013-08-01 7:54 PM, Scott Johnson wrote:
> On 8/1/2013 2:16 PM, Twayne wrote:
>> On 2013-07-31 3:07 PM, Jerry Stuckle wrote:
>>> On 7/31/2013 2:20 PM, Twayne wrote:
>>>> Hi all,
>>>>
>>>> I was wondering what the general consensus might be on this:
>>>>
>>>> Should one Validate Radio Buttons for an online website contact form?
>>>>
>> ...
>>
>>>
>>> Good practice means you ALWAYS validate ALL information from the user.
>>> You may have a radio button on your form - but there is no guarantee the
>>> request comes on from your form.
>>>
>>> I can easily build a page which has invalid information and submit it to
>>> your site.  Or even use tools like cURL to feed your site invalid
>>> information.
>>>
>>
>> Care to share the "how" of doing that, or better yet some code? This
>> particular form isn't "live" yet or I'd put it somewhere and let you at
>> it if I didn't have orders to the contrary from on-high :)
>>     I've done my best but it's obviously not enough or my questions
>> wouldn't exist.
>>
>> Regards,
>>
>> Twayne`
>
> Wasn't the point Jerry was making is that you 'should' validate anything
> coming from the public?  Does not mean you have to.

Agreed, no problem there.
>
> Not sure the need to challenge his ability to corrupt your form since I
> think it is well known that a form can be spoofed.....or maybe not well
> known.

What challenging his ability?  That was a valid, meaningful question. 
He said "that" and I asked for clarification and further information.

Just read, don't try to see between the lines.

>
> I think the premise is that you can ignore the need to validate your
> data but you cannot ignore the consequences of not validating your data.
>
> Just saying. :)
>
> Scotty

[toc] | [prev] | [next] | [standalone]

#10354

On 8/2/2013 5:10 PM, Twayne wrote:
> On 2013-08-01 7:54 PM, Scott Johnson wrote:
>> On 8/1/2013 2:16 PM, Twayne wrote:
>>> On 2013-07-31 3:07 PM, Jerry Stuckle wrote:
>>>> On 7/31/2013 2:20 PM, Twayne wrote:
>>>>> Hi all,
>>>>>
>>>>> I was wondering what the general consensus might be on this:
>>>>>
>>>>> Should one Validate Radio Buttons for an online website contact form?
>>>>>
>>> ...
>>>
>>>>
>>>> Good practice means you ALWAYS validate ALL information from the user.
>>>> You may have a radio button on your form - but there is no guarantee
>>>> the
>>>> request comes on from your form.
>>>>
>>>> I can easily build a page which has invalid information and submit
>>>> it to
>>>> your site.  Or even use tools like cURL to feed your site invalid
>>>> information.
>>>>
>>>
>>> Care to share the "how" of doing that, or better yet some code? This
>>> particular form isn't "live" yet or I'd put it somewhere and let you at
>>> it if I didn't have orders to the contrary from on-high :)
>>>     I've done my best but it's obviously not enough or my questions
>>> wouldn't exist.
>>>
>>> Regards,
>>>
>>> Twayne`
>>
>> Wasn't the point Jerry was making is that you 'should' validate anything
>> coming from the public?  Does not mean you have to.
>
> Agreed, no problem there.
>>
>> Not sure the need to challenge his ability to corrupt your form since I
>> think it is well known that a form can be spoofed.....or maybe not well
>> known.
>
> What challenging his ability?  That was a valid, meaningful question. He
> said "that" and I asked for clarification and further information.
>
> Just read, don't try to see between the lines.
>

Point taken.  I guess this NG usually develops into some serious mud 
slinging I misread from that you actually wanted to see some code that 
would do it to challenging if it could be done.

Sorry

Scotty

[toc] | [prev] | [next] | [standalone]

#10397 — Re: Validate Radio Buttons? RESOLVED

On 2013-07-31 2:20 PM, Twayne wrote:
> Hi all,
>
> I was wondering what the general consensus might be on this:
>
> Should one Validate Radio Buttons for an online website contact form?
>
> I've always thought they needed nothing but validation to see if they'd
> been used or not before accepting them, and sending the user back to the
> website Home Page.

>
> TIA & Regards,
>
> Twayne`

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.php

csiph-web