[Javascript] Where to learn JS best practices & style

[David T. Lovering]

  I too am familiar with POST mechanisms for form data transfer.  My
understanding (which by all rights may be imperfect) is that the GET forms
submission DOES append the response parameters directly to the URL (as in
?monkeyname=jabel&address=541%20South%20Wainwright%20Street), and that the
POST ships the stuff back to the server in a separate message body.  Admittedly,
the latter is more secure.

  However, just so we are on the same wavelength -- the message body (unless
shipped under HTTPS, IPSec, or something similar) is STILL in plaintext, and
STILL may be sucked out of channel by someone with a sniffer or other network
analyzer.  No decoding necessary.  

  I agree, shipping sensitive stuff from a form by any means other than an
SSL-driven POST transfer is a no-no of the first water.  However, a lot of 
folks that you would think would know better still do it that way -- including
M$oft.  [The default ASP form handler structure is based on a GET, or was the
last time I looked].

  And let us not forget PUT and DELETE...

  -- Dave Lovering

Rodney Myers wrote:
> 
> 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
> 
> _______________________________________________
> Javascript mailing list
> Javascript at LaTech.edu
> https://lists.LaTech.edu/mailman/listinfo/javascript