Mailing-List: contact isis-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: isis-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of dkhaywood@gmail.com designates
 74.125.82.43 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:reply-to:organization:user-agent:mime-version
         :to:cc:subject:references:in-reply-to:content-type;
        b=xNP2w+X4GBXhjjPSFH4o8hnZucUrWEN6rgqNSYsSO9IhTULG04fFqgTc6f4eW1EtuB
         ISTDl4q48jlR7/bEaG9g+rObjoE/n8Zf7jP5quqNnduJsB3VioSjxXAKen5k92ToW3qb
         w1LBy1HzH4YXBHfS0KxL5Pj8q9/CM+ePPyxAw=
Message-ID: <4D054D7C.30806@gmail.com>
Date: Sun, 12 Dec 2010 22:32:28 +0000
From: Dan Haywood <dkhaywood@gmail.com>
Reply-To: dan@haywood-associates.co.uk
Organization: Haywood Associates Ltd.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US;
 rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: Michael Schommer <michael@jatomix.de>
CC: isis-dev@incubator.apache.org
Subject: Injecting Services into Authenticators (was: Re: SmokeTest)
References: <AANLkTimH3MFdyonZDWe0K0ezFnLHvX6WxNwzqLyAx4vY@mail.gmail.com>
 <4D0103B3.1040405@gmail.com>
 <AANLkTikGVx+ZeppCpx4-JL5Zeowx3=WzcGk49arm58i+@mail.gmail.com>
 <4D025275.50208@gmail.com>
 <AANLkTikbC0Di8cOd00+dD+-pzbqwTGXhyT+Uxy8fWEuT@mail.gmail.com>
In-Reply-To: <AANLkTikbC0Di8cOd00+dD+-pzbqwTGXhyT+Uxy8fWEuT@mail.gmail.com>
Content-Type: multipart/mixed;
 boundary="------------020806060202080903060803"

--------------020806060202080903060803
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Hi Michael,
(nb: I've cc'ed this to isis-dev, because I think it should get 
visibility there)


On 12/12/2010 22:01, Michael Schommer wrote:
> Hi Dan,
>
> I'm able to inject a Service to an Authenticator.
>
> The AuthenticationManager becomes a new setter
> setServices(List<Object). In the IsisSessionFactoryAbstract.init() I
> call this setter: authenticationManager.setServices(serviceList).
> So the AuthenticationManager "knows" the services.
>
> I move the three methods injectServices, invokeMethod, invokeSetMethod
> from ServicesInjectorAbstract to an UtilClass in the commons package
> called "InjectorUtil".
>
> The method init() from AuthenticationManagerStandard is called bei the
> Framework and there I inject the services to the Authenticators:
>
>   for (Authenticator authenticator : authenticators) {
>              InjectUtil.injectServices(authenticator, serviceList);
>              authenticator.init();
>          }
> 		
> This all works fine.
>
> But ... when I call a method of the injected Service in the
> Authenticator I get a "java.lang.IllegalStateException: No Session
> opened for this thread".
>
> Maybe you can help me a little bit.
>
> Do I need an AuthenticationSession to open an IsisSession or is there
> an other way?
> Can I open a session before the Authenticator is called or is my
> solution completely wrong?
>
Appreciate you spending the time on this.

I'm quite surprised that your service is requiring an IsisSession, 
though I guess it depends on the particular implementation of your 
service.  I was imagining you'd be calling some system-level API outside 
of Isis itself, but given you've got this error, it would seem not?

Anyway, as you correctly surmise, an AuthenticationSession is required 
in order to create an IsisSession.  At least as far as mapping this onto 
webapps, an AuthenticationSession is analogous to an HttpSession, 
whereas an IsisSession is more equivalent to an HttpRequest.  It's 
different on the DnD client, but even then the AuthenticationSession has 
a larger scope than the IsisSession.

It would seem that my concern about scoping is biting us here, even if 
not in quite the way I anticipated.

To answer your question: yes, it is possible to create a "dummy" 
AuthenticationSession.  If you look at the subclasses, you'll see 
InitialisationSession, which we use for installing fixtures.  And 
there's also ExplorationSession, which is used when running in 
exploration mode (ie requiring no login).

By all means have a go at just instantiating one of those and see if you 
can hack something together.  I do think we'll need to review what you 
end up with; I'm guessing it's gonna be something like (all in the 
AuthenticationManager):
- create an InitialisationSession for the purposes of doing authentication
- open an IsisSession using this InitialisationSession
- delegate to the Authenticator and authenticate the credentials
- close the IsisSession
- close the InitialisationSession
- return the "real" AuthenticationSession for use in the main interaction.

... which may work, but does sound rather complicated!

Dan


> Thanks
> Michael
>
>
>
>>
>>> Now, I take a look at the Authenticator this weekend. Writing an
>>> Authenticator is very easy, you're right. But why don�t use Isis for
>>> the security infrastructure. With Isis it�s easy to manage the Users
>>> with Passwords and Roles. So, why don�t inject a service to an
>>> Authenticator?
>> It's not a bad idea, I do admit.  Why don't you raise a ticket on JIRA for
>> us, with a code sketch if how it would work in your current use case?
>>
>> It should be pretty trivial to implement... just looking at the code, the
>> services get instantiated initially and live with PersistenceSessionFactory.
>>   We just need to find a way to give them to the
>> AuthenticationManagerInstaller, from which it could propogate into
>> AuthenticationManager / Authenticator as required.
>>
>> Cheers
>> Dan
>

--------------020806060202080903060803--