[dgAIS] Re: Heya;;; continued brainpicking

[david nicol]

I'm CCing this to address@hidden



Jesse wrote:

> > thanks.  Yes. Know anything about authoritative thoughts regarding
> > implementing 402 Payment Req'd?
> 
> Nothing at all. I've never seen that implemented

in 1996 when I started TipJar.com I had an idea of describing the
protocol
in RFC format and trying to get tipjar.int to be the standard internet
transaction clearinghouse

That's still a live dream but the overhead of having to explain the .int
domain to everyone I share it with has got it pretty firmly
backburnered.



> > > > I have realized that NULL and ERROR make AIS clients more
> > > > complex and am changing to a paradigm where Authenticate()
> > > > either returns with a valid identity object or dies, instead
> > > > of returning special identities for the exceptions.
> > >
> > > Make that configurable. really. some perl code makes it really hard
> > > to trap exceptions
> >
> >
> > if it defaults to dying, I guess if the application defines
> > $param{RETURN_NULL} or $param{RETURN_ERROR} to true it would
> > return the crippled identities rather than dieing.  Either that
> > or ship two modules in the package, one that dies and one that returns.
> >
> 
> If you've got an oo interface, a parameter in the constructor would be what 
> I'd want. I'd probably set up somthing like
> on_fault => 'raise_error'
> 
> on_fault => 'return_undef'
> 
> much more extensible


furthermore, do I have the AIS client who wants NULL identities pass the
AIS server a string
specifying "send me a NULL" rather than "get an identity or don't come
back"?  I think
not; I think it is cleaner on both ends to have multiple AIS servers
each with different policies.

Two AIS servers, http://ais.int/ais/ and http://ais.int/ais/firm/ might
behave differently in that
the first would define a NULL AISXML block and the second would serve
the user a log-in page,
and they could share the same single sessionID cookie and database.

The implementation I presented at the conference sends the AIS client a
NULL identity when
working with a nonauthenticated user.  The AIS client is responsible for
directing the user
back to the ais add page.

You generally don't want NULL people roaming around your protected
space, so blocking until
the user provides some credentials makes more sense.  Unless you're just
keeping statistics
on who is wearing their name tag and who isn't, in which case you want
to get NULL identities
for nonauthenticated users.

Maybe the AIS protocol could define two different user->server requests,
"present" which
is the current one, which causes the user to request that the server
define an OTU key and
then redirect him back to the client, and a new one "demand" which works
just like
"present" except that the server MUST get an authentication from the
user and WILL NOT
issue an OTU key for a nonauthenticated user.

That's cleaner than having to define two whole different server
installations (several
scripts) for one little semantics change.

On the server side, one script is going to be doing either one or the
other,
so two modules make sense

use CGI::AIS::Session;  # exports Authenticate(...) which will
                                redirect to ${aissri}present... and
                                will return NULL identity for nonauthenticated 
users
                                will return ERROR identity on server-designated 
errors
                                will die on local configuation problems

and then

use trong; # exports Authenticate(...) which will
                                redirect to ${aissri}demand... and
                                will not return except with a valid identity
                                will die on server-designated errors
                                will die on local configuation problems


The strong version seems more implementor-friendly to me, since the
client implementor
does not need to handle any exceptions unless they really want to. 
Maybe it should
become the default and the current version (the inertia of this standard
is currently
AFAIK two scripts, both by myself) would remain as
CGI::AIS::Session::Weak.