Saturday, 16 March 2019

How to reset password with email in php and mysqli

How to reset password with email in php and mysqli



 step one create database



-- Database: `raj`
--

-- --------------------------------------------------------

--
-- Struktur dari tabel `user`
--

CREATE TABLE `user` (
  `id` int(100) NOT NULL,
  `username` varchar(100) NOT NULL,
  `password` varchar(100) NOT NULL,
  `email` varchar(100) NOT NULL,
  `token` varchar(1000) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

--
-- Dumping data untuk tabel `user`
--

INSERT INTO `user` (`id`, `username`, `password`, `email`, `token`) VALUES
(1, 'hens3159', 'lukmana12345', 'hens3159@gmail.com', 'ijh8aqt6w7');


 step 2:db.php database connection 

<?php
$host = '127.0.0.1';
$user = 'root';
$pass = '';
$db = 'raj';
$link = mysqli_connect ($host, $user, $pass, $db) or die (mysqli_error()); //die digunakan untuk memberhentikan syntax sampai disini
 ?>

<?php
session_start();
function result ($query) {
  global $link;
  if ($result = mysqli_query($link, $query) or die ('gagal menampilkan data')){
  return $result;
  }
}

function run($query) {
  global $link;
  if (mysqli_query ($link, $query)) return true;
  else return false;
  }

function user($username) {
  $query = "SELECT * FROM user WHERE username='$username'";
  return result ($query);
}

function update_token($code,$username) {
$query = "UPDATE user SET token='$code' WHERE username='$username'";
return run ($query);
}

function update_pass($konfir_pass,$username) {
$query = "UPDATE user SET password='$konfir_pass' WHERE username='$username'";
return run ($query);
}
 ?>


step-3:login.php



<?php
require_once 'db.php';

//check for submit
if  (isset($_POST['submit'])) {
$username = $_POST['username'];
$password = $_POST['password'];
$user_db = user($username);
$row= mysqli_fetch_assoc($user_db);

//if password in form same with password in database
if ($password==$row['password'] && $username == $row['username']) {
$_SESSION['user'] = $username;

if($_SESSION['user']==$username){
header ('location:home.php');
}else {
  echo "login gagal";
}
}else {
  echo "your password is wrong";
}

}
?>
<h3> form login </h3>
<form action=""  method="post">
<label>username</label><br>
<input type="text" name="username" placeholder="username"><br>
<label>password</label><br>
<input type="text" name="password" placeholder="passwrod"><br>
<p><a href="forgot.php">forgot password</a></p>
<input type="submit" name="submit"><br>

</form>


step4: home.php


<?php
//connect to db.php
require_once 'db.php';
if (!$_SESSION['user']) {
 header ('location:login.php');
}

//check submit and send email
if  (isset($_POST['submit'])) {
$tujuan = $_POST['tujuan'];
$judul = $_POST['judul'];
$isi = $_POST['isi'];
$headers = "From: chikennotes@gmail.com" . "\r\n";
mail($tujuan,$judul,$isi,$headers);
}
?>

<!DOCTYPE html>
<html>
<head>
<title>Send Email</title>
</head>
<body>
  <h3> Send Email </h3>
<form action=""  method="post">
<label>To</label><br>
<input type="text" name="tujuan" placeholder="to"><br>
<label>Title</label><br>
<input type="text" name="judul" placeholder="title"><br>
<label>Content</label><br>
<input type="text" name="isi" placeholder="content"><br>
<input type="submit" name="submit">
</form>
</body>
</html>


step5:forgot.php

<?php
require_once 'db.php';

//check submit
if  (isset($_POST['submit'])) {
$username = $_POST['username'];
$email = $_POST['email'];
$db = user($username);
$jumlah = mysqli_num_rows($db);

//check is there username in database
if ($jumlah !=0) {
  while ($row=mysqli_fetch_assoc($db)){
    $db_email = $row['email'];
  }

//check input email similiar with email in database
if ($email==$db_email){
// make random code
  $code = '123456789qazwsxedcrfvtgbyhnujmikolp';
  $code = str_shuffle($code);
  $code = substr($code,0, 10);

// for send token
  $alamat = "http://localhost/coba2/update.php?code=$code&username=$username";
  $to = $db_email;
  $judul = "passwrod reset";
  $isi = "this is automatic email, dont repply. For reset your password please click this link ".$alamat;
  $headers = "From: chikennotes@gmail.com" . "\r\n";
  mail($to,$judul,$isi,$headers);

//echo $alamat;
if (update_token($code, $username)){
  echo "your password have reset";
}else {
  echo "please try again";
}

}else {echo"your email didn't register";}

}else {echo"your username didn't register";}
}


?>

<!DOCTYPE html>
<html>
<head>
<title>Page Title</title>
</head>
<body>
<h3>Reset Password </h3>
<form action=""  method="post">
<label>username</label>
<input type="text" name="username" placeholder="username">
<label>email</label>
<input type="text" name="email" placeholder="email">
<input type="submit" name="submit">

</form>
</body>
</html>


step 6:update.php


<?php
require_once 'db.php';
$kode=$_GET['code'];
$username = $_GET['username'];

//check link
 if (isset($kode) && isset($username)){
 $db_user = user($username);
 $row = mysqli_fetch_assoc($db_user);
 $token = $row ['token'];
 $db_username = $row ['username'];

//check between tokens & usernames that are in links and databases
if ($token==$kode && $db_username==$username){
  //check submit
  if  (isset($_POST['submit'])) {
  $password = $_POST['password'];
  $konfir_pass = $_POST['konfir_password'];
  //check password
  if ($password==$konfir_pass) {
  echo "password telah diupdate";
    update_pass($konfir_pass, $username);
    header('location:login.php');
  }else {echo "password is different";}
  }
}else{echo "token & username is different";}
}else{echo "link is wrong";}

?>
<!DOCTYPE html>
<html>
<head>
<title>Send Email</title>
</head>
<body>
<h3>Change your password</h3>
<form action=""  method="post">
<label>password</label><br>
<input type="text" name="password" placeholder="password"><br>
<label>new password</label><br>
<input type="text" name="konfir_password" placeholder="new password"><br>
<input type="submit" name="submit">
</form>
</body>
</html>





JSPUNCH.HTM-Code for JScript Punchline


<HTML><HEAD><TITLE>JScript Punchline demo by Ray Daly</TITLE> <SCRIPT LANGUAGE="JavaScript"> <!--hide this script from some browsers function Punchline () { document.open(); document.write ("<BODY BGcolor=#00EE00><P><I>To get to the other side.</P> </I>") ; document.close(); } // hidden ray.daly@mailcall.com 12/16/95--> </SCRIPT> </HEAD> <BODY> <H1>Punchline</H1> <H2>A jJScript Punchline demo by Ray Daly</H2> <P>Why did the chicken cross the road?</P> <FORM> <P><INPUT TYPE="button" VALUE="Punchline" onClick="Punchline()"> </P></FORM></BODY></HTML>

Protecting your document from rogue users


Make Sure Your Functions Are Loaded

First, you should make sure your functions are loaded, which is easy to do. If you use a function that isn't loaded, your code will malfunction. What's more, it's almost certain to malfunction in a manner that leaves no doubt in the reader's mind that something went wrong-and that it's your fault. If there are JavaScript expressions in the body of your page and those expressions call other JavaScript functions that you wrote, place those JavaScript functions in a <SCRIPT> element within the <HEAD> element. The< HEAD> element is loaded before the <BODY> element; you can depend on the function being there. This approach prevents a user from impatiently clicking on a partially loaded page and invoking a JavaScript function that hasn't been downloaded from the server yet.

Validate Input

If you're getting input from the reader, make sure you check it before blindly using it, especially if it's supposed to be a number. Use the parseInt() and parseFloat() functions. If it's supposed to be an integer, check it like this:
if (Math.ceil(x) == x)
    {
    // it's an integer
    }
else
    {
    // oops...
    }
The Math object's ceil() method returns the next higher integer for a floating-point value; for an integer value, it will return the same value. The floor() method will also work.
Finally, if the number is supposed to be within a certain range of values, make sure that it's within the specifications. For example, if it's supposed to be a value from 1 to 10, put something like this in your code:
if (x < 1 || 1Ø < x)
    {
    alert("" + x + "is not between 1 and 1Ø");
    return;
    }

But Surely No One Would Do That!

Sometimes users will input data that they're not supposed to. Some users will be confused about what they're supposed to enter; they won't understand what they're supposed to do. Other users will deliberately try to make your page crash just for fun. Assume that when you ask for a number, someone is going to enter anything except a number. "But you're not supposed to do that" is not a valid defense for letting your code malfunction just because you asked for a number but someone entered a phone number or the word "no."

Not All Platforms Are Created Equal, Part 2

There are some differences between the implementations of Netscape Navigator for the various supported platforms. You can't expect everyone to use the same platform that you use, and you should write your code to defend against problems tied to specific platforms:
  • Macintosh and Windows browsers can't return NaN (Not a Number) when you call parseInt() or parseFloat() and the argument is not a number. They return 0 instead.
  • random() only works on UNIX platforms.
  • Xwindow platforms have difficulty drawing new browser windows. Even if you specify the parts of the window you want, you're going to get a bare window.
  • When you open a new document, call open() twice. Windows and Macintosh browsers won't open the document unless you call open() twice. 

Clocks java script


   <HEAD>
        <TITLE>Clock</TITLE>
        <SCRIPT>
<!--
function updateTime()
    {
    var now = new Date();
    var time = "" + now.getHours() + ":";
    var minute = now.getMinutes();
    if (minute < 1Ø)
        {
        time += "Ø";
        }
    time += minute + ":";
    var second = now.getSeconds();
    if (second < 1Ø)
        {
        time += "Ø";
        }
    time += second;
    window.status = time;
    window.setTimeout("updateTime()",1ØØØ);
    }
//-->
        </SCRIPT>
    </HEAD>
    <BODY ONLOAD="window.setTimeout('updateTime()',1ØØØ);">
    </BODY>
</HTML>

Scrolling Messages java script

Here's an example of how to create a scrolling message:

<HTML>
    <HEAD>
        <TITLE>Scrolling Message</TITLE>
        <SCRIPT>
<!--
var winLength = 2ØØ; // guess at how many spaces wide the status bar is
var speed = 1ØØ; // number of milliseconds between updates
function scroll(count)
    {
    var msg = "Hi! This is my scrolling message in the status bar.";
    var out = " ";
    var cmd = "scroll(";

    if (count <= winLength && Ø < count)
        {
        var c = Ø;
        for (c = Ø ; c < count ; c++)
            {
            out += " ";
}
        out += msg;
        }
    else if (count <= Ø)
        {
        if (-count < msg.length)
            {
            out += msg.substring(-count,msg.length);
        }
        else
            {
            count = winLength + 1;
            }
        }
    window.status = out;
    count--;
    cmd += count + ")";
    window.setTimeout(cmd,speed);
    }
//-->


        </SCRIPT>
    </HEAD>
    <BODY ONLOAD="window.setTimeout('scroll(winLength)',speed);">
    </BODY>
</HTML>

What JavaScript isn't

JavaScript can provide a high degree of user interaction like some other systems, including CGI and Java.

CGI


The Common Gateway Interface (CGI) provides a mechanism for a program on the server to interact with the client's browser. You can use any language to write CGI programs, and CGI programs may be interpreted (PERL scripts, for instance) or compiled (C or C++). One popular use of CGI is in hit counters-programs that modify the page to show how many times that page has been visited. Another popular use of CGI is in form handling, where a program on the server reads the data from the user input fields and does some work based on that data.
JavaScript, which does its work in the client's browser, cannot entirely replace CGI. For instance, a hit counter has to update a file on the server so it can remember how many times the page has been visited by all visitors. That's a little difficult for JavaScript, but a JavaScript Web page can keep track of how many times a given visitor has visited the page. So can CGI, but only if given an endless supply of disk space on the server.
JavaScript can do a lot of the same things CGI can do, and it can often do them much more efficiently. For example, JavaScript can do form validation more efficiently than CGI. When a non-JavaScript page has user input fields, it sends all the field values to a CGI server application. The CGI application then has to figure out whether the data in each field makes sense before doing something with the data. A JavaScript page, however, can validate the data entered before it is sent to the server. If the data is invalid, JavaScript can block transmission to the server. Because all of this work is performed on the client side, JavaScript does not waste bandwidth transmitting bad data and then receiving an error page from the server.
JavaScript can also replace some of the animation and page-reloading functionality of CGI. To perform animation and page-reloading, CGI provides mechanisms called "server push" and "client pull." With server push, the Web page server maintains a connection between the client (the browser) and server. Server push restricts the number of simultaneous connections the Web page server can maintain-a popular page using server push will frequently reward potential visits with a "sorry, not now, try later" message. Client pull, on the other hand, involves the client frequently re-establishing its connection to the server, artificially adding to the traffic at the server. You can use JavaScript to create dynamic documents that would have required either server push or client pull in CGI, but that involve no additional traffic or long, drawn-out connections between the client and the server.
JavaScript is independent of the server platform, the hardware and software that your server uses. CGI has to be written in a language that your server platform supports. No single language is supported by all server platforms. If your Web pages rely on CGI, what happens if the company that provides your server changes platforms? What happens if they go bankrupt and you have to take your pages and their CGI applications to another server?
Finally, not all Web space providers allow Web pages to use CGI. CGI requires that the program be executed on the server, but some Web space providers are nervous about the possible side effects of badly written or maliciously written CGI programs being executed on their machines. Some providers only allow the use of a limited set of applications. Many providers do not support server push CGI. JavaScript running on the client browser is perfectly safe to the server, and affords you, the creator of the JavaScript document, much greater flexibility in how your document interacts with the reader.

Java

Many people confuse JavaScript with Java, which is a programming language developed by Sun Microsystems, Inc. Each has its own Usenet newsgroup, yet people frequently post questions about Java to the JavaScript newsgroup, and vice versa.
Java is a programming language and JavaScript is a scripting language. Java programs are compiled on the server. You can write stand-alone programs in Java. Scripts written in JavaScript are interpreted by the browser. You cannot write stand-alone programs in JavaScript-you need a browser to interpret JavaScript.
Java is object-oriented. It employs classes and inheritance. It provides encapsulation of data. JavaScript is object-based. There are no classes. There is no inheritance. Data within objects is readily accessible.
Java is compiled into "applets" that are accessed from HTML pages. JavaScript is embedded in HTML.
Java requires that data types be strongly typed (if a function expects one of its arguments to be a number, the function will not accept a character string). JavaScript is loosely typed. JavaScript has numbers, character strings, and Booleans (logical yes/no, true/false, on/off data) and freely interchanges them.
Java can be used to create very powerful applications. JavaScript scripts cannot really do all the neat things that Java applets can. On the other hand, it is much more difficult to write programs in Java than it is to write scripts in JavaScript. 

The history of JavaScript

JavaScript is a lightweight object-based scripting language created by Netscape Communications Corporation for developing Internet applications. JavaScript is lightweight in that there isn't a great deal to learn and you can be productive with it very quickly, in contrast to much more complex languages such as Java. As a scripting language, JavaScript is meant to tell an application what to do. Unlike languages used to create applications, it cannot do anything without the application.
You can develop server applications or client applications with JavaScript. In this book, the term "server" refers to the computer where your Web pages reside. The term "client" refers to the browser application that loads and displays your Web pages. This book focuses on teaching you to create client applications with JavaScript-specifically, documents (Web pages) on the World Wide Web.
You can embed JavaScript statements in Web pages, which are written in HTML (Hypertext Markup Language). JavaScript is an extension to HTML that lets you create more sophisticated Web pages than you ever could with HTML alone. To appreciate this, it helps to know a little history.

The history of JavaScript

Strictly speaking, HTML is a Standard Generalized Markup Language (SGML), Document Type Definition (DTD). An SGML document has three parts. The first part defines the character set to be used and tells which characters in that set distinguish text from markup tags. Markup tags specify how the viewer application, or browser, should present the text to the user. The second part of an SGML document specifies the document type and states which markup tags are legal. The third part of an SGML document, called the document instance, contains the actual text and markup tags. Because there is no requirement that the three parts of an SGML document reside in the same physical file, we can concentrate on the document instance. The Web pages you create are document instances.
Most HTML browsers assume a common definition about the character set used, and about which characters distinguish text from markup tags. They also generally agree about a core set of legal markup tags. They then diverge on which additional new markup tags to permit.

HTML 1.0 and 2.0

HTML 1.0 refers to the original set of markup tags. HTML 1.0 is so limited that a browser that restricted HTML documents to HTML 1.0 would be a museum piece.
HTML 2.0 includes a more generous set of markup tags than HTML 1.0; in particular, it allows markup tags that define user input fields. As of this writing, HTML 2.0 defines the de facto common core of markup tags. You can create a relatively sophisticated Web page with HTML 2.0 markup tags.

HTML 3.0 and NHTML

HTML 3.0, still in the process of standardization, adds additional markup tags to those defined in HTML 2.0, such as tags to define tables, figures, and mathematical equations. HTML 3.0 expands some tags to include more functionality, such as centering text or images in the browser, and adding background colors and images.
NHTML, a nickname for Netscape's extension of HTML 2.0, is another set of markup tags that goes beyond those defined in HTML 2.0. Netscape, like other developers of cutting edge Web browsers, is trying to influence the development of the HTML 3.0 standard, and has developed extensions of its own. At the same time, Netscape is making an effort to conform to the evolving HTML 3.0 specification. Furthermore, Netscape continues to support markup tags that the draft HTML 3.0 specification has declared obsolete.
Netscape's browser, Netscape Navigator, is not precisely HTML 3.0-compliant. The best way to find out whether Netscape Navigator supports a particular markup tag is to get the latest version and try a document containing the tag.

Why NHTML isn't proper SGML

Formally, a Web page is the third part of an SGML DTD, and as such, should conform to the SGML DTD specification.
A few features of NHTML do not conform to the rules of the SGML DTD specification. If browsers actually treated a Web page as the third part of an SGML DTD, this would be a problem. However, browsers typically accept a certain hard-coded level of HTML-typically HTML 2.0 with some HTML 3.0 extensions and some NHTML extensions-and ignore markup tags that they do not recognize.
Where this nonconformity does present a problem is in writing tools that validate Web pages. These tools typically use an SGML parser, and they require a page to be part of a properly conforming SGML DTD for the level of HTML they check.
Should you validate your Web pages? I think so, although as of this writing, it's not a viable option for JavaScript pages. So far, no one has come up with a validation tool that recognizes and validates the syntax of JavaScript. But count on it; someone will. And when they do, try it on your pages. Validation tools have saved me countless hours of headaches trying to figure out why my HTML code wasn't working correctly.
Just for the record, here are the nonconforming parts of NHTML:
  • NHTML makes liberal use of the % character. It's used to specify that certain entities occupy a fixed percentage of the window's real estate, or to specify scaling on images. The problem with this is that the % character is a reserved character in the SGML specification for declaring parameter entities in a DTD. It does not belong in a Web page. There is no workaround to achieve the same effect. An SGML parser-based validation tool will not accept pages with % characters in the attributes.
  • NHTML allows the BORDER attribute to be specified in two ways:
    <TABLE BORDER>and
    <TABLE BORDER="1">The SGML DTD specification does not allow an attribute to be specified in two entirely different fashions like this. While a grammatically correct SGML DTD cannot handle both forms simultaneously, a grammatically correct SGML DTD can handle either form. Since BORDER alone means the same thing as BORDER="1", BORDER alone is redundant, and you can write a DTD that says the BORDER attribute always takes a numeric argument. From the standpoint of making your pages clear and easy to maintain, it's always a good idea to state the border size explicitly.
  • SGML parsers will not accept tags like <FONT SIZE=+3> and <FONT SIZE=-2>. Fortunately, this one is easy to work around: Place the value in double quotes, like this:
    <FONT SIZE="+3">and
    <FONT SIZE="-2">
  • Color attributes specified as six-digit hexadecimal values will not pass an SGML parser if written like this:
    <BODY BGCOLOR=#123456>As with the incremented or decremented font sizes, you can fix this problem by placing the offending value inside double quotes.
    <BODY BGCOLOR="#123456">

How the Web Works

The World Wide Web has a client/server architecture. This means that a client program running on your computer (your Web browser) requests information from a server program running on another computer somewhere on the Internet. That server then sends the requested data back over the Net to your browser program, which interprets and displays the data on your screen.
  1. You run a Web browser client program on your computer.
  2. You connect to the Internet-at work or school via a direct T1 or T3 line; at home via a modem dial-up connection to an Internet service provider (ISP).
  3. You request a page from a site on the Web. Your browser sends a message over the Internet that includes the following:
    • The transfer protocol (http://)
    • The address, or Uniform Resource Locator (URL)
  4. The server receives your request and retrieves the requested Web page, which is composed in HTML (HyperText Markup Language).
  5. The server then transmits the requested page back across the Internet to your computer.
  6. Your browser program receives the HTML text and displays its interpretation of the page you requested.



The Client Computer

To browse the Web, you need a client computer. There are two basic requirements for this machine: it must have a connection to the Internet and must be capable of running a Web browser program.
The Internet connection can be hard-wired, or it can be a dial-up phone connection via modem to an Internet service provider (ISP). You're most likely to have the former at work or school and the latter at home. The only difference you will notice between the two is speed; otherwise, they work identically.
There are Web browser programs for just about any computer you can name, from dumb text-only terminals running on mainframes to off-brand personal computers, such as the Amiga. (I'll list and discuss the most popular browser programs later in this chapter.)

The Server Computer

On the content-provider side of things, you need a server computer. This machine has requirements similar to those of the client computer: it must be connected to the Internet and must be able to run a Web server program.


However, a Web server needs a more robust Internet connection than a Web client does. A server should ideally be hooked up to the Internet via a fast dedicated T1 or T3 line that remains connected all the time. Otherwise, people trying to access your Web site will often find that it just isn't there.
It is possible (though excruciatingly slow) to run a Web site on a dial-up line, especially if you can find an Internet service provider who will let you stay dialed in 24 hours a day without disconnecting you. However, you must make sure that your ISP can assign a permanent IP address to your machine-not a new IP address each time you connect. Otherwise, people won't even be able to find your site.


HTTPD server software is available for a wide variety of computers  Surprisingly, server computers don't have to be very powerful; serving up Web content is simply not that demanding. More of a concern is having a multithreaded, multitasking operating system so that the server can handle several tasks at once without bogging down. Storage is a concern, however, because Web sites are notorious for growing without limit.

The Wrong Stuff: What Not to Put on the Web

The Bad

Remember to focus. Don't try to be everything to everybody. This is the number two problem of personal sites. They haven't defined who or what they are there for. They spew out whatever pops up in whatever areas interest them at the moment. You might see graphics of motorcycles, rock bands, comic book characters, and computer screens all mixed up like a nightmare collage.
"Wait a minute," you protest, "you said that's the number two problem of personal Web sites. What's number one?"
Even worse than a site that's burdened down with everything is one that contains nothing of interest at all. Many personal sites contain next to nothing: lists of CDs or comic books the person owns; pictures of his dog, gerbil, or fish; fuzzy photos of the site's owner goofing around with friends; and so on. Let's face it; except for a small circle of your very closest friends, nobody but nobody (not even your significant other) wants to know that much about you. So why put it on the Web? It's a waste of bandwidth. It's boring.

Legal Issues

 The first amendment to the U.S. Constitution guarantees every American the right of free speech. This does not guarantee you the right to say anything you want with impunity. People who feel that you have treated them unfairly have legal recourse. You can be sued for libel and/or slander for anything you say online, just as you could if you had printed it on paper. And in this litigious society, it is probably better to err on the side of caution than to strike out boldly and without forethought.
Controversy and debate online are fine, but if you're diplomatic and noninflammatory you'll not only avoid legal battles, you'll attract more sympathizers. After all, you're on the Web to share your ideas, not to entice someone to sue you. Before you post something questionable, consider the following: Even if you're sure you'd win, do you really want to spend your time sitting in court for months on end?
The right to privacy ties in closely with libel and slander issues. If you receive private information about any of your users-through a registration form, for example-you must be very, very careful about how it is used and who has access to it. Though there is no actual law guaranteeing U.S. citizens a right to privacy, there is long-established legal precedent that says it is a basic right implied by the U.S. Constitution. It is best to keep all such information completely private, unless you have asked for and received specific permission to use it publicly.
Perhaps no laws are more openly flaunted on the Web than those concerning copyright and plagiarism. Everyone steals text, graphics, programs, hypertext link lists, HTML code, and everything else from one another pretty freely and openly. However, the most recent U.S. copyright law says that all original creative works in any medium (including electronic) are automatically assigned to their creator when created. No registration is necessary (though it is a good idea, so that ownership can be proven if challenged). Again, it's best to not "borrow" anything at all from anyone else's site, unless you have written permission to do so.
Perhaps no Web-related topic has gotten more press than the issue of adult material on the Web and its accessibility by minors. It is such a hot topic that Congress recently included tough anti-pornography language directed at the Internet in the Telecommunications Act of 1996. Although this law is certain to be challenged in the courts, it has made many ISPs very, very nervous about the content of pages posted through their sites. If you plan to post adult material on your site, you certainly should at least make people enter through a disclaimer page. And make sure you have the permission of your ISP beforehand, or you could be kicked unceremoniously offline at the first hint of controversy. 

A Short Internet Glossary

Although you don't need to know every term that's bantered about on the Internet to be able to work, play, and develop on the Web, an understanding of a few key terms will help you to better understand what's going on there. Here's a short glossary of Internet and Web terms to help you get started.
Backbone  A high-speed network for internetworking computer networks.
Browse  To navigate the World Wide Web. Synonyms: cruise, surf.
Browser  A client program for viewing HTML documents sent by a server over an HTTP connection.
Client  An application or computer that receives and interprets data sent by a matching server computer/application.
CGI  Common Gateway Interface; the way in which Web CGI-BIN scripts are run.
CGI-BIN Script  CGI Binary script; a server-side program that accomplishes a task that cannot be done using HTML. A means of extending the usefulness and versatility of the Web.
Domain Name  The unique name that identifies each Internet site.
E-mail  Electronic Mail; addressed messages sent over a computer network, either automatically or by a human user, to one or more recipients.
FAQ  Frequently Asked Questions list, which attempts to answer the most-asked questions on a given topic. Many are transmitted on a monthly basis over Usenet, and are archived on the Net.
FORM  A subset of HTML tags that can be used to create fields on a Web page to accept input from a user.
FTP  File Transfer Protocol; the TCP/IP protocol for transferring files on the Internet.
GIF  Graphics Interchange Format image, often used on Web pages because of its ability to render a background color as transparent.
Gopher  A client/server application for indexing and retrieving information on the Internet. The predecessor to the World Wide Web.
Hit  An instance of someone (or something, such as a Webcrawler robot indexing program) accessing a Web page.
Hostname  The DNS name for a single computer on the Internet, e.g., www.yahoo.com.
HTML  HyperText Markup Language; the language used to create Web pages.
HTTP  HyperText Transfer Protocol; the client/server protocol for moving hypertext files on the Internet.
Hypertext  Text containing links that, when chosen by a user, will "jump" to another block of text, either in the same document or in another.
Internet  The worldwide network of computers connected by TCP/IP and other internetworking protocols.
IP Address  Internet Protocol address, which is composed of four numbers separated by periods ("dots"), e.g., 198.137.221.9.
ISP  Internet Service Provider; an institution that provides access to the Internet.
JAVA  An interpreted script language developed by Sun Microsystems that resembles C++. It was created to extend the capabilities of the Web by allowing programs to be associated with Web pages that can run on a Web client computer when the page is accessed.
JPEG  Joint Photographic Experts Group; compressed graphics images, often used on Web pages.
LAN  Local Area Network; a computer network limited in scope to a single group of locally interconnected computers.
Link  A user-selectable hypertext or hypermedia jump point, that, when selected, will "jump" to another text or multimedia object.
MIME  Multipurpose Internet Mail Extensions; a means of identifying content in e-mail files and on Web pages. Used by Web browser programs to identify Web page content for proper display.
MPEG  Moving Picture Experts Group; compression algorithm for video and audio files, often used on the Web.
Multimedia  Generic term for integrated, interactive video, audio, text, graphics, database, and other content.
Netscape  Shorthand for the Netscape Communications Corporation's Netscape Navigator WWW browser, generally acknowledged to be the most popular Web browser program today.
Network  A collection of computers connected by LAN, WAN, or Internet.
Newsgroup  A Usenet conference or discussion group.
Node  A single computer connected to a network.
NRE  National Research and Education Network; the entity that will form the backbone for the U.S. potion of the Internet for the near future.
Page  A single HTML document on the Web.
PERL  Practical Extraction Reporting Language; many CGI-BIN scripts on the Web are written in PERL.
POP  Post Office Protocol; the method whereby e-mail is generally transmitted.
Post  To send a message for public display in a Usenet newsgroup.
PPP  Point-to-Point Protocol; one of the protocols that enables a user to create a TCP/IP dialup connection to the Internet via modem.
RFC  Request For Comments; the process of writing a document proposing a new standard for the Internet and then asking for the Net community to comment on it. The standard method for establishing rules and methods on the Internet.
Server  A computer/application that sends data over the network to a matching client computer/program that is capable of properly interpreting that data.
SGML  Standard Generalized Markup Language; the precursor to and a superset of HTML.
SLIP  Serial Line Internet Protocol; an alternative to PPP.
T1  A leased-line Internet connection that operates at 1.5 megabits per second.
T3  A 45 megabit-per-second leased line Internet connection.
Tag  An HTML markup element.
TCP/IP  Transmission Control Protocol/Internet Protocol; the suite of protocols that provides the infrastructure for the Internet.
Telnet  A remote logon program that is part of the TCP/IP protocols.
URL  Uniform Resource Locator; the standard World Wide Web address format, e.g., http://www.google.com.
Usenet  A worldwide system of discussion groups.
VRML  Virtual Reality Modeling Language for creating 3D sites on the Web.
WAIS  Wide Area Information Server, for indexing and accessing great quantities of information on the Net. Often an adjunct to Gopher.
WAN  Wide Area Network; an internetwork of LANs. The Internet is a huge WAN.
WWW  World Wide Web; the portion of the Internet that consists of linked HTML pages.

HTML: The Bricks and Mortar of the Web

Now that you know where the Web came from, it's time to jump into the whole melange feet first-but with your eyes open. HTML (HyperText Markup Language) is what you use to create Web pages, and it's the topic of this book.
HTML is relatively simple in both concept and execution. In fact, if you have ever used a very old word processor, you are already familiar with the concept of a markup language.
In the "good old days" of word processing, if you wanted text to appear in, say, italics, you might surround it with control characters like this:
/Ithis is in italics/I
The "/I" at the beginning would indicate to the word processor that, when printed, the text following should be italicized. The "/I" would turn off italics so that any text afterward would be printed in a normal font. You literally marked up the text for printing just as you would if you were making editing marks on a printed copy with an editor's red pencil.
HTML works in much the same way. If, for example, you want text to appear on a Web page in italics, you mark it like this:
<I>this is in italics</I>
Almost everything you create in HTML relies on marks, or tags, like these.
The rest of this book elaborates on that simple fact. 

Who Uses the Web and for What?

Today, there are over 37 million adults in North America with access to the Internet. 24 million of them actually use their access, and 18 million use their Internet access time to browse the World Wide Web. The total amount of time spent cruising the Web is greater than the time spent using all other Internet services combined, and is roughly equivalent to the time North Americans spend watching rented videotapes.
Some of the survey information used in this section is Copyright 1995 CommerceNet Consortium/Nielsen Media Research.
The number of people using the Internet is increasing so rapidly that if the growth rate were to continue at the current rate, by 2003 every person in the world would be on the Web!
Increasingly, people are using the Web to conduct business. Today, over 50 percent of the sites on the Web are commercial (with a .com domain name). Over half of the users of the Web look for products at least occasionally and-since Web users are predominantly upscale, well educated, and affluent-business is paying attention. Expect Web growth in the near future to continue to be driven and driven hard by business expansion into cyberspace.
But Web surfers also use the Net for more traditional telecommunications purposes. Three-fourths browse the Web. Two-thirds exchange e-mail. One- third download software by FTP. One in three takes part in discussion groups, and one in five is active in multimedia.

Content

The World Wide Web didn't get its name by accident. It truly is a web that encompasses just about every topic in the world. A quick look at the premier topic index on the Web, Yahoo! (http://www.yahoo.com), lists topics as diverse as art, world news, sports, business, libraries, classified advertising, education, TV, science, fitness, and politics (see fig. 1.9). You can't get much more diverse than that! There are literally thousands of sites listed on Yahoo! under each of these topics and many more. 

Domain Names

Computers on the Internet are referenced using IP addresses, which are comprised of a series of four numbers separated by periods (always called dots). Each number is an 8-bit integer (a number from 0-255). For example, the IP address of my Web server at Neural Applications is 198.137.221.9 (verbalized as "one-ninety-eight dot one-thirty-seven dot two-twenty-one dot nine").
However, because addresses composed of nothing but numbers are difficult for humans to remember, in 1983 the University of Wisconsin developed the Domain Name Server (DNS), which was then introduced to the Net during the following year. DNS automatically and invisibly translates names composed of real words into their numeric IP addresses, which makes the Net a lot more user-friendly. To use the same example cited above, the DNS address of Neural's Web server is www.neural.com (pronounced "double-u double-u double-u dot neural dot cahm").
There is no formula for calculating an IP address from a domain name-the correlation must be established by looking one or the other up in a table.
Domain names consist of two or more parts, separated by periods (always, in Internet parlance, pronounced dot). Generally speaking, the leftmost part of the name is the most specific, with sections further to the right more general. A computer may have more than one domain name assigned to it, but any given domain name will "resolve" into only one specific IP address (which is unique for each machine).
Usually, all the machines on one network will share a right-hand and middle domain name portion. For example, you might see computers at one site with the names:
server.grizzly.com
mars.grizzly.com
www.grizzly.com
The leftmost portion of a domain name may indicate its purpose; for example, www. for a Web server or mail. for a mail server.
The rightmost portion of a domain name often indicates the type of site it lives on. The most common domain name extensions are:
.com
Commercial site
.edu
Educational site
.gov
Government site
.mil
Military site
.net
Network service provider
.org
Organization
Other (generally two-letter) extensions indicate a site's country of origin, such as .ca for Canada, .de for Germany, or .fr for France. 

The Internet

With the near-universal changeover to TCP/IP protocols in the years following 1982, the word Internet became the common term for referring to the worldwide network of research, military, and university computers.
In 1983, ARPAnet was divided into ARPAnet and MILNET. MILNET was soon integrated into the Defense Data Network, which had been created in 1982. ARPAnet's role as the network backbone was taken over by NSFNET (the National Science Foundation NETwork), which had been created in 1986 with the aid of NASA and the Department of Energy to provide an improved backbone speed of 56Kbps for interconnecting a new generation of research supercomputers. Connections proliferated, especially to colleges, when in 1989 NSFNET was overhauled for faster T1 line connectivity by IBM, Merit, and MCI. ARPAnet was finally retired in 1990.
In 1993, InterNIC (the Internet Network Information Center) was created by the National Science Foundation to provide information, a directory and database, and registration services to the Internet community. InterNIC is, thus, the closest thing there is to an Internet administrative center. However, InterNIC doesn't dictate Internet policy or run some huge central computer that controls the Net. Its sole purpose is to handle organizational and "bookkeeping" functions, such as assigning Internet addresses (see the sidebar, "Domain Names").

Gopher

Along with e-mail, remote logon, and file transfer, information indexing and retrieval was one of the original big four concepts behind the idea of internetworking.
Though there were a plethora of different data indexing and retrieval experiments in the early days of the Net, none was ubiquitous until, in 1991, Paul Lindner and Mark P. McCahill at the University of Minnesota created Gopher. Though it suffered from an overly cute (but highly descriptive) name, its technique for organizing files under an intuitive menuing system won it instant acceptance on the Net.
Gopher treats all data as a menu, a document, an index, or a Telnet connection. Through Telnet, one Gopher site can access others, making it a true internetwork application capable of delivering data to a user from a multitude of sites via a single interface.
The direct precursor in both concept and function to the World Wide Web, Gopher lacks hypertext links or graphic elements. Its function on the Net is being taken over by the Web, though there are currently still several thousand Gopher sites on the Net, and it will probably be years before Gopher disappears completely. Because so much information is still contained in Gopher databases, the ability to navigate and view Gopherspace is now built into most Web browsers

FTP

The ability to transfer data between computers is central to the inter-networking concept. TCP/IP implements computer-to-computer data transfers thorough FTP (File Transfer Protocol).
An FTP session involves first connecting to and signing on to an FTP server somewhere on the Net. Most public FTP sites allow anonymous FTP. This means you can sign in with the user name anonymous and use your e-mail address as your password. However, some sites are restricted and require the use of an assigned user name and password.
Once in, you can list the files available on the site and move around through the directory structure just as though you were on your own system. When you've found a file of interest, you can transfer it to your computer using the get command (or mget for multiple files). You can also upload files to an FTP site using the put command.
The FTP process was originally designed for text-only UNIX shell style systems. But today, there are many FTP programs available that go way beyond the original FTP capabilities, adding windows, menus, buttons, automated uploading and downloading, site directories, and many more modern amenities.

Individual files on an FTP site are handled according to the way they are defined in your browser's configuration setup, just as though you were browsing a Web site. For example, if you're exploring an FTP site and click the link for a .gif picture file, it will be displayed in the browser window. Text files and HTML encoded files will be displayed too. If you have configured helper applications for sound or video, clicking these types of files will display them using the configured helper applications. Clicking an unconfigured file type will generally bring up a requester asking you to configure a viewer or save the file to disk.
Since you most often want to save files to disk from an FTP site, not view them, you can generally get around all this by using the browser's interactive option to save a file rather than display it. For example, in Netscape you can choose to save a file rather than view it by simply holding down the Shift key before clicking the file's link. 

Telnet

One of the driving forces behind the development of ARPAnet was the desire to afford researchers at various locations the ability to log on to remote computers and run programs. At the time, there were very few computers in existence and only a handful of powerful supercomputers (though the supercomputers of the early 1970s were nowhere near as powerful as the desktop machines of today).
Along with e-mail, remote logon was one of the very first capabilities built into the ARPAnet.
Today, there is less reason for logging on to a remote system and running programs there. Most major government agencies, colleges, and research facilities have their own computers, each of which is as powerful as the computers at other sites.
TCP/IP provides a remote logon capability through the Telnet protocol. Users generally log in to a UNIX shell account on the remote system using a text-based or graphics-based terminal program. With Telnet, the user can list and navigate through directories on the remote system and run programs.
The most popular programs run on shell accounts are probably e-mail programs, such as PINE; Usenet news readers, such as nn or rn; and text editors, such as vi or Emacs. Students are the most common users of Telnet these days; professors, scientists, and administrators are more likely to have a more direct means of access to powerful computers, such as an X Windows terminal.
Most Web browsers don't include built-in Telnet capabilities. Telnet connections are usually established using a stand-alone terminal program, such as that shown in figure 1.4. These programs can also be used by those who want Telnet capabilities on the Web by configuring them as browser helper applications. 

TCP/IP

By the mid-1970s, many government agencies were on the ARPAnet, but each was running on a network developed by the lowest bidder for their specific project. For example, the Army's system was built by DEC, the Air Force's by IBM, and the Navy's by Unisys. All were capable networks, but all spoke different languages. What was clearly needed to make things work smoothly was a set of networking protocols that would tie together disparate networks and enable them to communicate with each other.
In 1974, Vint Cerf and Bob Kahn published a paper titled "A Protocol for Packet Network Internetworking" that detailed a design that would solve the problem. In 1982, this solution was implemented as TCP/IP. TCP stands for Transmission Control Protocol; IP is the abbreviation for Internet Protocol. With the advent of TCP/IP, the word Internet-which is a portmanteau word for interconnected networks-entered the language.
The TCP portion of the TCP/IP provides data transmission verification between client and server: If data is lost or scrambled, TCP triggers retransmission until the errors are corrected.

Note
You've probably heard the term socket mentioned in conjunction with TCP/IP. A socket is a package of subroutines that provide access to TCP/IP protocols. For example, most Windows systems have a file called winsock.dll in the windows/system directory that is required for a Web browser or other communications program to hook up to the Internet.

The IP portion of TCP/IP moves data packets from node to node. It decodes addresses and routes data to designated destinations. The Internet Protocol (IP) is what creates the network of networks, or Internet, by linking systems at different levels. It can be used by small computers to communicate across a LAN (Local Area Network) in the same room or with computer networks around the world. Individual computers connected via a LAN (either Ethernet or token ring) can share the LAN setup with both TCP/IP and other network protocols, such as Novell or Windows for Workgroups. One computer on the LAN then provides the TCP/IP connection to the outside world.
The Department of Defense quickly declared the TCP/IP suite as the standard protocol for internetworking military computers. TCP/IP has been ported to most computer systems, including personal computers, and has become the new standard in internetworking. It is the protocol set that provides the infrastructure for the Internet today.
TCP/IP comprises over 100 different protocols. It includes services for remote logon, file transfers, and data indexing and retrieval, among others.

Introducing the World Wide Web

Contrary to what the media would have you believe, the World Wide Web did not spring into being overnight. Though relatively new in human terms, the Web has a venerable genealogy for a computing technology. It can trace its roots back over 25 years, which is more than half the distance back to the primordial dawn of the electronic computing age.
However, the media is right in noting that the Web's phenomenal growth has so far outstripped that of any of its predecessors that, like a prize hog, it has left almost no room at the trough for any of them anymore. But like that prize hog, the Web is so much bigger and better and so much more valuable than the network technologies that preceded it, there is little reason to mourn the fact that they've been superseded.
In this chapter I'll discuss the history, development, and characteristics of the Web. You'll find out where it came from and what it's good for. If you're the impatient type and you just want to start using HTML to develop Web pages as quickly as possible, you can certainly skip this chapter and jump right in. However, as with all things, a little understanding of the background and underlying structure of the Web will not only enhance your enjoyment of and appreciation for what it is and what it can do, but it might even give you some insights into how to approach the development of your own Web sites.
The Web came out of the Internet, and it is both empowered and limited by the structure of the Internet. Today, most Web browsers include the capability to access other Internet technologies, such as Gopher, e-mail, and Usenet news, as well as the World Wide Web. So the more you know about the Internet as a whole, as well as the Web's place in it, the better you'll understand how to exploit the entire Net to its fullest potential.
Then, too, the Web and the Internet are more than just technology: they are an environment in which the members of an entire cyberculture communicate, trade, and interact. If you hope to establish your own Web site and make yourself a part of that culture, you'd better know what you're getting into. In a way, it's like moving to another country and trying to set up shop; if you don't speak the lingo and learn the customs, you'll never become a part of the community.
In this chapter, you learn about the following:
  • A short history of the Internet, the home of the Web
  • What Net technologies existed before the Web, and how they work alongside the Web today
  • How to decipher Internet e-mail addresses and domain names
  • How and why the Web sprang so suddenly into being
  • How the Web has quickly grown to reign supreme on the Net
  • What's on the Web and why you'll want to develop a presence there

The Genealogy of the Web

In the late 1950s, at the height of the Cold War, the Department of Defense began to worry about what would happen to the nation's communications systems in the event of an atomic war. It was obvious that maintaining communications would be vital to the waging of a worldwide war, but it was also obvious that the very nature of an all-out nuclear conflict would practically guarantee that the nation's existing communications systems would be knocked out.
In 1962, Paul Baran, a researcher at the government's RAND think tank, described a solution to the problem in a paper titled "On Distributed Communications Networks." He proposed a nationwide system of computers connected together using a decentralized network so that if one or more major nodes were destroyed, the rest could dynamically adjust their connections to maintain communications.
If, for example, a computer in Washington, D.C., needed to communicate with one in Los Angeles, it might normally pass the information first to a computer in Kansas City, then on to L.A. But if Kansas City was destroyed or knocked out by an A-bomb blast, the Washington computer could reroute its communications through, say, Chicago instead, and the data would still arrive safely in L.A. (though too late to help the unfortunate citizens of Kansas City).
The proposal was discussed, developed, and expanded by various members of the computing community. In 1969, the first packet-switching network was funded by the Pentagon's Advanced Research Projects Agency (ARPA).

So What's Packet Switching?
Packet switching is a method of breaking up data files into small pieces-usually only a couple of kilobytes or less-called packets, which can then be transmitted to another location. There, the packets are reassembled to re-create the original file. Packets don't have to be transmitted in order or even by the same route. In fact, the same packet can be transmitted by several different routes just in case some don't come through. The receiving software at the other end throws away duplicate packets, checks to see if others haven't come through (and asks the originating computer to try to send them again), sorts them into their original order, and puts them back together again into a duplicate of the original data file. Although this isn't the fastest way to transmit data, it is certainly one of the most reliable.
Packet switching also enables several users to send data over the same connection by interleaving packets from each data stream, routing each to its own particular destination.
Besides the original file data, data packets may include information about where they came from, the places they've visited in transit, and where they're going. The data they contain may be compressed and/or encrypted. Packets almost always also include some kind of information to indicate whether the data that arrives at the destination is the same data that was sent in the first place.

ARPAnet, as it was called, linked four research facilities: the University of California at Los Angeles (UCLA), the Stanford Research Institute (SRI), the University of California at Santa Barbara (UCSB), and the University of Utah. By 1971, ARPAnet had grown to include 15 nodes; there were a grand total of 40 by 1972. That year also marked the creation of the InterNetworking Working Group (INWG), which was needed to establish common protocols for the rapidly growing system.