[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-users] Re: PerClauses
|
Craig,
If you use the percflow(login()) association, your advice to
logout() and authOperations() won't execute at all due to
implicit limiting of the join points (see AJIA page
132-134). I am asumming that you meant to put all the
mentioned pointcuts and advice in AbstractAuthAspect (and
associate it with percflow(login()).
So the question remains is where do you store your
authenticated subjects and how you fetch the right subject
when a an operation matching the authOperation() pointcut
is executed? Session would be a good place as Ron suggests,
but your design does not seem to favor it. I think you still
need to find some sort of "session-like" object.
A few questions that may lead to an answer:
1. Would the sequence of operation be login-op1-op2-...-logout,
all happening in a single thread? If so you can either:
A. Associate the subject with the caller thread
of the login() method.
(use of ThreadLocal would be a good choice).
B. Use percflow() for the join point that surrounds these
sequence of calls. For example, if you have
perform(..) {
login()
op1()
op2() (these may in turn call other operations
directly/indirectly needing authorization
check)
logout()
}
you can associate the aspect with
perfclow(exceution(* perform(..)). Then, you can keep
your subject as an instance variable of the aspect
(no need to use a map).
2. Is subject related to the client machine somehow? And if so
would there be more than one subject concurrently accessing
from a machine?
-Ramnivas
--- Craig Collings <Craig.Collings@xxxxxxxxxxxxxxxxx> wrote:
> 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
>
>
#####################################################################################
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
