Vote for Our Mud on TMC!











help > w > web
Tsunami Web System.

I. Apache Overview

The Tsunami Web System is made up of several components some from within
the Mudlib some from without.  This will generally out line how a client
connection works however.

A web-browser will hit port 80 or 443 of 'www.thebigwave.net' these are
the only two ports that are open to the public.  All traffic must go
through these ports.  The initial request is dispatched by an Apache
webserver that looks at the headers and decides where it should go.  

The DocumentRoot of the default server is /www within the Mudlib, hence
/www/index.php is the same as http://www.thebigwave.net/index.php

a Mod_userdir is enabled that redirects ~NAME to /players/NAME/WWW hence
~wildcat/index.html will be redirected to /players/wildcat/WWW/index.html

The following aliases are also defined:
http://www.thebigwave.net/redmine goes => http://127.0.0.1:8080/redmine
http://www.thebigwave.net/w => /home/thebigwavenet/wiki
http://www.thebigwave.net/wiki => /home/thebigwavenet/wiki/wiki.php
http://www.thebigwave.net/svn => /home/thebigwavenet/viewvc/bin/cgi/
http://www.thebigwave.net/bugs => /www/bugs/bugs.php
http://www.thebigwave.net/bug => /www/bugs/bug.php

The /svn directory and /wizards/secure are also MYSQL protected
requiring a valid login from the DB view tsunami.wizlogin.  To be in
that view a wizard has to have last logged out with a wiz_level >0

II. PHP

The PHP engine in the default web instance is also configured to only
allow execution out of /www.  In addition all file access outside of /
is forbidden.  

The PHP engine has include paths set to /www/include as well as .

There are several important PHP objects to be aware of:

/include/Auth.php call authenticate with a user / password and it will
check against the Tsunami Login DBs to see that the user is valid and if
so will set level, banish status, and group status.  For the most part
this shouldn't be called directly instead use...

/include/SessionAuth.php Invokes Auth.php above, but stores the results
in a session on the server for you to check against later.  Also has a
pseudo-Facebook API.
	$SessionAuth->require_login() - will either succeed if there is
a valid session object, or will display a form asking the user to login.
	$SessionAuth->require_group("groupname") - Same as above but
will fail even if the user is logged in if they aren't ALSO in a defind
group, such as: $SessionAuth->require_group("wizard")
	$SessionAuth->logout() - Destroys the session

/include/ObjectData.php Reads in an LPC save_object and creates a map
out of it.  Note this is read only.
	$ObjectData->load($filename) - Loads/parses the file
	$ObjectData->query($variable) - Returns the variable in the
object

Hacked Together Page System

At some point someone hacked together a page generation system.  The
less said about it the better.  However it's in use.  The way to use it
is to require include/page.php, create a new Page() object, set the
title, set the contents, and then render it.  As an example at this time
/www/index.php in it's entirity looks like:
<?
        require_once("include/page.php");
        require_once("include/SessionAuth.php");
        require_once("include/ChangeBoard.php");

        $session = new SessionAuth;
        $page = new Page();
        $page->set_title("Tsunami - Home");
        $page->set_content_file("index.htm");
        $page->set_var("ChangeBoard", $sChangeBoard);
        $page->render();
?>

The call to set_var allows you to replace variables found in the
template dynamically.  Anyplace in HTML where {ChangeBoard} is found it
will be replaced with the string $sChangeBoard.  In addition to the
variables you specify per page, the following ones are always defined:

        {SessionName} - $session->name (Who is logged in, empty string
if no session)
        
  • Wizard Login
  • - Link to wiz menu if session->group("wizard") is true else empty string {LastModified} "F d Y H:i:s" - Date stamp of when the current rendered page's HTML was last modified. For each php page, a 'template' file is looked for if you specify a 'set_content_file' that file is relative to the working directory of the script with templates added on. IE: /www/index.php will look for /www/templates/index.htm in the above example. This can get confusing at times as there's even the default page that page.php itself loads in called /www/include/templates/page.htm Yes, I hate this system very much. Every page you wish to have displayed with our normal CSS needs a .php as well as a .htm. The only exception is if the PHP is generating all the HTML code completely, then instead of calling set_content_file you can call set_content($sHTML) with the full page to display. III. In game Web objects From within the game, the MUD listens on port 8002 and also has port 8004 to accept connections but the driver doesn't listen on that port. (This is so that a test mud can be brought up and have web connections on port 8004 without having to modify any code.) When master accepts the connection on port 8002, it calls /obj/daemons/httpd::connect() This is just a small object to do bookkeeping on web connections and at this time is very minimal. httpd clones an /obj/daemons/httpd/http_request object who's job it is to parse headers and figure out what cgi-bin to invoke. The list of CGI's we accept is defined in the http_request object. If it is not listed there it will not be accepted even if the object does exist. http_request knows currently of two types of requests a GET that directly invokes an object and a PSEDUO REST get that will pass part of the path as an arg to the cgi. IE: http://www.thebigwave.net:8002/quests?quest=4 vs http://www.thebigwave.net:8002/valid_read/obj/master.c?username=wildcat At some point I hope to support POST queries as well but we do not at this time. When http_request has finished determining what the headers have to say and if everything is valid it will clone a cgi-bin object that was specified in the http_request. The blueprint for the object lives in /obj/daemons/httpd/cgi-bin, and most of the cloned blueprints are in /obj/daemons/httpd/cgi-bin/ This is your primary object that you will inherit to make a new cgi-bin. It defines two functions for you to overload Run() and PrintHeader(). PrintHeader() prints out a standard HTTP header to the socket that's connected, and Run() is invoked by http_request. For the most part the end of your overriden run should call ::Run() to handle cleanup. The cgi-bin has 2 member variables that describe the request, m_sAuth that describes any Basic Authentication found, and m_mRequest that is a mapping of key to value of the request. IV. Tying it together As mentioned, an end user has no direct connection to the HTTPD running within the MUD. If data is needed from the MUD a php script has to act as a pass through. The common pattern for this has been for the web object to assume everyone can access port 8002 (in case we change things in the future) and return URLs relative to that, the php script will invoke said web page via a call to file($sUrl) and then preg_replace the references to 8002 back to itself. IE: /www/who.php: $url = "http://www.thebigwave.net:8002/who"; $content = implode("",(@file($url))); preg_match("/<body[^>]*>(.*)<\/body/si", $content, $matches) && $content = $matches[1]; $content = preg_replace("#http://www.thebigwave.net:8002/who#", "/who.php", $content); -Wildcat 5/10