Dreamweaver MX 2004 Design Projects Competition Pt.II

Dreamweaver MX 2004 Design Projects is the latest release from friends of ED to cover our favourite web design tool. This new book is a collaborative effort by Rachel Andrew, Craig Grannell, Allan Kent and Christopher Schmitt with each author taking a standard web site type (entertainment/fan site, news portal, external facing corporate website and intranet site) and looking at it from inception to implementation.

Earlier this week we posted an exclusive extract from the book and, as we mentioned before, we are running a book giveaway competition spread over 2 days. 

Today is the second of those days – the extract concerns the database set up for a news portal project and in it authentication is considered; the simple question for today is: 

  • To authenticate an editor in this system, name one of the pieces of information required.

Send this answer, along with the one previously posted on Wednesday along to this e-mail address to be in the virtual hat.

Exclusive Extract from Dreamweaver MX 2004 Design Projects, Rachel Andrew, Craig Grannell, Allan Kent and Christopher Schmitt, friends of Ed, ISBN 1-59059-409-6, 2004, by kind permission of friends of Ed.

Extract taken from Chapter 2: News Portal by Allan Kent

We need to have some way of linking articles together. We could do it through a series of keywords attached to each news story—all you would do then is do a query on the database for stories that have keywords in common with the current story and you would get your related stories, but that could get messy in time and end up with articles linking to one another that are not meant to be linked. You'd also then be doing a textual search across your database, which is not efficient when you have a large number of stories in the database. A better option is to create a table of links—like categories, but more specific.

The news editors can create as many of these as they need to and then when creating a new news story, just link that story to the link item. Any other story also linked to this item would then be linked. As an example, suppose we had a new news story on a sighting of the Loch Ness monster. The editor would create a link item with the name of "Loch Ness Monster". After creating the news article, they would link the story to the Loch Ness Monster link item. In two weeks time, another story comes through about an expedition to chart the bottom of Loch Ness to try and find the monster. This story is also linked to the Loch Ness Monster link item and because both stories are linked to the same link item, they become linked. When we build the page that displays the one story, we search the database for any other stories also linked to this and we'll have our list of related stories.

All we need now is some way of saving the links between news story and link item, and this is the linkmatrix table:

#
# Table structure for table 'linkmatrix'
#

CREATE TABLE linkmatrix (
lm_links_fk int(11) default NULL,
lm_news_fk int(11) default NULL,
KEY lm_links_fk (lm_links_fk),
KEY lm_news_fk (lm_news_fk)
);

Both fields are foreign keys to the links and news tables, and both are indexed to provide quicker searches when looking up related stories.

The last table holds usernames and passwords for the editors so that they can authenticate and add news stories:

#
# Table structure for table 'editors'
#

CREATE TABLE editors (
editor_pk int(11) NOT NULL auto_increment,
editor_username varchar(20) default NULL,
editor_password varchar(20) default NULL,
PRIMARY KEY (editor_pk)
);

The username and password is used to authenticate the editor in the admin section of the site. Since our site is reporting on news stories, we do not need to record which editor entered a particular story—if we wanted to have a system where one editor could not make changes to another editor's story, then we would use the primary key of the editor as a foreign key in the news table to implement some basic security checks.

While we are on the subject of security, we should implement some further security measures on our MySQL server. We do not want to store our root username and password in our configuration files, nor do we want to use it as the username and password that connects to our database from the web application. What we will do now that we have finished creating our database and tables is create a MySQL user that only has rights to the tvnews database. We will then use this user to connect from our web application, and if our site is hacked, the hacker will only gain access to the tvnews database and not every database on our server.

Ian Blackham

Ian BlackhamFollowing a degree in Chemistry and a doctorate in Scanning Tunneling Microscopy, Ian spent several years wrestling with acronyms in industrial R&D (SEM with a side order of EDS, AFM and TEM augmented with a topping of XPS and SIMS and yet more SEM and TEM).

Feeling that he needed a career with more terminology but less high voltages, Ian became a technical/commissioning editor with Wrox Press working on books as diverse as Beg VB Application Development and Professional Java Security. After Wrox's dissolution and a few short term assignments Ian became content manager at DMXzone.

Ian is a refugee from the industrial Black Country having slipped across the border to live in Birmingham. In his spare time he helps out with the website of a local history society, tries to makes sure he does what his wife Kate says, and worries that the little 'un Noah is already more grown up than he is.

See All Postings From Ian Blackham >>