In the spirit of KISS

use strict;
use CGI;

my $q = new CGI;

# Set a SESSION persistant cookie. (deleted when browser is closed)
my $cookie = "name=value;path=\";
print $q->header(-cookie => $cookie);

# The cookie value should be some sort of code (encrypted or random), 
+linked
# to a database (or file) variable for validation.

# Read a cookie. And don't forget to verify that it's what you expect.
my $cookie_value = $q->cookie('name');
if ($cookie_value !~ /^\w{23}$/) { print "not a valid cookie\n" }

# Clear a cookie.
# Here you can re-write the cookie with a 'past' date, or simply null 
+it out
# Also clear out the database (or file) variable.
my $cookie = "name=;path=\";
print $q->header(-cookie => $cookie);
[download]

Also take a look a this...
stonehenge

Ah, this looks rather simple indeed. The stonehenge article is pretty useful as well. Thank you!
Just need to find out how I will manage the server-side file storage, but that'll be no problem.

If the documentation for either CGI::Cookie or CGI::Session is not enough to get you started, you probably need to work on your Perl skills before attempting such an ambitious project.

Take a look at the HTTP_COOKIES section for CGI.pm for it's handling of cookies, assuming your web browser accepts headers set by cgi's in the usual (CERN/NCSA) fashion.

Here is a small example:

#!/usr/bin/perl -w -I.
use strict;
use CGI;
use CGI::Cookie;
use CGI::Carp qw/ fatalsToBrowser /;    # TODO - Hide errors.
use CGI::Session;


#
#  New CGI object; used to get access to the cookie(s).
#
my $q       = new CGI;


#
#  Get a CGI::Session object - either completely new, or one previousl
+y
# associated with the given cookie.
#
my $session = CGI::Session->new( 'driver:File',
                 $q->cookie('CGISESSID') || $q->param('CGISESSID') || 
+undef,
                 { Directory => '/tmp' } )
    or die ($CGI::Session::errstr);

#
#  Identifier for this session.
#
my $sessionid = $session->id();

#
#  Retrieve "count" from it.
#
my $count = $session->param("count") || "1";

#
#  Update the count in the session
#
$session->param( "count", ($count+1) );


#
#  Print a sample page showing the visited count:
#
print "Set-Cookie: " .  $q->cookie(
                     -name    => 'CGISESSID',
                     -value   => $sessionid,
                     -expires => '+1d',
                     -path    => '/'
                   ) . "\n";
print "Content-type: text/plain\n\n";

print "You've been here $count times before\n";
[download]

I personally like/prefer setting a sessionid parameter in every URL (or embedding a hidden sessionid parameter in every form).

Cookies can be blocked, whereas an embedded sessionid in urls will be portable across every browser known to man (even lynx), and still offers security, particularly if web pages check the sessionid against the incoming IP address..

an embedded sessionid in urls... still offers security, particularly if web pages check the sessionid against the incoming IP address.

I believe this to be an oversimplification. Different users can have the same apparent IP address thanks to proxy servers. Additionally, as described in "Writing Apache Modules with Perl and C", URLs with session data can leak out to other sites via the HTTP Referer (sic) header if your site links to external resources or if a visitor leaves your site for another.

MSDN Magazine has an document on maintaining session state that points out, "[Embedding session IDs in URLs] is discouraged from the security perspective because cookieless IDs lend themselves better to discovery and spoofing, and to injection by link posting or phishing attacks".

As I see it, there's a balance to be struck between alienating users who don't want to accept cookies and accepting the somewhat heightened risk of using session IDs embedded in URLs in the absence of cookies.

        $perlmonks{seattlejohn} = 'John Clyman';

Yeah, I understand. But *how*!

Manually? CGI.pm? Apache::Cookie? A search on cpan.org shows up 701 results for Cookie, surely one of them will let you get/set them.

My Toronto YAPC buddies Richard Dice and Michael Graham demonstrated CGI::Application::Framework which sounded like it took care of everything you're talking about when it was presented at YAPC 2005 in Toronto. I just checked, and it is available on CPAN, although the warning does state that it's alpha quality software.

The docs look pretty complete, so have a look anyway.

Why are using this "xitami" to develop a cms on? It seems to me the simplest thing in the world would be to start with tried and true ingredients that are known. If you are trying to make bread, Maybe Xitami is better flour then apache, but maybe not many people will know how to work with Xitami flour, therefore.. can't help you?

I may be way off. You tell me.