[aspectj-users] Re: PerClauses

[Craig Collings <Craig.Collings@xxxxxxxxxxxxxxxxx>]

Thank you Ron, for such a thoughtful and authoritative reply.

However, I would really like to avoid the use of sessions altogether.

It is part of the design brief that the information server be co-operable
with (and therefore agnostic of) any forseeable delivery protocols. From
which follow these conditions with regard to sessions:

1) Only stateless protocols will require sessions,
2) Auth sessions on the information server will be a subset of sessions
generally,
3) There will be a one-to-one correspondance between Auth sessions and JAAS
Subjects,
4) Sessions will have protocol-specific interfaces not wholly definable at
this time,
5) The sessioning mechanisms will probably be running in a different process
and will, in any case, be a "black box" as far as I am concerned.

If we did go with sessions...

What we could do, at the adoption of a new session type, is use aspects to
ensure its conformance to an interface which we can fully specify right now
:) 

For those platforms requiring sessions, the natural place to pass them into
the auth framework would seem to be the LoginModule CallbackHandler which
would associate a sessionId with the Subject. This may mean a subtype of
CallbackHandler for each protocol adopted - such is life.


But I would really like to avoid the use of sessions at all....
So what I'm thinking of at the moment is:

percflow(login)

where

pointcut login(LoginContext c): target (c) && call(boolean
LoginContext.login());
pointcut logout(LoginContext c): target (c) && call(boolean
LoginContext.logout());
abstract pointcut authOperations();


The task now is to keep this aspect alive until logout so that there exists
precisely one aspect instance per current login:
we will keep the aspect alive by using it as a Map key. 
So within this AbstractAuthAspect:

protected static Map liveSubjects = new HashMap();


after(LoginContext c) returning: login{
    Subject subject = c.getSubject();
    synchronized(AbstractAuthAspect.liveSubjects){
        AbstractAuthAspect.liveSubjects.put(this, subject);
    }
}

after(): logout{
    synchronized(AbstractAuthAspect.liveSubjects){
        Subject subject =
(Subject)AbstractAuthAspect.liveSubjects.remove(this);
        subject = null;
    }
}

around(): authOperations{
    Subject subject = (Subject)AbstractAuthAspect.liveSubjects.get(this);
    // Subject.doAsPrivileged(subject etc....
}

This aspect-subject association differs logically from a simple member
Subject only by using the Map to keep the aspect alive.
It is the associated Subject (one per login) that will be tested for
permissions.

Ok so far, but what I now need to know is:
which live aspect will advise around authOperations and after logout?
All of the live aspects?? (clearly no good)
or just the aspect created for login? (which would be very good)

In other words, by what mechanism is an advice notified that its associated
pointcut has been reached?
And how does this differ under different aspect instantiation schemes?


I hope these questions aren't considered excessively lazy, its just that
documentation is never quite sufficient :)

craig collings
architect
abnamrocraigs.com

#####################################################################################
Notice of Confidential information 
The information contained in this electronic mail is CONFIDENTIAL INFORMATION and may
be LEGALLY PRIVILEGED, intended only for the individual or entity named above. If you
are not the intended recipient, you are hereby notified that the use, dissemination,
distribution, or copying of this document is strictly prohibited. If you have received
this electronic message in error, please immediately notify us by return or telephone
call collect to 07 577 6049) and destroy the original message. Thank you, ABN AMRO Craigs Limited.

This e-mail message has been scanned and cleared by MailMarshal   www.marshalsoftware.com 

#####################################################################################