HumanConf

graduated limits

search problems

comment checks

submit, login (?)



pollbooth "null"

pollBooth extra checks

remaining problem: the special checks don't allow us

fine-grained control




So here's a list of the forms we have.  Pretty much all forms should have

reskeys.  A short HOWTO follows in a separate message.


I don't include below admin forms, user forms, or moderation/metamod.  The

latter two are being substantially rewritten, and admin can come last: it

is still important to do admin though: we can check is_admin, seclev, and make

sure bad guys aren't forcing us to submit forms we don't want to submit).


Search is getting a big rewrite too, but it shouldn't change the forms

and API.


  zoo - done

  journal (journal, zoo: done; prefs [DO WITH users REWRITE], search: not done)

  email (optout, storyform) [do we care to continue to support this?]

  messages (delete, prefs) - vroom

  pollbooth - done

  search/searchtoo [also in footer] - pater

  submit - done

  subscribe - jamie

  dispStory (ircslash_remarks)

  comments [remove discreate/u?discuss_list]


  metamod, comments-mod [REWRITE]

  users (REWRTIE)

  login (change, login, create, send; userlogin template)

        [DO WITH users REWRITE]

  admin [fun fun fun]


So basically, what needs to get done is messages, pollbooth, search/searchtoo,

submit, subscribe, and dispStory/ircslash_remarks.  Comments comes later, and

then there's the bigger ones at the end.


Rob, do you want to divy this up, or just have me start working on it and then send people to me if they have free time to work on it too?







HOWTO do reskeys?  See zoo.pl and ResKey/mysql_dump.sql for an example.



First, you decide what the name of your resource will be.  So for Zoo, I chose

"zoo", and gave it number "2", which was the next available ID.  Then you

insert a row into the reskey_resources table defining that resource:


  INSERT INTO reskey_resources VALUES (2, 'zoo');



Then you define which Check classes will be used for that resource:


  INSERT INTO reskey_resource_checks VALUES \

  (NULL, 2, 'all', 'Slash::ResKey::Checks::User', 101);

  INSERT INTO reskey_resource_checks VALUES \

  (NULL, 2, 'all', 'Slash::ResKey::Checks::ACL',  201);

  # etc.


This tells Slash::ResKey to do the user check first, then the ACL check, and

so on.  'all' means to apply the check to all types of reskey uses (create,

touch, use).  You can also specify one or another (e.g., we only do the

ProxyScan check for 'use').



Then, finally, you set a bunch of vars.  For instance, if we want only

subscribers to use zoo, we could do:


   INSERT INTO reskey_vars VALUES \

   (2, 'user_is_subscriber', 1, 'Require user to be subscriber');


A full list of available vars is in mysql_dump.sql.


NOTE: you can put the vars in each plugin's SQL file, or in ResKey's.  Could go either way, whatever.  But make sure you add it there, and in the sql/mysql/upgrades file.




NOW THAT that's all set up, you can start adding the reskey code itself.

This is pretty simple too.  When you want to get a key object to work with

(creating a new form, previewing a form, submitting a form), you do this:


my $reskey = getObject('Slash::ResKey');

my $rkey = $reskey->key('zoo');


When you want to create a reskey for use in a new form, do this:


unless ($rkey->create) {

print $rkey->errstr;

return;

}


To handle a key when previewing a form, do this:


unless ($rkey->touch) {

print $rkey->errstr;

return;

}


To handle a key when finally submitting a form, do this:


unless ($rkey->use) {

print $rkey->errstr;

return;

}


You get the idea.  Of course, you may not want to print the errstr right

away, and you may want to do something else other than returning; that's

up to the application.  But that's the bulk of the code.



And in your form, you simply do:


[% PROCESS reskey_tag %]


which picks up the reskey value and constructs the <input type="hidden"

name="reskey" value="[% reskey %]"> stuff.



One other thing I should mention is that there are two types of failure

conditions: failure (non-fatal, recoverable) and death (fatal).  So if

you are submitting a journal entry, for example:


unless ($rkey->use) {

print $rkey->errstr;

if ($rkey->death) {    # fatal

return;

} else {               # try again

showJournalEditForm(@_);

return;

}

}


That's really it.  Pretty simple.  Of course, some of our code is nasty tangled

webs of poo, which means we may need/want to do some reorganization of the

code while we're adding reskey support.  I did that for both zoo and journal.