WebFund 2024F Lecture 6

From Soma-notes
Revision as of 17:32, 26 September 2024 by Soma (talk | contribs) (Created page with "==Video== Video from the lecture for September 26, 2024 is now available: (NOT YET) * [https://homeostasis.scs.carleton.ca/~soma/webfund-2024f/lectures/comp2406-2024f-lec06-20240926.m4v video] * [https://homeostasis.scs.carleton.ca/~soma/webfund-2024f/lectures/comp2406-2024f-lec06-20240926.cc.vtt auto-generated captions] ==Notes== <pre> Lecture 6 --------- * Assignment 1 is based on simpleserver2.js, which is a simplified version of formdemo.js * Assignment 1 will b...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Video

Video from the lecture for September 26, 2024 is now available: (NOT YET)

Notes

Lecture 6
---------

* Assignment 1 is based on simpleserver2.js, which is a simplified version of formdemo.js

* Assignment 1 will be due on Oct. 4th at earliest. Code is online, questions should be up in the next day.

* The assignment will be a mix of explaining and writing code based on simpleserver2.js, as well as explaining how you came up with your answers.

* your assignment answers will be a text file following a supplied template
  - a script will split up your submissions by questions so TAs can grade specific questions rather than entire assignments


When a browser makes an HTTP request, it generally uses one of two types of requests:
 - GET to get content
 - POST to submit information to the server

Now, it is often possible to do POST-like things with GET, but you shouldn't
 - GET is assumed to be safe to call multiple times (it is idempotent)
 - POST is assumed to NOT be safe, so repeated form submissions won't happen without alerting the user

In an HTML form
 - <form> encloses the form
 - <input> labels each input widget
 - <label> is the label for the input widget
 - name= sets the key used to identify values sent to the server
 - type= sets the type of input widget used to get user data
    - some widgets do input validation/constraints
    - SERVER can never trust that the client did its job,
      must validate data on its own
    - so you should validate on the client (for a better user experience)
      and on the server (for security/integrity/proper functionality, etc)
 - to submit the form, there is normally a button of type "submit"
    - submits all data in the form

When we say input validation, we can mean a lot of things
 - for a date, make sure it is a valid date (e.g., month is between 1 and 12)
 - but can also include other constraints, such as a credit card expiration date should be in the future, not the past
 - sometimes types can be used for validation, but type-based validation is almost always partial, there are other constraints

input validation is HARD, give it respect
 - most application bugs and security issues arise from insufficient input validation

If you take user input on one page and show it to other users without proper input validation/escaping, your app becomes vulnerable to cross-site scripting attacks
 - name isn't quite accurate
 - just means attacker injects code into web app that isn't run on the server,
   but is instead run on the client (but a victim user's browser, not the attacker's browser)