 Folks, it's been a while. Good to see you all again. Let's see. Oh, midterms are graded. You'll be getting your scores back later today over email. They're actually pretty good. I was impressed. The high was a 97, so everyone's score will be modulated divided by 97 instead of 100. So you got some extra points for that. Let's see. I don't know. The mean was like a 78, 79, and the median was like 82 or 83. So I was actually very impressed with how you all did on that. So good job. And then if you want to see your mentor, you'll need to make an appointment with the TA. So we're not actually handing them back. So you'll get your score back with the breakdown. But if you want to see exactly did wrong, you'll need to make an appointment with the TA or go to your office about it. All right. My project teams. And let's get going on THB. So to refresh our memory, since I know it's been a while, what we're looking at here is all of the amazing language features of PHP that actually make developing a website easier but have weird unintended security consequences than problems. So there is a setting in PHP called Allow URL Include. So what does an include do in PHP? Somebody tell us. Yes, so it takes another file, it reads from it, it copies it, and pastes it right into the code and whatever code was there. So Allow URL Include is an option that allows you to use HTTP or FTP to do our eyes in your includes. Why would this be cool? Photo, photo, you'd use an image tag and you'd set the href to be somewhere else. What else, yeah? You have the parameter, possibility of code if it's gathered. Yeah, it's actually a super cool way of like having a code repo of all these different PHP snippets that you can include and use, right? But from a security perspective, this is insane because if somebody can inject into an include, and if you're including something based on untrusted user input, now I can go pull code from my server and run it on your server. It needs to have this Allow URL FOpen setting also. This also allows you to call, so FOpen is basically PHP's open function of how to open and read a file. So this allows you to use URLs in that FOpen call. And so the remote file will be fetched first and executed, which is insane. Other cool things about PHP are super global. So the idea is this dollar sign, so PHP, all variables start with dollar sign. This dollar sign underscore server is a specific PHP variable that is global to all functions, all, sorry, all PHP code, and that is based on the HTTP request. And so you look at this server, it has a request method, so this looks like the HTTP request method here if it's a get or post. So you're seeing here is checking whether it's a post or not. It's using dollar sign underscore post, which looks for any query parameters that were passed via the post method and all this stuff. So superglobals are also, when you're coding, a very nice language feature to have. The other interesting thing that PHP has is variable variables. Seems kind of ridiculous, right? It's a fun thing to say actually, but what do I mean by variable variables? Well, I can write some PHP code that defines a variable A as the string hello. Super straightforward, you could write this in any language. We can then set dollar sign, dollar sign A equal to world. So what is this doing, do you think? What variable name is being set to the string world? Yeah, dollar sign hello. So now I can echo dollar sign A and then dollar sign hello using this great string substitution syntax. And I can echo dollar sign A and then dollar sign curly braces to specify what dollar sign A is. This is another variable variable. So this will output hello world twice. So with variable variables, you're able to dynamically set a variable's name based on a variable value. This is insanity. You should never code like this. If you're thinking, I know, I'll use these variable variables, you're probably doing something wrong. So take a step back, reevaluate things, and then go forward, because if you think it's hard to understand what these four lines do, imagine if you had a big program that was using this all over the place, it would just be insane to try to figure out what's going on. Another language feature that PHP had was a functionality called register globals. And the idea was, hey, we'll register all environment, get parameters, post parameters, cookie values, and server variables as global variables. So essentially what PHP would do is automatically inject variable names into your script based on the input from the HTTP request. So it would look at all of the key value pairs of the parameters in the HTTP request, and it would create a variable with the name of the name parameter and set its value equal to the value. It was actually the default for a long time until 4.2, and you can still turn this on. So how does this look like? You'd have some PHP code that says if dollar sign name and dollar sign comment, then file is fopen, use your feedback, write out to the file, name the comment, and close the file, and then say, hey, feedback submitted. So this actually, when you're looking at this, it's a very simple way to program, right? Because with these register globals, when I submit this form, so where is this form going to post? What URI is this gonna hit? Itself, the current page, wherever it is, right? And it's gonna pass as the name name whatever you put in the name input box, and as the name comment, whatever you put as the comment input box. So now PHP, when you input this, well then, automatically create these variables of name and comment with these values, which is very handy for coding. Pretty much not handy though. Well, we'll talk about it later as to when this can cause problems. So this is another thing that makes it difficult to actually understand and analyze PHP code, but on the other hand, it makes it easy to write web applications. Press course in PHP. So, we talked about web applications need state. Why do they need state? HTTP is stateless, and they wanna be real applications, right? They're like Pinocchio. They wanna be real apps, right? So they need to store this state somewhere. Where could you store the state? Super global. Super global would not work because that's only for the execution of one script, right? So cookies will store values on the client, and they'll get sent back to you when the client returns, makes a subsequent request. You can store things in cookies, what else? Database, what else? Session and session. What's the difference between session and cookie? This is session stored. The tricky answer is it depends on the exact thing you're talking about. So for PHP, in web applications in general, session, cookie, not really a huge distinction, although when we use it, we're usually thinking of cookie as a value we store on a server, and session is some session information that's stored to that cookie. So that cookie will index into some session table, and that will hold all the value there. So actually PHP stores your session data as a file on the server. Okay, so where else can we store things? Is this the only things? Hidden elements. What was that? Hidden elements. Hidden elements, we can store it in the hidden elements, what else? Yeah, it's somewhere there. Files, we can store it on files on the operating system, right? We can just create files, right? But fundamentally this needs to be stored somewhere, right? We need to store persistence, state, otherwise we're not really a real application because we can only ask the clients to store a very limited amount of information. So you can store it in memory actually, so Java actually is running as a process, so all the requests are threads, so it actually has global variables that will persist. The file system, databases, but databases are essentially the main way that we think about storing data and storing state in a web application. Some pros are, from using database, we get assets and compliance, so what does that mean? What does it mean as a high level? Yeah, so we get atomic consistent, is that integrity? What does D stand for? I actually don't remember. Durability, there we go, yeah. So this means that what we write to our database will function as we assume, right? As we write things to the database, if we read it back later, we will read back the data that we just wrote. It has whole types of things about concurrency and all that stuff, but we get awesome features here, we get concurrency, we get this great separation of concern where the database, where the web app doesn't care how the data is stored. All it knows is it wants to store some data in the database, and the database can handle all that database asset stuff. We can also run the database on another server so we can actually physically separate the apps. The cons are it's more complicated to build than deploy, right? Now you have to have not only this PHP server, but now you have to have a database server as well. And it's gonna add another language that we have to understand in order to really understand the modern web and that's SQL. So you need to know at a bare minimum to do web application programming, you need to understand HTTP, URIs, HTML, SQL, and one kind of server-side programming language, probably PHP would be mine. So the LAMP stack kind of evolved as a classic web application model. We're running Linux, Apache, MySQL, and PHP. So it's kind of this nice way of thinking about a web application. And it's cool because you're gonna swap out, you don't like Apache, great, run Nginx. If you don't like Linux, you can run out of Windows and now there's WAMP servers, you can just download and run. If you don't like PHP, you can run something else, all this kind of stuff can be tweaked. So MySQL is currently the second most used open source relational database. Anybody know the first? Postgres? Ha ha, Postgres. That was a lot of wishful thinking, right? Postgres fans. Postgres is, I think, number three. Definitely not. Oracle would love, well, also I said open source, so definitely rules out Oracle. I don't know if Oracle's usage numbers, I would definitely claim that Oracle's usage numbers are nowhere near this number one. SQLite, why SQLite? I guess it's being used on your phone. Yes, SQLite. So SQLite is essentially an in-memory SQL database that is very fast performance, small footprint, and it's used on essentially, I think, everyone's phone. So if you're running an iOS device or an Android device, which is essentially everyone who's not running a Windows phone, is anybody running a Windows phone? My brother was for like two or three years, and that's really weird. He liked it a lot. So yes, so SQLite is the most used database because of phone devices. MySQL was first released in 1995. Actually, very weird that it was the same day that Sun released the first version of Java, which is weird. Why is this weird? Who owns my SQL now? So Sun eventually purchased my SQL, so that's super weird, for a billion dollars in January 2008. It's pretty good for an open source company, right? Yeah, a billion dollars is cool. OK, so SQL, so Crash Course in SQL, is a structured query language. The idea is it's a special purpose language in order to interact with the database, yes. You offer the people who make it a lot of money. So my SQL was always licensed, had a dual license. So there was an open source version, which I think they called the Community Edition, and then there was a closed source proprietary version. And so that had some plug, actually don't even know what the, exactly what the closed source version did or added, usually it's some kind of plug-ins or other kind of features that you wouldn't get. It basically also will probably give you support. And so if you think about an organization, this is why a lot of companies don't like using open source software, because when it breaks there's nobody they can yell at to get it fixed, right? But if you're paying somebody, if I'm paying you a support contract, it's literally in the contract that you'll fix the bugs that I have. So that gives them peace of mind that they can use your database and they can have somebody to yell at if things break. What if worth a billion dollars you're not paying? That's not my decision. The only thing we can say is it was because some bought them for that much money, right? So SQL, there are multiple types of commands and I should probably preface this. Have people taken database classes before? Okay, good. So that should be a very rough overview. You'll notice I don't talk about it in terms of tuples and all the formal database because I've always used the database as a dumb storage repo. So here, take all my stuff, take all my data and then get it back out. So that's kind of the way we'll look at it because honestly that's what a lot of web applications do. Multiple things you can do with the database. You can get data from the database using a select command. You can update data that is currently in the database. You can insert things into the database and you can delete things from the database. And one interesting quirk is that while SQL itself is a standard language, every implementation has its own dialect. So MySQL has a slightly different dialect than Postgres which has a slightly different dialect than MSSQL which is Microsoft's version which is probably different than Oracle's version. So this is a super simple query, select star. So get every column from the user's table where the username is added. So you can have clauses that limit the results you're getting back. You can do complicated kind of queries. You can do different types of ordering. So this would get all the books where the price is greater than some amount. You can have nested some queries which is pretty cool. So you can say, so this query would execute first and would get the average price of the book. So you're basically saying, hey, give me all the books that are less than the average price of all the other books. You can insert creating new entries into the table. So this would insert into table example with these columns, field one, field two, field three with these values. Updating things with update columns based on the where clause of your query. And you can do super crazy. This one will actually break down. So union is one that's gonna be really important to us that we'll talk about. So the idea is when you wanna get results from two different tables and join them as if they were one result. All they join is a loaded word of what I just said. So the idea is we're gonna select A from table one where A is 10 and B is one. That's a bad example. Yeah, so we're getting these, both of these queries and they will both be returned to us as if they were one thing. That's kind of the only important thing here. But we're selecting from two different tables. So you can think about the first results are gonna happen and then appended to that will be all the results from the second queries. That's kind of the way to think about a union. And P and P and MySQL go together very nicely, which would make sense. You have this lamp stack. So the idea is you make a connection to the database. You're connecting to this IP address with this username and this password. Your password should not probably be MySQL underscore password. Probably not. If you can't connect, you die. This means you print out this error message and stop executing. You select database example. So to say, hey, I want to query the example database with MySQL exam multiple databases. You can then, so this is printing out a query. So selecting first name, last name, address, age from friends where first name is equal to first name and last name is equal to last name. So why are these values surrounded by single quotes? Right, we're trying to figure out, we're trying to look up in the friends table somebody whose first name is Fred and whose last name is Fox. And so this is SQL syntax to say, hey, so first name we know is a column because it's not in single quotes. And so we're saying where first name as a column is equal to the value that's in single quotes here. You can also use double quotes depending on syntax. Then we can query that result and then we can say, hey, if we didn't get anything that means something went wrong. Otherwise loop over all the rows that are returned from this result and output the first name and the address here. So okay, so crash course in SQL. Now I'm gonna go back to HTML for a little bit. So the original HTML that we looked at had images, tables, font sizes, very basic types of things. And the content was fundamentally static. So if we look, this is what Yahoo looked like in 1996. I don't wanna think about this date when you're guys ages, so let's not get into it. But this is how Yahoo actually looked like, right? You can think like even though it has an image at the top, everything is basically links, right? And nothing moved. Same with Amazon. So this is the original Amazon. I don't have the date, does it say it up here? I don't know. This is actually insane when we think about what Amazon is doing now versus where they came from. It's really hard to remember, but they actually originally only sold books. That's the only thing Amazon did. Yeah, they did not run your applications. They did not provide servers for you. They just sold you books. Alta Vista, this used to be the cream of the crop in terms of search engines before Google came out. So this is the Alta Vista homepage. You can actually see it's actually super similar besides that super annoying ad right at the top. It's now immortalized. And this was in 96. So the Internet Archive has a wayback machine that you can go to any web page if it's crawled it, and you can go through the history, so you can see the history of web pages through there. It's actually really cool to look at and explore. So this was awesome until Google came out. This was the original MyCandy 8 Google homepage. And actually what's insane is it's even, the homepage now is even simpler than this, right? There's a lot more links on here than there was before, so. Yeah, so you can see everything was incredibly simple, right? You just get a page with links and forms. You can click a link if you want to visit that link. You type in information and hit enter or click a button if you wanted to submit a form. And so, of course, as the web became more and more important and you had crazy companies trying to sell books on the Internet, people wanted to start doing more things, right? They wanted to say, how can I get, well, it sounds trivial to think about this, right? But it makes sense when you think about now how important the web is to our lives, right? To get to that point, it had to look pretty and be nice and actually be full-featured applications. So how to do fancy animations or pretty web pages? JavaScript, it all comes down to JavaScript. So JavaScript, the key problem with HTML is it does not allow you to do any scripting or do anything dynamic, run any code on the browser. So JavaScript is a client-side scripting language for interacting and manipulating with HTML. So the important thing here is client-side, which means fundamentally it's executed on your browser. It was created in September, 1985. This is actually something I really liked about this by the folks at Netscape, and they renamed it to JavaScript in 1995, and they specifically said that they announced JavaScript in an open cross-platform object scripting language for the creation and customization of applications on enterprise networks on the Internet, which is actually not true. So the important thing here is the object scripting language, so JavaScript is actually a prototype-based scripting language with dynamic-typing and first-class citizens. So you think about, they originally named it as LiveScript, and then changed it to JavaScript. Does anybody know why? Because Java was super popular. I know it's hard to think because you may think of JavaScript as this like curmudgeon-y, old, like enterprise-y language, but if you think about back in 95, around the time frame that Java was first starting, Java's promise was, hey, stop writing crappy C apps that you have to test and debug on every single and write for different platforms, write a Java app, and it will run on every operating system. And that was a really cool promise, and so Java was kind of what I would say, well, now you kind of have rust has a little bit of that coolness or, I don't know, one of these other go, I think, also has a little bit of that. And so they literally tried to just piggyback on the popularity of Java's, even though the languages are incredibly distinct, right? Is Java a prototype-based language? No, it's object-oriented language, right? The fundamental concepts there are objects, not prototypes. Is Java a scripting language? No, does Java have dynamic typing? In 95, did Java have first-class functions? Functions that you could pass into other functions and return functions from functions. No, JavaScript had all that built in. It's insane that they named them so similar, but this shows you what marketing can do, even if it's something you would consider a technical topic like what to name or programming language. Okay, so by 1996, Microsoft added support to JavaScript to Internet Explorer, and they actually changed their name to JScript, so there's weird JScript JavaScript for a while. Fundamentally, finally, in November, ECMA is an internationalization, standardization body, so they submitted the language there, and so in 97, the first version of JavaScript was actually standardized. Okay, I like to ride on PHP. JavaScript can be worse, especially if you're not familiar with it, and especially if you approach JavaScript as you would writing a Java program. So JavaScript itself is a different beast. It is the language of the web, so we need to add JavaScript to our list of all of those languages and technologies that you need to understand to understand the web, and this is definitely 100% true today. Eventually, supported by all browsers, and the language kind of organically evolved over time. So the idea is if you wanna use JavaScript on your web page, what you would do is you would embed into your HTML using script tags, and that would delimit your JavaScript code. So you have a script tag, and then you have something here, like variable and prompt, enter your name below, if name is null, document.write, welcome to my site. So why do I need these HTML comments here? Is the script, like, it's not welcome to my site, is it an HTML text or whatever? No. Yes. Stop the old parser from parsing it? Yeah, so this is actually, nowadays I'd say you probably don't need to do this, but it used to be standard style because somebody could be browsing your site with a browser that didn't support JavaScript. And so if a browser sees a tag, like a script tag, it doesn't know what it is, it just displays the text that's there. So your users wouldn't see the text of your tags, of your script tags in your JavaScript, which is not something you want them to see. So we can see here that, so this prompt function is a way to ask the browser to display a prompt message, as we'll see in a second. Same thing as document.write, this is a way to write out to the current document and change and manipulate the HTML of the page. Without requiring a round-trip back to the server, and that's the important thing. So JavaScript allows this updating of HTML on the top. So you can also specify the type, so text JavaScript, language JavaScript, it's actually not necessarily a little default to JavaScript, but it's kind of a cool way that you can, in the future, add different languages, maybe, to find that script in here. So this would be something like this. This would pop up a box that says enter your name, and then you enter your name, and then it would say welcome to my site, which is exactly the code here. So writing the code directly into the page like that is problematic. If you wanted to reuse a JavaScript file or JavaScript function across multiple pages, you got to kind of insert the code there. So there's this distinction in JavaScript between inline scripts, which are inside and in between script tags, versus external scripts, which we're gonna get and fetch from our web server. So this would be a way to do an external inclusion. So here you have your script tags, and there's nothing inside the script tag, and then you specify the source of an absolute or relative URI of where to fetch that code from. And the browser, it's important to note, the way the parsing engine works, is the browser parses the HTML elements, automatically fetches and goes and parses the JavaScript before it continues to parse the rest of the HTML. So this is why if you go to a website, and it's hanging for a long time, and you see nothing on the page, oftentimes what happens is they have a JavaScript included at the top of the page, and that JavaScript included is timing out, so that server is going up, or there's no problem with that server. So your browser will wait until that times out before trying to parse the rest of the HTML. So this is why if you're a web developer, you put your JavaScript includes at the bottom of the page, so that the content will at least show up first, yeah. Is there any other popular languages that the client sets scripting other than JavaScript? No, JavaScript and JavaScript. The correct answer is kind of, so there's closure script, what's the copy now? Copy script, that's what it is, yeah. So coffee script is a JavaScript-like language that compiles into JavaScript. So you can, and there's a few languages like this, I think there's some crazy people that do like Lisp to JavaScript compilers and all kinds of stuff, so you can, and this is going to be changing-ish in the future where instead of passing the script, you can either do binary, or anyways, there's kind of things. I guess, it kind of depends on what you think. If you think native to a browser, no, it's basically JavaScript or bust, so you either have to compile to JavaScript or you do some kind of plug-in. So I'd say Flash would be an example of something that's not quite, but Flash actually uses JavaScript. Oh, and JavaScript is even infecting us the other way. So with Node.js, any of you know Node.js? Yeah, nice, cool. So the idea with Node.js is basically server-side JavaScript. So the idea is like instead of writing your server-side code in PHP and then having to write a completely different language to your front-end code, why not write one language for both JavaScript? And then you can take advantage of the fact that the browser's JavaScript engines keep getting faster and faster because they're trying to execute everybody's JavaScript code. So then you get that performance benefits on your server-side as well. Okay, so the semantics here of the external include are exactly the same, so it's as if that code was right there on the page, even though it's not. So it's important to keep in your mind, and this actually ties into what we were just talking about with Node.js. So Node.js, so JavaScript is a language, like any other programming language like C. So JavaScript is a language and JavaScript allows you to easily access and modify the HTML elements on the page. These are distinct, separate things. Right, this is why you can run JavaScript on the server, which doesn't have a browser or HTML or anything like that. So, and fundamentally it comes down to the document object model. So the DOM is essentially the site of JavaScript that allows the JavaScript to access and interact with the browser or with the HTML element. So essentially the browser creates this globally accessible document object that any JavaScript code that executes in the browser can access. And so it's used to, the JavaScript code can fundamentally traverse, so traverse means, so the DOM essentially represents that tree structure we were talking about in the HTML. It can query things, like give me the anchor tag that has ID foo. It can manipulate everything. It has a history which is not super important. So we can do cool things like this. We can say, here's my HTML page, standard HTML5 boilerplate. Then I can set a DOM example with a div tag with an ID of insert here. And then I can have a script that says, hey, create. So this is, we know it's using the DOM but it's using the document object. So it's saying document.createElementHR. So HR is a horizontal rule. It's a tag that says, put like a horizontal line here basically. And then I can dynamically get the element in the DOM that has an ID of insert here. So that would be this div element. And I can add this HR as a child. So this will add an HR line dynamically at runtime, even though there is no HR tag here in the HTML text. When you get this, it looks like this. Yay, we got our own line. Using, actually using the DOM is insanely difficult. Why is that? Yes, it fundamentally comes down to, you have all these different browsers, right? So you're writing one JavaScript code, right? You're sending it out to anybody who asks and requests your webpage. And then this JavaScript code has to execute on each of their browsers. And even though there are standards, there are crazy quirks and weirdnesses between different browsers. So coding proper DOM access so that it works across browsers is, was, and I can still probably argue still is, especially with the advent of all these mobile browsers, is a nightmare. So if you wanna check this out, there's interesting things here. So for instance, Internet Explorer does not replace dollar sign NBSP, so this is a non-breaking space, or HTML character code 160. You need to replace its Unicode equivalent of whatever the heck this is. In Firefox, a dynamic, and it's not just Internet Explorer. So not just a, you know. In Firefox, a dynamically created input field inside a form created using document.createElement does not pass its value on form submit. That seems like a big issue. Document.getElementById in Internet Explorer will return an element even if the element name matches. Mozilla only returns an element if id matches. It's insanity. It's insane to try to handle all these cases yourself. That's why there are libraries. So jQuery is a great, fantastic library, and actually a lot of people end up, especially if they haven't been doing this a while, end up equating JavaScript and jQuery in their minds. They kind of think of them, and then equate also the DOM and jQuery. So it's important to remember that there are distinctions here. Like jQuery is kind of a library that will handle all of these crazy nightmare scenarios. So it will do things like detect, if you're running Internet Explorer with a specific version, then do this crazy behavior and work around with your terrible bugs. Okay. So the document object model handles how to manipulate the HTML content on that page. The browser object model essentially allows the JavaScript code to access other things. So, and there's not really a standard here. So some examples are setting the name of the window. So setting the name there, we can actually close. So you can close your own tab or your own window using JavaScript code. You can set the window.location, which will redirect you to this new URL. So, like I said, JavaScript is separate from the document object model and the browser object model. So yeah, not only do you have JavaScript showing up in server-side code, you have JavaScript showing up in querying new, no SQL, new. No SQL databases like MongoDB. So instead of writing SQL, you're writing JavaScript code. In Flash, so Adobe Flash had ActionScript, which is basically JavaScript with DOM-like stuff. You can use it in Java applications, so the new, even I think in the Windows 10, there's the Universal, the UWP, maybe the Windows programming. The Universal Windows platform or something. You can write apps that run on the mobile and the desktop and tablets and all that stuff using just one app. Like you can code all of that in JavaScript. It's pretty cool. Okay, so JavaScript does have objects. So I was on the line, or not trying to, I didn't, it's very much prototype, so we'll see you in a second, so almost everything is an object. So objects are essentially, you think of as hash tables. So they have property names, so they're with property values. So there's properties and they can have values and they can be added and deleted at runtime. So for instance, this is creating an object called, object that has a test property with value foo and a num property, which has the value of the integer 50. So I can set object foo is equal to object, so you can have an object, essentially you can think of it as pointers, right? You can then use console.log, object, object test. What's that gonna do? What's it gonna output? The object. The object, yeah. And then I can set object.num equals to 10,000, I'll console.log and object.num. So important things here, this dot syntax is simply syntactic sugar for this. It's exactly the same. So there's no difference from accessing something with the dot operator like object.num or outputting object bracket.num. Exactly the same. So we can see, we can actually do this, we can see variable object, we can say object foo is equal to object, which shows us this. We can console.log and object object. So everyone is right that we're actually gonna output the object itself. So just unpack this, object test is gonna return to string foo, and then the foo property of object is the object itself, and that's what we're gonna output on the log. Object.num is there, and then we can see that this is exactly the same. So everything works as we expect. So, okay, so JavaScript, so a couple of things here. So we're defining a function factorial. So this should be, we all know the other version. So we can say if n is equal to zero, so why do I need to use triple equals here? Was there anything triple in doubles? The job's tripping errors? Yeah. Yeah, so triple equals checks the type, double equals, we'll try to do type corrosion to try to see, oh, this is a string, should I try to interpret this as an integer? And so you can get weird equality operations here. The triple equals says, is this an integer and is it zero? Otherwise we turn n times factorial n minus one, and so we can do factorial five. We can also do, so the cool thing about JavaScript is we can do have anonymous functions, so what's an anonymous function? A function with no name. Yeah, a function that has no name. And we can also make closures around other values which we'll see. So the idea is, so here the difference between the syntax is here I'm creating a variable called create function, and I'm assigning that variable to the value of this anonymous function. So you can think of this function as declaring some function, and it's gonna return it essentially. And so that's what we're saying, so that's the difference between the syntax here or defining a factorial function. So this defines a variable name factorial. So could we call create function within here? Actually don't know, that's a good question. I don't think so because I don't think the scope is declared, but I don't know, maybe you could. Good question. Okay, so I can set a variable count equals zero, and here I can return an anonymous function that returns plus plus count. So what's plus plus count I'm gonna do? Use it and then increase it or increase it and then use it? Increase it and then use it. Okay, cool. So what is create function return? It returns a function. So if I call variable ink equals create function, and I call ink, what should this return? One, and then what should this return? Two, three. Now if I call variable increment two, and I call create function, and I call increment two, what should this return? One, okay, cool. So essentially the idea is this count variable, when I return this function and this count variable references this variable here. But when I call create function again, it creates a new version of create function that the function that gets returned from create function references. Okay, one, two, three, one. All right, look at that. So some important things here. I'm not sure, I think we'll probably skim over. JavaScript has function scoping, function level scoping. So unlike, how does C do scoping? So in between curly braces, right? JavaScript does not do that. So if you try to, so if you need a new scope, you actually have to create a new function and then you get a new scope. Important things to keep in mind. Okay, JavaScript also has features that you would think on the surface seemed very nice. So it has features to interpret code as a string, sorry, interpret a string as code, and then execute that code. So it has eval, it has the function, which is a function that takes in a string and we'll turn that into a function. Set timeout, which is a function to run a function every x amount of milliseconds. Set interval is the same thing, exec script. So you can do something like this. If I have a variable foo equals to the string bar, I can eval, and so I'm passing into eval string and this string is foo is equal to single quote Adam, single quote, it's not like one. And then I can say console.law foo, what's this gonna output? Adam, yeah, so I'm executing code. I'm fundamentally turning strings into code at runtime. And so I can do, excuse me, I can do interesting things here, variable x console.law. So I can create a test into this new function and ask called test, which will log out, hello. So we can see this here, I eval that, I do console.law foo, I got Adam, I set x test, hello. So this logs out, hello, I do this here. Okay, so one of these super useful things about JavaScript that it was used for originally is form validation. So the idea is how you validate user input on HTML forms. So how would you do it without JavaScript? Why would you wanna do this? What was that? I don't know, before JavaScript, why? And trust user inputs, you need to make sure that it's valid user input. Yeah, so you guys are thinking a bit too far in terms of vulnerabilities, right? But it could be anything, I mean, the number of items you wanna buy or make validating that that number is positive or I don't know, any kind of thing that you wanna validate or validate eating that they actually give you an email address or all types of things, right? So we're accepting user input, we wanna make sure it's in certain forms. And traditionally, if you wanna do this on the server side, you need to do a whole round trip to the server. So you need to submit that form, that form generates an HTTP request to the server, the server checks it, generates an HTML response back and that says if it's valid or not. So here we have PHP code. So we get the student class in grade, if their MDs say error didn't fill out all forms, otherwise check. So in grade it should be either ADCD or technically E here. I did this before I found out we had E grades, I didn't realize that, that's super weird, it's still weird to me, but oh, I did this. So here we're doing all the fancy submission here. So now we can have a form that's sending the student class in grade and we'll just submit the button. So it looks something like this, I can fill in all this stuff. And so if I don't fill out the class, when I submit this it's gonna tell me error, right? Error, error, okay, until their grade success was submitted. So we think about it, what's happening is I'm making a PHP request, so I'm making a request for this form validation regular.php, it's giving me a response and I didn't do this because I had, oops, I had an empty class field and then I had the wrong grade format and then I finally had a correct submission. So we think about how many round trips it took in order to get this response and remember depending on exactly how the server works each of these may have required a new TCP IT connection to the server, which is a whole three-way handshake. So the whole total number of round trips could be a lot and this is wasting a lot of bandwidth of time. So with JavaScript, I can do super cool stuff where I can put on the form and on submit element, which says when this form is submitted, execute this check form function and if it returns true then submit the form, if it returns false, don't submit the form. So this check form can do cool things like getting the form, checking this, making that sure that there's a student value, a class value and a grade value, yeah. So I can do this checking there so I can tell the user, hey, the form must be filled out and I can return false which will stop and prevent that HGG request from being made to the server. I can get the grade, I can test the grade, otherwise I return true. And so this is great. So now if I go through my whole stuff, I forget to type in a class, I get this eh, error, eh, error, HGG work. Finally, I successfully submit the grade and we think about what happened. Well I made one request to get back that HTML page, then all of those other requests happened there and then I finally made the correct submission. So I'm basically cutting down the amount of requests I need to make by using JavaScript. So now that we're doing all of these requests on the client, it seems super redundant, right? Why execute all that same code on the server when we've already checked the client? So no, so that goes to your point, right? So good, I've at least taught you something, right? That you should never trust any user input. Anything that comes from the client is evil and can't be trusted and could be manipulated. Fundamentally, there's no guarantee that that client side validation was executed. Why? Yeah, you can disable JavaScript. Somebody tell me another way to do it. Yeah? What was that? Yeah, you can just make a request. You can use NetCat to make an HGP request to the server. You can use Curl to make a request to the server, right? Without executing any of that JavaScript code. If we fundamentally aren't performing that, so if we get rid of that client, the server side validation, we're only doing client side validation. Now we have no way to know if that data that we're putting in our database or calculating values on conforms to our validation. And so it could lead to a security compromise or not. Why? Or why is it not always a security problem? Close. It's very good, like just deal with this display. Yeah, it could be something stupid. And it could be something that's not, it could be your name, right? Maybe the application wants your name to be alphanumeric, but you put an arbitrary jump in whatever. It just shows up funny or weird, but it doesn't actually cause a security problem, right? So fundamentally, your validation needs to be on both the server side and the client side, which brings up another interesting problem, right? What's the difference between your server side validation code in this example and the server side validation code? Wait, this is, the answer's nothing. So what's the difference between your server side validation code and your client side validation code? Different languages, right? So this is where now you have problems with what about there's inconsistencies between the server side code and the client side code? This means that every time you update the validation on your server side code, you need to update the client side code. And vice versa as well, right? When you update the client side code, you must be able to update the server side code. What we've seen till now basically is you get an HTML page, the HTML page can shove you some JavaScript code. That code's gonna execute in your browser and do whatever. But when you wanna make another HTTP request, what do you have to do? Yeah, so fundamentally, you have to click a link or input a form, which then makes another HTTP request to the server and gets you an HTTP response. So this beautiful object, the XML HTTP request, fundamentally changed the way that web applications were written. So it actually has an incredibly interesting history and it started with literally the unlikeliest of places. And I bet if Microsoft could go back and sabotage this and never let this happen, they would probably be seriously considerate, especially how much Google kind of ate into their project share. So, and you know what Outlook Web Access is? So you get a web app version. It's actually, I think it's changed now. I had a friend who worked on the Exchange team. So for Microsoft, you have Outlook, which is the client, right? When in email client, what for? Email client, right? And then you have Exchange, Microsoft Exchange is the email server. So OWA, the Outlook web application, or web access, runs on the server, right? So it runs on Microsoft Exchange. So actually those two teams used to be completely separate. So the Outlook team was on a completely separate team and the OWA, whatever, Outlook web access, was in the Exchange team. So they used to be completely different. I think now they're together, but I don't know. Microsoft's constantly changing things around. But they said, man, these web applications, you have this terrible, you know, we wanna make a web version of Outlook and every time I click an email, I need to wait for my server to make a request and then I need to wait for my client to make a request to the server and then the server to generate the entire HTML on the page and send it back. Wow, this is super slow. So actually, I got migrated off this. I'm not on this anymore. So I don't think I do one. I think we have like the 365, do you guys have that? Whatever, some more. All right, cool. So the problem is they found scalability problems with traditional web applications. They found out that the servers were just crumbling under all these requests. Because if you think about it, an email app, you wanna be able to click through emails like you are frugally interacting with it. And so they created a version in 98 using an ActiveX control. So ActiveX was a way on Windows that you could basically do plugins. So you can execute essentially plugins there. And the idea was they said, hey, wouldn't it be great if we clicked on email? We only fetched that new email and updated the DOM page to show you that new email. And so actually, and this is why this link is really interesting, because it gives you an insight into how things actually work at a company. So they actually had decided this and created this prototype that was really awesome after the release date of basically their system. So they couldn't, oh, that's right. So I believe it was Internet Explorer was like feature complete and it wasn't gonna add any new features. So they couldn't add this ActiveX control that they wanted and get this asynchronous JavaScript, this XMLHGPRequest object. So they tricked or coerced or convinced the MSXML team, which is Microsoft's XML library to include their ActiveX control, which is why there's this XML name in the name of this object. This is where the XML part of XMLHGPRequest comes in. Not because you're fetching XML necessarily, but because they got it shoehorned in through MSXML. So it shipped in Internet Explorer 5 and exchanged 2000, which was released in November of 2000 where Outlook Web Access used this ActiveX object. And it provided so useful that Netscape added it in December of 2000 so that they have feature parity with Microsoft's Internet Explorer. And the full story is here, it's super interesting. Idea is this object allows JavaScript code to asynchronously retrieve data from a server, process that data and then update the DOM in response to whatever data it got back. So now you fundamentally have this way that the JavaScript code can make requests on its own to the server. And your page doesn't refresh or change. And now you can get some new data, take that back and update your DOM in response to that data. So now you can get apps that only update and modify simple things. So it's kind of a sad story, the whole XMLHGPRequest object, because Microsoft did all this work and actually did everything and got it all started. And then it didn't become popular until Google used it in Google Maps. Like when Google Maps first came out, it was insane. Like especially compared to MapQuest, like if you remember, I mean you've all seen like the Google Maps, right? You have like your square block. Like in MapQuest you would get the directions and if you wanted to move around on a map, there'd be like buttons to click of like up, down, left or right. So you click and you'd wait for the new thing to completely refresh. So you can see like one tile over. Like the fact that you could drag like a Google map around was insane. So just wanted to give a little shout out to Microsoft for doing all that. Okay, so in most browsers, you just say you want a new HTMLXMLRequest object in the Internet Explorer. Even though it's no longer an ActiveX object, you still need to instantiate it in this way. So the idea, you define this the XMLHGPRequest object has an onReadyStateChange function. So this function is called every time the state of the request changes. So then you open a request so you can make a getRequest to this example. And I forget what this option does. I think it's asynchronous or something like that. If you send the request, oh yeah, very cool. So this means that that other JavaScript code on the page can continue executing while this request is being fetched in the background. And then asynchronously this onReadyStateChange will get fired. So it'll get changed and the value they get passed in will be zero first, one if it's loading, two that it's finished loading, three it's almost ready to be loaded and the four is finally done. So basically you just wait and say hey, when this ready state is four, then operate on that data. So then you can access the response text to get the text response. If it's an XML document, you can get the XML. And you can completely interact with it and everything. So super simple example. So this is the way of doing like a cross-platform. So this is a cross-platform XML HTTP request object that is first checking hey, so this is how you do cross-platform stuff. So you're saying hey, if XML HTTP request doesn't exist, and this is the super annoying JavaScript way of having to check if something is null or defined, you can look at the specifics of why you have to do things this way. Otherwise you know you're in Internet Explorer and so you can create it using the ActiveX object. Then if you have a console, so I actually to prove that this does work in old browsers, I ran this in IE6. And so IE6 does not have a console.log to show you stuff. So here I'm defining a console object, and I'm faking it with the log function which pops up in the alert box for the text. So now I'm specifying the already state change of this request to log the ready state. And then if it's for creating a text node with that child there. So, and I'm gonna log the before request, then make a get request so that Ajax text send it. Good, so this is in a modern browser. So in Chrome, I set some break points here. So you can see from the before request, we then send the request. And it's actually interesting, before that even returns, we have a thing here. So we just log one, so the ready state is one. Then we log the after request, the ready state is two, three, four. And then it changes this page to be the test Ajax which is the result that I got back. And the cool thing is that we pop over to the network tab. So if you wanna get familiar with web apps, you should spend time in these developer console modes. So you can actually see what's going on in the web page you visit. The network tab shows us that we got this Ajax.html page which then made an asynchronous request to Ajax.txt. And the cool thing is that it has this initiator which tells you exactly which line of JavaScript code caused this request to be made. And you can see that that's what this Ajax on the door test.txt had. Cool. So you can actually run this exact same code on internet explorer six. Before request, one, two, three, four. And then the test Ajax. And then after request, so it's actually really interesting. It doesn't get to that after request thing. So the asynchronous, it's not really happening super asynchronously, but hey, it's no worse. So what you can see here, it even updated test and then Ajax. So in between that thing over there. So, but it does work. This is proof 6.0. It's obviously much easier to use jQuery and you should absolutely use jQuery when you can do this because this is a whole example. So you first include the jQuery library. So this is how you're getting external include to include the jQuery library. And what you say is dollar sign. So dollar sign is the jQuery object that has a lot of the jQuery functions that you want. You say .get and then you say you want Ajax.test.txt and when you get this response back, you wanna call this function and pass in the data so that you can update that with that data here. So this works 100% in Chrome and it's super awesome and it's much less code because jQuery is doing all that crazy stuff with testing for obvious. And it still works in Internet Explorer 6. So this XML HTTP request object is where the term Ajax comes from. So the idea is now you can make web applications that asynchronously fetch only the required data from the server. So you can do super cool stuff. You can also do this in response to user input. So it clicks forms, load data, so you're not actually making any branding for the HTTP request in the server. If you wanna look at this, there's cool stuff about the origins of the term Ajax. Okay. I'm designing a web application and here we go. Okay, so PHP code, if you look at a PHP application, they oftentimes look like this. So you start a session, you get some username, you use some gets, you know, echoes here, set some values. You then have, like, so, so all this is completely valid PHP code. Fundamentally here, we're mixing the HTML output that we want this page to have along with the business logic of this page. Right, we're saying where we want our username to go. You can see we have a database query for comments in here. We're using SQLite to fetch comments from a database. And so here I have, in my PHP application, intermixed with the HTML code, I have PHP code and SQL queries all mixed together. This makes for a frighteningly difficult and hard to scale web application. So somebody asked, I think, on the mail, unless why I dislike PHP, and that's because it allows you to, and it encourages you to be writing your applications in this way. In this kind of spaghetti, all intermingled, you got SQL queries and HTML. It's a very natural way of coding HTML, but it's horrible, I mean, sorry, coding a web application in PHP, but it's horrible from a maintenance perspective. Right, because everything is all tightly coupled and interconnected with each other. So terrible, terrible in the terms of maintenance. So if you want to change how comments are stored or if you want to add extra metadata to comments, you have to find every query in all of your PHP scripts that touch the comments table and make sure that they're not updated or changed. As well as all the outputs. So you need to say, where is all this comments output used? I mean, to update every single place in the code. So you have this HTML intermix with SQL queries, intermix with PHP code. It makes her difficult reading and it makes her buggy and vulnerable programs. The other thing that PHP has is this really tight coupling of URLs to scripts. So by default, PHP maps every valid URL to a specific script that gets executed. So URLs look like this. Example.com, add underscore comments.php. So this would map directly to your web route, which is typically var www. Usually like maybe var www.html and then add underscore comment.php or view underscore comments.php or users view users adminsecret.php and would demand exactly to this file structure. Is this a good thing? What do you think? Yeah, so like I said, there's adminsecret.php. Maybe I don't want somebody to execute that, right? It also means that anytime you want, let's say you want to refactor and change, maybe you don't like this add underscore comment name. Maybe you really like hyphens and so it should be add hyphen comment. Or you wanna call it add a comment or something or you wanna completely refactor it, right? Now you can't do that without breaking all of your previous links to this add comment and so you need to write basically a redirect rule to have a patchy or whatever your web server is, redirect all requests to add underscore comment.php to your new add comment php script. So it's not necessarily a vulnerability or a problem. Well, I mean, one thing you could say is that you're leaking a bunch of information, right? Somebody by browsing your website can understand exactly that you are out the files that are on your web server, which, you know, it's not a huge severe vulnerability but it's not great either. So as we saw, the web ecosystem, we have our clients which make HTTP requests to a web server. They make requests back to a web application which executes some code, fetches some things from our database, makes an HTML response. And we've even seen that this HTTP response can include JavaScript code that gets executed on the client's browser, which can then make and fetch additional requests. When in reality, web applications are incredibly complicated, right? So you can think of the web as an ecosystem where we have a client accessing a website. That website may have to fetch other third party web services, right? Fetch some human things which may talk to their own web applications. Okay, yeah, the web is complicated. Okay, so the question is, when you're using a browser, right? If you think about the web as an ecosystem, so we wanna think about it not just in terms of the single client server model we've been thinking about, but in terms of the clients and all of these servers on the web and all of the clients and all of the servers. So a client can make a request to a specific web app. So a specific application, right? And we know exactly how this is done. We know this is making HTTP requests, blah, blah, blah. Gets back an HTML response. Now, we can click a new link which will take us to a new server and send us a response. So fundamentally from a security perspective, should this new application, this new page, be able to find out anything about this old one? We'd hope not, right? And furthermore, do we often have the case? I don't like this at all. I don't like this at all. I don't like this at all. It doesn't make any sense. Okay, I even made these slides. I don't even know. I know the point this one's trying to make. I don't really understand this part here. I would kill this part. Yeah, a web app can make other requests look like a goal. But here, fundamentally, in your browser, so how many people use more than one tab when they're browsing the web? How many people are like me and use like 20 to 30 tabs? Oh wow, a lot more of you than I thought. Yeah, I'm really bad. I actually don't, I realized I never use the bookmarking feature in my browser. I don't think I've ever booked, every time I bookmark something, it's an accident. So if you look at my bookmarks, they're all like terrible things, where I happen to hit the wrong key to bookmark it. Yeah, I either just search, or I use my Google history or something. So, fundamentally, from a security perspective, let's say this first website here. Oh, I'm gonna do it here for you. The people at home. This tab is accessing, let's say, facebook.com. This tab accesses attacker.com, something controlled by a hacker. We've been talking about the fact that each of these web applications can send you HTML code with JavaScript that's executing on your browser. This should terrify you, because you can easily go to some attacker, some malicious site, and now fundamentally, you're downloading some code that somebody else wrote, and you're executing it on your computer. This seems insane. It seems like everything, we should just burn everything and start over from scratch. So, how is it the case that we can do this, and when I visit some crazy, malicious site, it doesn't completely alter and change Facebook, or my bank account, or can it get me to send and transfer money to an attacker? The browser must do something, yes. Fundamentally, the browser must do something. So this is a good reason why JavaScript is not a compiled language. It's an interpreted language, so the browser has an interpreter. But this is actually fundamentally how oftentimes, this is what's called a drive by downloads. The idea is browsers have bugs. If you visit a malicious website, they'll send you JavaScript that takes advantage of those bugs and then executes arbitrary code in their machine. So fundamentally, when we come back on Wednesday, we're gonna talk about the most important principle and concept to web security, which is, how does the browser make sure that the attacker's JavaScript code can't mess with Facebook's data?