[Javascript] Where to learn JS best practices & style

[Rodney Myers]

David,

Your posts are appreciated, not least by me.

However, I would add a comment on your remark
"ALL CGI/BIN information is exchanged as part of the URL declaration"

This is the default form method   Method="Get" and can be occasionally 
useful if submitting to another page using only javascript since the 
result can be parsed from window.location.search

Secure it is not, so I fully agree there.

There is an alternative which is Method="Post" as in <FORM METHOD="POST" 
....
This does not put data in the URL but (I gather from clever people who 
understand what this means) in the http header.

As far as PHP scripts are concerned it makes no difference whatever
$myinput is picked up whether <input name="myinput"> is sent POST or GET

For ASP and Perl there are separate "collections" to access for the two 
methods.

When using https one generally uses POST.

Whatever restriction a browser may (or may not!) place on a URL 
"get-string" or "query-string" or "search component" in th URL there is 
no such restriction in data sent by method POST.

In my own work with the Javascript based shopping system "Shop at ssistant" 
I am generally  using forms to gather data into js data objects.
Then finally data is sent by method post to  a forms to email or forms 
to database script and (very often also) to the script of the chosen 
payment service provider. (PSP).

I would never ever collect credit card information in http mode. We send 
name address and order information to the PSP's secure script and allow 
them to take the card data in secure mode. A good PSP will not store any 
card data "in clear" on its server.

hth

Rodney


David T. Lovering wrote:

>However, CGI/BIN (and ASP and all things Microsoftian) have started to smell a bit in this
>era of heightened security awareness.  The reason is that ALL CGI/BIN information is exchanged
>as part of the URL declaration -- the stuff you see in the little window at the top of your
>browser.  For example, if you hit the 'submit' button on most forms, you'll see this window
>suddenly fill with lots of gobblety-gook following after your original 'naked' URL.  Most 
>forms do not encrypt this data (the CPU burden on the server side would tend to be prohibitive),
>so anyone with a network sniffer could suck your form data out of the ether and parse it for
>such delightful bits as your credit card info, your home telephone address, etc. etc.
>
>For complicated forms this string can grow to astonishing lengths -- and most browsers put some
>sort of cap on how long they can be.  Scuttlebutt has it that IE6.X generally limits this to
>2K characters, but I'm still awaiting confirmation of this.
>
>HOWEVER (!!!) by judicious use of dereferencing child windows, using embedded SSL streams, and
>server-to-client pipes, almost all of the CGI/BIN dialogue becomes unnecessary, thereby giving
>our sniffer friends considerably less to look at.  I still recommend that whenever you are 
>dealing with privacy-act sensitive data you use SSL (i.e; HTTPS), and use a software-generated
>one-time passkey/certificate exchange to authenticate it.  
>
>The other thing that bugs me no end is the default assumption on forms that hitting 'carriage
>return' (enter) is equivalent to 'submit this form'.  Since this is counter to the user tendency
>to regard enter as little more than the completion of a current field, it can cause all sorts
>of problems.  
>
This is a bug/feature which no good developer should rely on.
It applies only to forms with single text inputs.

>The best way to deal with this is to nuke entirely the built-in form 'submit'
>function (sorry Rod), and redirect it by way of a separate stand-alone function:
>  
>
No worries! Good advice.


R

-- 
PS. I have just bought a licence for Mike Chen's
BizAutomator. If you have to answer routine 
email queries from your sites or mailings then
you need this as much as I do. 
http://www.BizAutomator.com/rlbm51 

Rodney