X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ian/git?a=blobdiff_plain;ds=sidebyside;f=caf.pod;h=53789b3e14d91b072a6100e94aa547016c6fcba5;hb=829bdfa8f56bef52b9eb22d9e4753463cd945dd0;hp=ab45ac096b306a6fdfbb4af03c19de8974909d4d;hpb=cdb13789e4025ebc1ab10ce6784ffad7a222a35a;p=cgi-auth-flexible.git

diff --git a/caf.pod b/caf.pod
index ab45ac0..53789b3 100644
--- a/caf.pod
+++ b/caf.pod
@@ -725,6 +725,28 @@ We should generate a login form.  The user is not yet logged in.
 We should redirect to our actual application, with the specified
 parameters.  (The user has just logged in.)
 
+=item C<STALE>
+
+The user is logged in but the incoming form submission looks like it
+was from a stale login session.  Alternatively, it may have been
+generated by an attacker's cross-site-scripting attack.
+
+Naive applications should generate a small page with a form or link to
+our own main page without any parameters.
+
+A sophisticated application could infer from the submitted form
+parameters what the user was allegedly trying to do.  We could then
+generate a fresh page showing what the intended action was, with a
+fresh form which (if the user confirm) would resubmit that action.
+B<Great care> must be taken to avoid relying on the sanity and
+coherence of the incoming form parameters.  We B<MUST NOT> simply
+reproduce the incoming parameters in the new form.  It is essential
+that the visual appearance of the generated form correctly shows to
+the user what the action is that will be taken if the form is
+submitted.  If that action is dangerous, the form should not look like
+the kind of confirmation pages which the user is likely to simply
+click through without thinking.
+
 =item C<MAINPAGEONLY>
 
 We should generate our main page but B<ignoring all form parameters>
@@ -739,6 +761,9 @@ kind.)
 
 =back
 
+Applications should die if they are presented with a divert kind that
+they don't recognise.
+
 =head1 SETTINGS
 
 C<new_verifier> and C<new_request> each take a list of settings, as