[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[dgAIS] Re: java client developer

From: David Nicol
Subject: [dgAIS] Re: java client developer
Date: Tue, 12 Mar 2002 13:08:06 -0600

Indrajith Rajapaksa wrote:
> when do I start
> Indrajith

 join the mailing list at

and see what you can do.

I don't know how java modules interact with the rest of
a java program, I suppose it could throw an exception.

the idea for a Perl deliverable is a file that can be
required or used which will take the beginning of an AIS
url as an argument (possibly passed by global variable in
the <code>require</code> use case ) and it dies in a well-defined
way if it can't authenticate, or that may be the AIS service's problem.

Your mission is to design and implement a java client for the
six step handshake.

Research into whether the other dotGNU identity services have
defined inclusion interfaces yet or not is also important -- I
don't think any of them do, there are at least three, and they
all are defined protocols but none have a defined developer
use path as simple as 

        1: install dotgnu::dgAIS from CPAN

        2: include a line

                use dotgnu::dgAIS server => '';

        near the beginning of your Perl CGI program that is concerned
        with creating a session.  (We don't want to impose a handshake
        on every page view, just on session creation -- so we need to
        deliver example code that includes a session model, which is
        also abstracted somehow.)

        3: find an authenticated e-mail identity in the global variable


which is the goal of the dgAIS project.

I'm not clear on the details of writing CGIs in Java; but with
multiple AIS servers around, it would be nice to have the handshakes
triggered by attempts to display a graphic for each one, so a independent
service that subscribes to a set of AIS servers could have a login page
which would start its operation by checking all the AIS servers and
displaying happy or sad doormen for each one.

That means, developing a combined AIS client and session component
that gets invoked something like

        <image src="/bin/aisclient.jpg" height=40 width=40 alt="AIS client 

and operates by doing a six-step handshake and winding up with delivering
either a happy or sad image.  Getting the server programs to request credentials
if you don't have a session already with that AIS server is another open
issue: the reference AIS server does need some work on it too.

So that's the vision: a page on the AIS client domain links to a dynamicly
generated image, and in the process of serving that image, a session object
is created on the AIS client domain, which can be loaded by other programs
on the AIS client domain.

Working with the session object needs to be abstracted so it can be replaced,
something like

        use dotgnu::session expires => $CGI::data{expires}; #YMMV
        $dotgnu::session::user = $dotgnu::dgAIS::Identity

to create a session object and serve a cookie pointing to it


        use dotgnu::session;
        my $user = $dotgnu::session::user;

to access the identity stored in the session object.

           David L Nicol, humble system administrator (816) 235 1187
   Nuclear fission gives off heat, which we use to boil water, which
                 we use to make steam, to spin turbines, to generate
                                  electricity, so we can make toast.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]