//Cyber Battlefield/Client Side Scripting – Non-Event Driven

Dynamic Web Pages

try clicking on the pluses!
+ the beginning
+ the middle
+ the end

The web pages we've created up to this point have been static web pages, meaning that nothing on the page changes. You only see different content by loading different web pages. Moreover, everyone looking at that page sees exactly the same thing. All but the most basic sites these days have dynamic content, which means that user interactions can cause changes to the current page, or that websites have pages that look different to different users. Fancy websites like Google Maps are built around the idea of dynamic web content. To the right is an example of a simple piece of dynamic content. Click on the +'s and -'s and see what happens. Note that the URL never changes.

Dynamic content is only possible if user interactions (or sometimes other factors, like a timer going off) can cause some snippet of code to execute. The only question is whether that snippet of code executes on the client machine (meaning in the web browser) or on the server; i.e. do we have client-side scripting or server-side scripting. This is actually a simple question, but the consequences are important.

  1. Allowing code to execute in response to user input (or other events, like a timer going off) could pose a security risk. In client-side scripting the one visiting the website incurs risk. In server-side scripting the organization hosting the website incurs risk.
  2. Executing scripts costs CPU cycles. Server-side scripts cause more work for the server machine, client-side scripts cause more work for the client-side machine.
  3. Client-side scripts don't require network communication to change what's on the web page. Server-side scripts can only change what the user sees after some back-and-forth message passing between server and client.

In this lecture we start looking at client-side scripting of web pages. As you might well guess, the language our scripts will use is JavaScript which, conveniently, you've already studied. It's worth noting that you can actually turn JavaScript off in your browser (how depends on the browser). This way you don't take on the security risks inherent in client-side scripts. Of course lots of useful and fun websites then become useless. This is not the first time you have seen that trade-off! More functionality often means less security.

Embedding Scripts and the DOM (Document Object Model)

The World Wide Web Consortium (W3C) is an organization that is responsible for the development of many standards for the web. HTML is one of those standards. The W3C has a lot of nice tools for learning about HTML and related standards. You can read their material on the DOM starting here.
Browsers allow you to embed scripts in HTML code, as you've already seen, using the
<script type="text/javascript">...</script>
tags. However, this is only part of the story. Without any way to interact with the web page it's embedded in, scripts would be of pretty limited utility. The browser gives a script access to the "DOM" (Document Object Model) for the current web page, which allows the script to change any and every aspect of the page. The DOM is the browser's internal representation of a web page, and most browsers have a similar (though not always identical) DOM. At its simplest, the DOM for a page is constructed from, and reflects the structure of, the page's HTML file. The root of the page's representation is available to an embedded JavaScript program via the variable named document. A script can write HTML code directly into the DOM using the function document.write( ... ). The position of the script in the HTML file determines where the new HTML code appears, in that what you output simply replaces the <script type="text/javascript">...</script> in the final document. Before going any further, let's look at a simple example of what kinds of things you can do with this new-found power.

ex0.html (see how this page is rendered) ex1.html (see how this page is rendered)
<html>
<head></head>
<body>
<script type="text/javascript">
  var iter = 0;
  while(iter < 1000)
  {
    iter = iter + 1;
    document.write("G O N A V Y ! ");   
  }
</script>
</body>
</html>
<html>
<head></head>
<body>
<script type="text/javascript">
  var iter = 0;
  while(iter < 1000)
  {
    iter = iter + 1;
    document.write('<span style="color: #ff0000">G O</span> <b>N A</b> V Y ! ');
  }
</script>
</body>
</html>
Short program, long web page! Remember, document.write(...) allows us to insert arbitrary HTML code! So this time we've added formatting.

One thing you have to think about when you have embedded scripts is when each script will get executed.
Essentially, they get executed in the order the browser comes across them.

Hopefully the following example clarifies this:
ex2.html Gets rendered as ...
<html>
<head></head>
<body>
<script type="text/javascript">document.write("1");</script>
fish,
<script type="text/javascript">document.write("2");</script>
fish,
red
<script type="text/javascript">document.write("<span style='color: #ff0000;'>fish</span>");</script>,
blue
<script type="text/javascript">document.write("<span style='color: #0000ff;'>fish</span>");</script>.
</body>
</html>
fish, fish, red , blue .

Embedded scripts with JavaScript code in separate files

For larger scripts, or for JavaScript code you want to use in many pages, it's nice to keep the JavaScript code in a separate file. This is done by setting the src property of the script tag to the path to the file containing the JavaScript code. (BTW: files containing JavaScript code are traditionally given the .js extension.) Thus,
<script type="text/javascript">document.write("hello");</script>
is effectively identical to
<script type="text/javascript" src="ex.js"></script>
assuming the file ex.js simply contains the line document.write("hello");. For the kind of short scripts we'll deal with in this class, we wouldn't usually do this, but if you do much JavaScript programming, it quickly becomes difficult to manage having both the HTML and the JavaScript in the same file. What's interesting to note is that the JavaScript file specified in the src property doesn't have to come from the same site as the web page that's using it. You could have a site here at www.usna.edu that references a script from www.usma.edu, like this:
<script type="text/javascript" src="http://www.usma.edu/sneaky.js"></script>
This is, of course, a bit of a risk. You're putting your faith in another entity, trusting that they won't put sneaky stuff in that JavaScript file. Even if you have no fears on that count, you're trusting that their security is good enough that you won't have to worry about someone breaking into their server and changing that file.

More of the DOM: document.location

Input a JavaScript expression or statement and press enter
js>
Another feature of the DOM that we can manipulate with JavaScript code is the value document.location. This variable holds the URL for the current page. So, enter
alert(document.location);
into the interpreter field to the right and press enter. You should see an alert box pop up displaying the URL for this page. Setting the variable document.location to a new string value (it should be a URL!) causes the browser to load that page. So, try entering the following in the interpreter field to the right and press enter:
document.location = "http://www.usma.edu";
If you did as I asked, thanks for coming back! One simple use of the behavior for setting document.location is redirection. If you're moving an important page from one URL to another, you can set up a blank page at the old URL that does nothing but immediately send the viewer to the new URL. Here's an example:

ex3.html (see how this page is rendered)
<html>
<head></head>
<body>
<script type="text/javascript">
  document.location = 'http://www.usma.edu';
</script>
</body>
</html>


If you hover over the link, you look like you're going one place (ex3.html), but then you appear to be sent to another. What happened? Well, you actually do go to ex3.html. However, that page immediately redirects you to http://www.usma.edu.

A timely script

Here's an example of the kind of thing we can do with embedded scripts:
Every time you visit this page, you get an updated report of the time remaining until graduation, but only when the page loads. It's a big number, but even worse: it's not counting down! Time is frozen and you'll be a plebe forever!!

Okay, clearly the graduation clock should actually count down, so here's another version:

Whenever you refresh the page, the two clocks will briefly be in sync.

HTML and e-mail

Most e-mail clients allow you to write and read e-mails with HTML formatting, not just plaint-text. Combining this with JavaScript allows for some evil possibilities. For example, we know how to make HTML automatically send you to the page of our choosing, no clicks required! If an e-mail client executes JavaScript embedded in an HTML-formatted e-mail, we can craft an e-mail such that just opening the e-mail sends the machine's browser to a site of our choosing. You are safer with an e-mail client that does not execute embedded JavaScript like this!

Pretty much any e-mail client allows attachments, and you are free to attach an HTML file to an e-mail. If the recipient opens the attachment, it will be rendered by the recipient's browser, and the browser almost certainly will execute JavaScript! Thus, we can easily make an e-mail that includes as an attachment an HTML file that does the document.location trick to redirect the recipient to a page of our choosing. As long as the recipient opens the attachment, we can send him to any page we like — automatically.

In fact, even without JavaScript, HTML-formatted e-mail allows for some undesirable shenanigans. For example, suppose I send out an HTML-formatted e-mail to a bunch of people with the embedded image:

	  <IMG src="http://rona.academy.usna.edu/~sy110/f18.png">
	
I can go check on rona's web server logs for GET requests of /~sy110/f18.png and find out exactly when that image was accessed ... i.e. exactly when my e-mails were opened. If I can match IP Addresses to hosts and hosts to users (there's services for that) I'll know exactly who opened my e-mail, and when they opened it. For this reason, many e-mail clients refuse to open remote images embedded in e-mails.