This code is related to the creation of accounts rather than logging in - obviously a user cannot login until their account has been created!

Still I think that perhaps you're correct and that instead of having two handlers I should just keep one long one. It just seemed right to make it a two step affair as conceptually it is.

I guess that's just an implementation detail though and it would solve my problems.

Steve
---
steve.org.uk

Having just solved a very similar problem, I would suggest the following pseudocode. What it boils down to is using the query object to pass parameters to the other runmodes.

sub join {
  # This is the 'join' runmode
  my $self = shift;
  my $q = $self->query;

  # It submits to the verify runmode
  if ($self->query->param('error')) {
    # We just tried to submit, but had error(s); print them
  }
  # Print the rest of the form, etc
}

sub verify {
  # 'verify' runmode
  my $self = shift;
  my $q = $self->query;

  # Do error checking
  unless (@errors) {
    # This is how we 'redirect' without redirecting.
    $q->param('username',$username);
    $q->param('password',$password);
    return $self->create;
  } else {
    $q->param(-name => 'error', -value => \@errors);
    return $self->join;
  }
}

sub create {
  # 'create' runmode
  my $self = shift;
  my $q = $self->query;
  # Create the account
  return $self->viewprofile;
}

sub viewprofile {
  # 'viewprofile' runmode
  # ..uses $q->param('username') which is either supplised by the user
+, or
  # by the code in 'verify', which was passed to 'create' and then on
  # to us.
}
[download]

Few comments on your idea: the "create" run mode (or handler) could be invoked directly, is it safe? if you already have a session, why don't you place all sensible data in the session? building URLs by hand may cause some serious problems, try instead with URI->query_form.

The problem here is that the sessions are only really used when the user logs in - so they don't apply in a useful way at the point the account is created.

Building URLs by hand is annoying, though I can use the ->param() function to make sure I've got everything I need.

Steve
---
steve.org.uk

Sure, do an MD5 of the password -- you never want to have the password going anywhere in plaintext. If the password passes your 'tough enough' rules, MD5 it, re-direct to the place where you add the new user and password to the database, and continue.

Later, you should be able to log in using the same MD5 operation on the same password.

Am I missing something obvious?

The problem is that even if the password is hashed the redirect will lead to an URL that is visible to the user.

Which means that they could cheat and bookmark this in the future to create arbitary unvalidated accounts - now at the moment I have a simple scheme to avoid this with the use of sessions, but making this less visible would be a good thing.

Steve
---
steve.org.uk