Posted: April 27th, 2010 | Author: amos | Filed under: security, server | Tags: authentication, class 11, htaccess, htpasswd, http | 1 Comment »
Overview
HTTP is the protocol which web browsers and web servers use to communicate via client requests and server responses, respectively. We’ve seen that the browser uses HTTP GET and POST methods to request data from the server.
HTTP also provides a very basic level of authentication which you can use to password-protect your sites or certain folders within your sites. And Apache servers, such as our class server, make it is possible to use this authentication system by simply writing a bit of special code in a file called .htaccess.
We have previously used .htaccess files for rewriting URLs to create Fancy URLs. The .htaccess file is a directory-specific configuration file – it can hold a variety of server settings that apply only to the folder in which you place it. This post is about one such setting.
Password-protecting a folder
To password protect a specific folder, we will create two files: one named .htaccess and another named .htpasswd.
.htaccess holds the server instructions indicating that the folder should be password protected. This file gets placed in the folder which you want to password protect.
.htpasswd holds the username/password combinations of users who are allowed to view the folder. Passwords are encrypted. This gets placed somewhere on the server where it is not accessible from the web – you don’t want people loading this file up directly in their web browsers.
The .htaccess file
The .htaccess file contains the following code.
AuthUserFile <the server path to the folder where your .htpasswd file will live>/.htpasswd
AuthGroupFile /dev/null
AuthName EnterPassword
AuthType Basic
Replace <the server path to the folder where your .htpasswd file will live> with the path to your own .htpasswd file. Ideally this will be somewhere outside of the web root of the server. On the class server, the web root is the folder /home/scps/onepotcooking.com/
As an aside, saying this is the “web root” means that when a user goes to http://onepotcooking.com in their browser, they will by default view the files in the folder /home/scps/onepotcooking.com. The “server root” is /, the very topmost folder on the server.
So, if your name is George Washington, perhaps put your .htpasswd file at
/home/scps/passwords/georgewashington/.htpasswd
so it is outside of the web root, yet still somewhere you might be able to find it again if you ever went looking.
The .htpasswd file
The .htpasswd file will contain one of the following lines for each user that has access to the protected folder:
<username>:<encrypted password>
Replace <username> with the username of the user you want to give access. And replace <encrypted password> with an encrypted password for that user.
How do you get an encrypted password? You use one of the many websites that encrypt your .htpasswd passwords for you for free, such as this one.
So, for example, if your username is “scps” and your encrypted password is “pnzpsMNdWW6aw”, you will put the following line in your .htpasswd file:
scps:pnzpsMNdWW6aw
And you will save this .htpasswd file into the folder that you indicated in the first line of your .htaccess file.
An example
See an example here. The username is our standard username, and the password is our standard password minus the last character. You’ll notice that I have been naughty and put the .htpasswd file in the same folder as the .htaccess file. On a real site you shouldn’t put it anywhere where a web browser can find it.
How it works
Here’s an overview of the steps that are happening behind the scenes to make this system work:
- Your client (most likely your web browser) makes a standard HTTP GET request for a password protected area of the server
- The server looks for any .htaccess file in the requested folder
- The server reads the .htaccess file and sees that the requested file or folder should be password protected
- The server responds to the client with an HTTP HTTP response code indicating that the requested file is password protected.
- The browser is built to know what to do with this response code: it pops up a dialog that the user must fill in with a username and password
- The user fills in the username and password and clicks submit
- The client sends another HTTP GET request to the server, but this time includes the login credentials as extra HTTP headers along with the request.
- The server again looks at the .htaccess file and sees that the requested file or folder is password protected, but this time notices that the client included the necessary login credentials along with the request
- The server responds to the client with the requested page
- The client stores the login credentials the user entered somewhere on the client machine (similar to a cookie) so that next time the page is requested, it doesn’t have to ask the user to enter them again. The client just sends them to the server in the HTTP headers automatically.
Posted: April 25th, 2010 | Author: amos | Filed under: cms | Tags: class 11 | No Comments »
The following CMSs are up and running on our class server. Most of these CMS installations have two distinct web interfaces: one for “end-users”, meaning the website the public sees; and another interface for administrators to manage the content that is displayed on the public site.
Each of these CMS’s can be skinned (a.k.a. themed) to look the way you want them to. I have set them up to use the default styles for starters. For the popular CMS’s, you can often find themes that other designers have made that you can easily use on your own site.
However, if you want to create your own custom theme, rather than using someone else’s, you often will have to spend a good deal of time learning the intricacies of skinning the particular type of cat you have adopted.
These examples are yours. Feel free to play around with them, modify them, etc.
Drupal
Drupal is one of the most popular open-source general-purpose CMS’s.
Joomla
Joomla is one the most popular open-source general-purpose CMS’s.
WordPress
WordPress was originally created as a CMS specifically for blogs. But it has since added features that make it, at this point, a very popular general-purpose CMS.
ZenCart
ZenCart is a CMS designed specifically for e-commerce sites. It provides easy setup of a storefront, shopping cart, and integration with popular payment processing gateways.
Moodle
Moodle is a CMS designed specifically for online learning (e-learning) sites.
MediaWiki
MediaWiki is one example of a wiki platform. It was originally developed as the platform behind Wikipedia, but is now its own product that can be used by independent site operators.
phpBB
phpBB is a popular message board CMS
Indexhibit
Indexhibit is a truly bare-bones CMS that does nothing fancy, but is very easy to use.
ZenPhoto
ZenPhoto is a CMS designed specifically for photo gallery sites.
Posted: April 22nd, 2010 | Author: amos | Filed under: ajax, javascript | Tags: class 10 | No Comments »
AJAX is an acronym that stands for Asynchronous Javascript And XML. It refers to a specific feature of the browsers’ implementations of Javascript that became popular in the first few years of this century because it provided a way in which web pages could load content on demand in reaction to a user’s actions, rather than preloading all content with the initial page load, as had been the norm previously.
Many people in the web industry conflate the terms AJAX and dHTML. Since you are taking this class, you should know the accurate meaning of each of these terms, even if you choose not to stick to the correct meanings when conversing with the ignorant and incorrigible masses.
dHTML
Since Javascript was first introduced into Netscape Navigator in 1995, people have been using it to change the content of web pages. In other words, long before AJAX was even possible, there was dHTML. Dynamic HTML is the technique, which we have already seen, of using Javascript to change the content of the page dynamically. Most typically, this change is in response to a user’s action, such as a click, a mouseover, mouseout, or some other action that changes the appearance of the page in some way. Often, these changes are simply showing and hiding various parts of the content, or changing the styles associated with some of the content.
By preparing Javascript, CSS, and XHTML in just the right way, a website maker can make a page seem to be dynamic and responsive to user actions. dHTML refers to this use of Javascript, in combination with CSS and XHTML, to make a page seem dynamic and responsive.
People don’t use the term dHTML very much anymore, although the dHTML techniques are used more than ever.
AJAX
AJAX refers exclusively to the technique in Javascript whereby Javascript code on a page makes a request to the server without requiring a reload of the entire web page. As we have discussed the client/server relationship, the HTTP GET and HTTP POST methods, persistent data and passing data, we have spoken as if a request to the server is one and the same as the loading a whole web page in the browser. Now you know that there is a way to make requests to the server without requiring the reload of the entire page – it is called AJAX.
After an AJAX request is made from the Javascript code running on the client to the server, the server may respond, as it usually does to any request. The Javascript code that made the request often waits [asynchronously] for that response. Once the response is received from the server, the Javascript code on the client then updates the content of the page dynamically using standard dHTML techniques depending on exactly what response it got back.
People often [inacurrately] use the term AJAX to mean any dHTML, regardless of whether it actually involves a request to the server. The term, AJAX, has been usurped by marketers to indicate any kind of dynamic content.
Conceptually, making an AJAX request is identical to any other request to the web server. The Javascript code makes the request using either HTTP GET or HTTP POST. The client can pass data to the server along with that request, or not. The server can process that request using PHP or some other server-side language, read any data that was passed, do some business logic, and respond appropriately.
According to how AJAX was originally conceived, the server was supposed to respond with some XML code that the browser thean parsed. Practically-speaking, the browser is not especially good at parsing XML, so receiving a response in XML is more work than it’s worth. Today, having the server respond with XML is the exception rather than the rule, although it is still done. However, these days the server is programmed to usually respond either with an XHTML snippet which is then dynamically output on the page by the Javascript script on the client, or the server responds with a Javascript code snippet of its own which is then run by the client.
JQuery
Naturally, Internet Explorer handles making AJAX requests differently from Firefox and the other popular browsers. Once again, JQuery solves this problem by providing a set of functions that normalize the browser differences for us. While you can, of course, use the native Javascript AJAX methods to handle the asynchronous requests to the server, I strongly recommend that you use JQuery or another Javascript framework instead to make your code more reliable across browsers, and to keep it simpler and easier to maintain.
Posted: April 18th, 2010 | Author: amos | Filed under: cms, mysql, php | Tags: class 8 | No Comments »
Working off of the example code from the Basic SQL example files, here is a slightly more sophisticated set of pages that when used together, create a sort of Content Management System for our animals application.
How it works
Here is a user flow diagram outlining how this application fits together. Below the diagram is an overview of each step.
User flow diagram for Basic SQL CMS
read.php
In this version of the files, the pages that handle each of the CRUD commands are all linked together. A user can view the animals stored in the database on the main page, read.php. Read.php simply queries the database for a list of all the rows stored in the animals table, and outputs each of those rows into the XHTML for the page.
The user can click links to “update” or “delete” any individual animal. When they click either of those links, the id of the selected animal is passed in the query string of the link to the corresponding page, either update.php or delete.php.
update.php
Update.php displays a form that the user can use to change the name of the animal that was clicked. The first time this page is loaded, this form is prepopulated with the existing name of the animal that was clicked, which has been retrieved from the database.
The id of the animal and its new name are passed along with another request for update.php once the user clicks the submit button. Update.php this time updates the selected row in the animals table and redirects the user back to read.php, where the user can see the updated list of names.
delete.php
Delete.php simply runs a query that deletes the selected row from the database, and then redirects the user to read.php, where they can see the updated list of animals.
create.php
A user can click a link to “add a new animal” on read.php. This takes them to create.php, where they can enter a new animal name into a form. When they submit the form, the animal name is passed along with another request for create.php.
Create.php this time creates a new row in the database table for the new animal, and then redirects the user to read.php, where they can see the updated list of animals.
Posted: April 11th, 2010 | Author: amos | Filed under: php | Tags: class 7 | No Comments »
One potential problem that you may come across when putting XHTML code inside your PHP files is that the XML declaration tag may confuse the PHP server.
Short tags
Some PHP servers, including ours, are set up to accept “short tags”, which are shortcut versions of some PHP commands. For example, on our server, you can either open your PHP script by writing
<?php
Or you can simplify that to
<?
This is a shortcut, “short tag” version of the opening PHP tag that allows lazy developers to type less.
There is another short tag that replaces the normal “echo” command. For example, a normal echo might look like
<?php echo "arugala"; ?>
And the shortened version of the same command would be
<?= "arugala"; ?>
The problem
A problem arises when we put XHTML code inside a PHP file (a file with the .php extension) because the “xml” tag that we use as the first line of our “bare minimum” XHTML document includes the “<?” in it.
<?xml version="1.0" encoding="utf-8"?>
This confuses the PHP processor, which thinks you intend to use a PHP short tag, which you do not. You will an error message about a “parse error”.
See this problem in action
The solution
The solution is to encapsulate the “<?” characters inside of a PHP echo statement. This way you prevent the PHP processor from thinking that those two characters are the start of a PHP opening tag.
<?php echo "<?"; ?>xml version="1.0" encoding="utf-8"?>
See this solution in action
Why you should use PHP short tags
You may be tempted to use PHP short tags. The conventional wisdom is that it’s a bad idea. This is because not all servers are set up to support them.
So if you at some point move your code from a server that does support them to a server that doesn’t, your code will cease to work.
This does not fit in with our philosophy of writing code using only those practices that are guaranteed to work with a minimum of fuss.
Loading ...