NYCPHP Meetup

[Kenneth Downs]

Anirudh Zala wrote:
> On Fri, 15 Sep 2006 20:55:34 +0530, Keith Casey  
> <mailinglists at caseysoftware.com> wrote:
>
>   
>> On 9/15/06, Anirudh Zala <arzala at gmail.com> wrote:
>>     
>>> 1) The biggest area of this problem is browser. Not because that it is
>>> being exploited in many ways but why can't browser itself provide basic
>>> level of validation and input filtering like validations of name, email
>>> address, phone, fax, mobile etc. according to country or region.
>>>       
>> With all due respect, this is a terrible idea.
>>
>> While this validation *might* work for an incredibly small segment of
>> information - like address as you rightly note - it pushes a huge
>> burden onto the browser and then the webapp still needs to do it
>> anyway.  *Nothing* that comes from a user (or anything they have
>> access to edit) can be trusted.  Period.  End of story.
>>     
>
> This is good point "Nothing can be trusted." This is similar like  
> validating client data using JS. But from client point of view, can't  
> browser help bit to filter input directly from there and ask client to  
> make necessary corrections? I am not just thinking in terms of Security  
> only. But overall view says that such implementations can benefit clients  
> as well and then at application level we can at least be relieved about  
> format of data (which is 1st level of security checks).
>
>   
This is good design.  The browser can be used to improve the user 
experience by rejecting things that it knows the server will reject.  
This gives the honest users a better experience.

The server still must do the final validation, however, because of the 
dishonest users, or because of mistakes in js code.

...and of course when I say server I mean database server.

There are also some validations the browser cannot easily do.  Lookup 
validations are particularly bad, but format validations like checking 
for an "@" in an email are much easier.

If I were king, I would decree that browsers should allow pages to cache 
state information from page-to-page.  This information could take the 
form of complete lookup tables out of a database, complete with 
expiration times and so forth.  Of course the browser is in control of 
how much space it will allocate (unless MS writes it), and the app must 
be able to run w/o the local cache if the browser refuses to allocate 
space, but it would be really cool.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20060920/4e4fd4ea/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ken.vcf
Type: text/x-vcard
Size: 261 bytes
Desc: not available
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20060920/4e4fd4ea/attachment.vcf>