-
July 30th, 2002, 06:20 PM
#1
Website Administration
Website Administration and Maintanence by Jethro
------------------------------------------------
Index:
o Introduction
o Updating
o diary.php
o Log Files
o Website Security
o Conclusion
Introduction
------------
This tutorial assumes that you currently have or are thinking of making
your own website. It can be any type of website, from a personal
homepage, to a commercial website for your company.
Updating
--------
Updating is a very important part of being a webmaster. Don't you hate
looking at a website that hasn't been updated for 5 years, or maybe
was created and then *never* updated!
To see when a webpage was last modified, go to that page and in the
Address Bar enter: "javascript:alert(document.lastModified)" (need I
say it? Without the inverted commas) and hit enter. You should see
something like a date and a time. That's the last time the page was
updated.
****
Quick Note: If you are a Windows user, you can use this in folders,
because folders are seamlessy connected to Internet Explorer, as
shells.
****
So, let's say you have a "recent news" page, where you add information
about what's being going on in your world, or todo with your website,
or about the topic which your website is about. This is the type of
page which obviously has to be updated.
But, because you may be updating this page a lot (like everyday for
example), it can be a real pain to have to FTP it everytime and wait
for it to upload.
Here, I have created a PHP script which updates a page with the
information you input. Test it out first and make any neccessary
changes, to suit the look of your website. It saves the need to upload
any files. The information is saved to "diary.html" (which will be
created if it doesn't already exist, saving the need to "chmod" it)
It's called "diary.php", but you can change all that.
****
Note: I tested it out on my Apache web server and it works fine. If you
have any problems with it, just send me an email.
****
PHP Code:
<?php
### diary.php
###
$submit = $HTTP_POST_VARS["submit"];
if ($submit) {
# Format the entry
$entry = $HTTP_POST_VARS["entry"];
$entry = htmlentities($entry);
$entry = stripslashes($entry);
$entry = nl2br($entry);
$date = date("Y-m-d");
# Format the diary page
$html .= "<div align=\"center\"><center>";
$html .= "<table border=2 bordercolor=\"#000000\" bordercolordark=\"#000000\" bordercolorlight=\"#000000\">";
$html .= "<tr>";
$html .= "<th align=\"left\" valign=\"top\" width=\"300\" bgcolor=\"#FFFFFF\">";
$html .= "<p align=\"center\"><font face=\"Fixedsys\">$date</font></p>";
$html .= "</th></tr><tr><td>";
$html .= "<font face=\"Fixedsys\">$entry</font></td></tr></center></div>
";
# Open diary.html
$filename = fopen("diary.html","a+");
if (!$filename) {
echo "Could not open diary.html
";
}
# Write to diary.html
$writeit = fwrite($filename, $html);
if (!$writeit) {
echo "Could not write to diary.html
";
}
# Close diary.html
$close = fclose($filename);
if (!$close) {
echo "Could not close diary.html
";
}
include("diary.html");
exit();
}
else {
?>
<html><head>
<title>Online Diary</title>
<style><!--
input,textarea{font-family:Fixedsys;}
//--></style>
</head><body bgcolor=#ffffff>
<form action=give2diary.php method=post>
<p align=center><font face=fixedsys><u>The Date is: <?php echo date("Y-m-d"); ?></u></font></p>
<center><textarea cols=60 rows=10 name=entry></textarea>
<input type=submit value="Record Entry" name=submit><input type=reset></center></form></body></html>
<?php
exit();
}
### The End
##
##############
?>
Log Files
---------
If you are running your own webserver, you will have logs. If you
didn't know this, I suggest you hurry on down to your logs directory
and gaze in amazement at the huge memory they take up, if not properly
cared for.
Open up "access.log" (or wherever your server keeps it's access logs)
and take a look at it. You will probably see hundreds of lines like
this:
159.445.433.33 - - [30/Jul/2002:16:27:08 +0100] "GET /index.php HTTP/1.1" 404 2746
You can safely delete the contents of this file, however, you might
want to take a look at them first. Is your IP the only one there? If
it is, this is a key indication that your website sucks beyond belief.
Unless of course, you're using your server as a development server,
for testing out CGI or PHP scripts. Then it's okay.
Visit http://www.antionline.com/tools-and-...cate/index.php and
run a few of the IP addresses through it. Are most of the IP addresses
from the same country, or from regions that all speak English? This is
all great marketing info and allows you to find out more about your
target market.
Are some places on your website getting more visits than others? Does
this suprise you? Check that all your links are functioning properly
and make sure that a visitor can get the material you have created
easily and quickly. You know yourself how fickle websurfers are.
If you're getting lot's of hits, congratulations. But now for,
debatebly a much more important log file... the error log!
Open it up. You will see lines like:
[Tue Jul 30 16:47:18 2002] [error] [client 159.84.69.23] File does not exist: c:/program files/apache group/apache/htdocs/oldpage.htm
Why doesn't this page exist? Has it been moved? Renamed? If so, why are
people still accessing it. Dead links are very annoying to come
across. And sometimes it hard to track pages and change links whenever
you alter a page.
To deal with this, you can either check your logs regularily or just
make sure that every link and every reference to that page is edited.
Of course, the log-checking is the easier option (usually), but what
if you don't own the webserver and you are being hosted by an ISP?
They'll hardly give you access to the logs (you can try, but please
send me the email you got back because I'm going through an addiction
of BOFH-style humour at the moment).
A possible solution is to create a custom error 404 script which logs
errors to a local file. Then you can periodically check these logs and
make the according changes.
Log files are very useful tools if you use them right.
Website Security
----------------
An important part of maintaining and administrating a website is making
sure that your server cannot be comprimised because of it.
Many people don't seem to understand that when people connect to a
website you are hosting, they are connecting to your computer, just as
if they were FTPing to TELNETing to you.
****
To show you this, use the command: "TELNET localhost 80" and then when
you are in the terminal, enter "GET /index.php" and hit ENTER. The
HTML contents of your webpage will appear. This is what the browser
does. It gets this information and then converts the HTML to what you
see in the browser window.
****
Here are some possible security threats to your website:
Badly written scripts.
For example if you are using a command such as exec("dir
$HTTP_GET_VARS['directory'] > dir_contents") or something nutty like
that, if someone was to feed a newline character in the "directory"
variable, they could wreak all kinds of havoc. exec() is definitely a
function to skip. If you don't think that this could happen to you, go
to Google and enter "phf bug".
Not encrypting data
This is not so much a threat to your box (well, not usually) as it is
to your visitors and/or customers.
If they entrust you with personal information about themselves, such as
names, email addresses, passwords...etc, the least you could do is
encrypt that data. Valuable information like that is too important to
be leaving around your server, in plaintext.
If you are thinking of starting an E-Business or selling goods online,
where visitors need to give information like credit card numbers, you
might want to do some research into the HTTPS protocol, a much more
secure version of the HTTP protocol.
Buffer Overflows
This is a threat in most scenarios, not just in web development. Make
sure your
Last edited by jethro; April 11th, 2017 at 02:35 PM.
-
August 30th, 2002, 03:18 PM
#2
One minor detail: Instead of "java script:alert(document.lastModified)", type javascript (one word). Antionline won't let you type this, as your browser could interpret this as a javascript command, instead of text...
Your logs are, as Jethro stated, quite valuable. To use them optimally (and if you feel up to it), I would suggest logging your data in a database. ntsa touched this topic in his thread 'Building your own IDS tripwire'. If you are using Apache, there's a somewhat easier method. You could use mod_log_sql, a module for apache that uses your database to store your logs.
There are numberous advantages in logging to databases. GrubbyBaby.com (where you get the module, lists a couple of them:
- Chores like log rotation go away, as you can DELETE records from the SQL database once they are no longer useful. For example, the excellent and popular log-analysis tool Webalizer (http://www.webalizer.com/) does not need historic logs after it has processed them, enabling you to delete older logs.
- People with clusters of web servers (for high availability) will benefit the most -- all their webservers can log to a single SQL database. This obviates the need to collate/interleave the many separate logfiles, which can be highly problematic.
- People acquainted with the power of SQL SELECT statements will know the flexibility of the extraction possibilities at their fingertips.
<more on this topic>
I wish to express my gratitude to the people of Italy. Thank you for inventing pizza.
-
August 30th, 2002, 04:17 PM
#3
Member
ah the wonders of website administration... Thx for the tut Jethro.. i enjoyed reading and learned a few things too! keep it up
-
August 9th, 2006, 08:07 AM
#4
Banned
I really am new to this world and like these simple tut. please dont stop and continue writting
-
August 9th, 2006, 10:13 AM
#5
N3m3siZ, if you see a flashing date on a thread that means it is old and the person has prolly already got their problem solved or their tut made so unless you have something productive to add to the thread try not to bring back a dead thread. Take a look at the AO FAQ and enjoy your stay here!
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
|