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
smime.p7s
Description: S/MIME cryptographic signature
