cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <jer...@media.demon.co.uk>
Subject Re: Access session user data from flow
Date Wed, 10 Dec 2003 13:20:56 GMT

On 9 Dec 2003, at 03:13, Antonio Gallardo wrote:

> Jeremy Quinn dijo:
>>
>> On 8 Dec 2003, at 14:31, Antonio Gallardo wrote:
>>
>>> Upayavira dijo:
>>>> Is it more useful to return a UserHandler than a boolean? The 
>>>> auth.js
>>>> code is experimental, and can thus be changed. If you can supply a
>>>> usecase as to why it should be changed, personally, I'd say go ahead
>>>> and
>>>> commit a change. It is good to have real users using the code, as
>>>> what I
>>>> came up with was just a first iteration.
>>
>> My use-case was that I wanted to read values from the authentication
>> XML in my 'login' script, because we needed to see certain values (eg.
>> the user's full name) outside of the security zone. I read the values 
>> I
>> need and set them as Session Attributes.
>
> I did the same :-D But I think you did it more general. I just added 
> some
> functions to allow this:

Handy

> /* Returns the userID in the session */
> function auth_getUserID() {
>   var handler = "authhandler";
>   var authMgr = null;
>   try {
>     authMgr = 
> cocoon.getComponent(Packages.o.a.c...Authentication....ROLE);
>     // autentication
>     if (authMgr.checkAuthentication(null, handler, null)) {
>       // User already autenticated, get the UserID
>       var userId = authMgr.getState().getHandler().getUserId();
>       return parseInt(userId);
>     }
>   } finally {
>     cocoon.releaseComponent(authMgr);
>   }
>   return null;
> }
>
>> A much better way of handling that IMHO would be to use a FlowScript
>> based authentication pipeline, and set up the Session there. This
>> unfortunately is still alluding us, we still get bizarre errors (null
>> FOM_Request etc.) when attempting this, after much research ..... we
>> now only get it the 2nd time someone logs in  =:'(  (deeply weird).
>
> In our case, we have the code already stable. No problems.

I'd love to see how ....

>
>> Another thing I have done to the flow-auth-fw is to Woodify it .....
>> maybe you'd be more interested in that?
>
> We have "woodified" code too. :-D

Ha!

>>> Hmm... I think this kind of changes will break the authentication for
>>> people that already use it (I am one of them). I prefer to first talk
>>> about this change and if it is OK. Make the change.
>>>
>>> Is this OK?
>>
>> No offence Antonio , but is it a Sample or an API ? :)
>
> Part of them is sample, but there is an auth.js inside the
> authentication-fw block that is not a sample to me. I mean:
>
> org/apache/cocoon/webapps/authentication/flow/javascript/auth.js
>
>> But I am perfectly happy to discuss any changes that might be made 
>> ....
>
> I agree. Lets discuss about it. I think it is a good idea. I don't have
> problem to show the code we did. Is this OK? Then I am sure we can got 
> a
> better support for woody and flow in the auth-fw.

OK, so how to move forward?

Some possible options for the modifications to make:

1) Woodification
2) Flow-base authorisation pipeline
3) i18n
4) utility functions to read authorisation data
5) reject User after a certain number of failed logins
etc.

Some possible options for where to work:

1) Start a new flowscript auth-fw in the scratchpad, intended as a 
replacement for the one in blocks
2) Work on the flowscript auth-fw directly in it's block
3) Put together a new flowscript auth-fw in a Wiki page, to replace the 
block when ready.
etc.

WDYT?

regards Jeremy



Mime
View raw message