Wave Image
















  • 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