Http Authentication and user identity problems

[Chris - Stirling]

Hi

I've succesfully implemented http authentication (for a web service)
into my code by following the example here:

http://rifers.org/wiki/display/RIFE/HTTP+authentication

I've changed it slightly to use a database instead of the memory users
participant, and it authenticates users quite happily.

However it doesn't seem to add any user information to the request
state - i.e. getRequestAttribute(Identified.IDENTITY_ATTRIBUTE_NAME)
is always null.

I've found some posts in the groups suggesting that the pattern for
custom authentication has changed and I think I might need to create a
custom CredentialsManager class.  However it seems that this is
_passed_ a Credentials object - and it's too late to take the
username / password from the http header at this stage.

I'm very grateful for any pointers.

(The relevant bit of code is below...)

Thanks

Chris

                private void authoriseUser(String cred_str) throws
SessionManagerException {
                        String[] cred_arr = StringUtils.splitToArray(cred_str, ":");
                        if (2 == cred_arr.length) {
                                String login = cred_arr[0];
                                String password = cred_arr[1];
                                String role = getPropertyString("role");
                                RoleUser credentials = new RoleUser(login, password, role);

                                SessionManager session_manager =
DatabaseSessionsFactory.getInstance(_datasource);
                                DatabaseUsers     credentials_manager =
DatabaseUsersFactory.getInstance(_datasource);

                                HierarchicalProperties props = new HierarchicalProperties();
                                props.put("datasource", _datasource);

                                SessionValidator   validator = new
DatabaseSessionValidatorFactory().getValidator(props);
                                validator.setCredentialsManager(credentials_manager);
                                validator.setSessionManager(session_manager);
                                validator.setRememberManager(null);

                                if (credentials.validate()) {
                                        long userid = credentials_manager.verifyCredentials(credentials);
                                        if (userid >= 0) {
                                                session_manager.startSession(userid, getRemoteAddr(), false);
                                                getLogger().fine("User " + login + " authenticated in role " +
role + ".");

                                                ///////////////////////////////////
                                                //  User identified OK but this is always null
                                                ///////////////////////////////////
                                                RoleUserIdentity identity =
(RoleUserIdentity)getRequestAttribute(Identified.IDENTITY_ATTRIBUTE_NAME);
                                                child();
                                        }
                                }
                                getLogger().warning("Authorisation failed for username " + login +
" for role " + role + ".");
                        }
                }

and the config is like this
<site>
        <globalvar name="authid"/>

        <!-- database and http authenticated /-->
        <element id="HttpAuth"
implementation="com.datadiscoveries.webapp.common.authentication.HttpDbAuthentication">
    <property name="role">admin</property>
    <property name="datasource"><datasource>authentication_datasource</
datasource></property>
        </element>

        <group inherits="HttpAuth">
    <element id="HttpAuthTest" url="httpAuthTest"
implementation="com.datadiscoveries.webapp.common.authentication.TestAuthenticated" /
>
        </group>
</site>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "rife-users" group.
To post to this group, send email to rife-users@...
To unsubscribe from this group, send email to rife-users-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rife-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Joshua Hansen]

Hi Chris,

Typically the RoleUserIdentity object would be _set_ (not retrieved) in
your authentication element, then retrieved in whichever element is
inheriting from your authentication element.

The built in RIFE authentication elements sets the request attribute by
extending Identified, which uses a childtrigger.

For example:
PurgingMemoryAuthenticated extends RoleUserAuthenticated
RoleUserAuthenticated extends Authenticated
Authenticated extends Identified
Identified extends Element

Site definition:
------
        ...
        <globalcookie name="authid"/>
        <element id="AuthSuperAdmin" extends="rife/authenticated/memory.xml">
                <property name="password_encryption">SHA</property>
                <property name="template_name">authentication.admin</property>
                <property name="role">superadmin</property>
                <property name="authvar_type">cookie</property>
       
                <submission name="credentials">
                        <param name="login"/>
                        <param name="password"/>
                </submission>
       
                <childtrigger name="authid"/>
        </element>
        ...
-------

I'm not sure how the new custom authentication system works, but the
underlying concept of needing to have the request attribute set before
being able to retrieve should be pretty solid. :)

Hopefully the above will be somewhat helpful. :)

Josh
--
Joshua Hansen
Up Bear Enterprises
[phone]


Chris wrote:

> Hi
>
> I've succesfully implemented http authentication (for a web service)
> into my code by following the example here:
>
> http://rifers.org/wiki/display/RIFE/HTTP+authentication
>
> I've changed it slightly to use a database instead of the memory users
> participant, and it authenticates users quite happily.
>
> However it doesn't seem to add any user information to the request
> state - i.e. getRequestAttribute(Identified.IDENTITY_ATTRIBUTE_NAME)
> is always null.
>
> I've found some posts in the groups suggesting that the pattern for
> custom authentication has changed and I think I might need to create a
> custom CredentialsManager class.  However it seems that this is
> _passed_ a Credentials object - and it's too late to take the
> username / password from the http header at this stage.
>
> I'm very grateful for any pointers.
>
> (The relevant bit of code is below...)
>
> Thanks
>
> Chris
>
> private void authoriseUser(String cred_str) throws
> SessionManagerException {
> String[] cred_arr = StringUtils.splitToArray(cred_str, ":");
> if (2 == cred_arr.length) {
> String login = cred_arr[0];
> String password = cred_arr[1];
> String role = getPropertyString("role");
> RoleUser credentials = new RoleUser(login, password, role);
>
> SessionManager session_manager =
> DatabaseSessionsFactory.getInstance(_datasource);
> DatabaseUsers     credentials_manager =
> DatabaseUsersFactory.getInstance(_datasource);
>
> HierarchicalProperties props = new HierarchicalProperties();
> props.put("datasource", _datasource);
>
> SessionValidator   validator = new
> DatabaseSessionValidatorFactory().getValidator(props);
> validator.setCredentialsManager(credentials_manager);
> validator.setSessionManager(session_manager);
> validator.setRememberManager(null);
>
> if (credentials.validate()) {
> long userid = credentials_manager.verifyCredentials(credentials);
> if (userid >= 0) {
> session_manager.startSession(userid, getRemoteAddr(), false);
> getLogger().fine("User " + login + " authenticated in role " +
> role + ".");
>
> ///////////////////////////////////
> //  User identified OK but this is always null
> ///////////////////////////////////
> RoleUserIdentity identity =
> (RoleUserIdentity)getRequestAttribute(Identified.IDENTITY_ATTRIBUTE_NAME);
> child();
> }
> }
> getLogger().warning("Authorisation failed for username " + login +
> " for role " + role + ".");
> }
> }
>
> and the config is like this
> <site>
> <globalvar name="authid"/>
>
> <!-- database and http authenticated /-->
> <element id="HttpAuth"
> implementation="com.datadiscoveries.webapp.common.authentication.HttpDbAuthentication">
>     <property name="role">admin</property>
>     <property name="datasource"><datasource>authentication_datasource</
> datasource></property>
> </element>
>
> <group inherits="HttpAuth">
>     <element id="HttpAuthTest" url="httpAuthTest"
> implementation="com.datadiscoveries.webapp.common.authentication.TestAuthenticated" /
> </group>
> </site>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "rife-users" group.
To post to this group, send email to rife-users@...
To unsubscribe from this group, send email to rife-users-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rife-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Chris - Stirling]

Hi Josh

Thanks for your reply.

I've confused you with this:

RoleUserIdentity identity =
(RoleUserIdentity)getRequestAttribute(Identified.IDENTITY_ATTRIBUTE_NAME);

The purpose of this line is to check (in the debugger) whether the
identity has been set - which at this stage it hasn't.

I was expecting it to be set either here:

  - credentials.validate() [DatabaseCredentials.validate()]

or here:

  - session_manager.startSession(userid, getRemoteAddr(), false);
  [DatabaseSessionManager.startSession(...)]

Which are both calls to RIFE classes - so I can't have messed these bits
up :-)

I'll try the childtrigger first thing tomorrow (finished work for the
day now!)

Cheers

Chris




Josh Hansen wrote:

> Hi Chris,
>
> Typically the RoleUserIdentity object would be _set_ (not retrieved) in
> your authentication element, then retrieved in whichever element is
> inheriting from your authentication element.
>
> The built in RIFE authentication elements sets the request attribute by
> extending Identified, which uses a childtrigger.
>
> For example:
> PurgingMemoryAuthenticated extends RoleUserAuthenticated
> RoleUserAuthenticated extends Authenticated
> Authenticated extends Identified
> Identified extends Element
>
> Site definition:
> ------
> ...
> <globalcookie name="authid"/>
> <element id="AuthSuperAdmin" extends="rife/authenticated/memory.xml">
> <property name="password_encryption">SHA</property>
> <property name="template_name">authentication.admin</property>
> <property name="role">superadmin</property>
> <property name="authvar_type">cookie</property>
>
> <submission name="credentials">
> <param name="login"/>
> <param name="password"/>
> </submission>
>
> <childtrigger name="authid"/>
> </element>
> ...
> -------
>
> I'm not sure how the new custom authentication system works, but the
> underlying concept of needing to have the request attribute set before
> being able to retrieve should be pretty solid. :)
>
> Hopefully the above will be somewhat helpful. :)
>
> Josh
> --
> Joshua Hansen
> Up Bear Enterprises
> [phone]
>
>
> Chris wrote:
>> Hi
>>
>> I've succesfully implemented http authentication (for a web service)
>> into my code by following the example here:
>>
>> http://rifers.org/wiki/display/RIFE/HTTP+authentication
>>
>> I've changed it slightly to use a database instead of the memory users
>> participant, and it authenticates users quite happily.
>>
>> However it doesn't seem to add any user information to the request
>> state - i.e. getRequestAttribute(Identified.IDENTITY_ATTRIBUTE_NAME)
>> is always null.
>>
>> I've found some posts in the groups suggesting that the pattern for
>> custom authentication has changed and I think I might need to create a
>> custom CredentialsManager class.  However it seems that this is
>> _passed_ a Credentials object - and it's too late to take the
>> username / password from the http header at this stage.
>>
>> I'm very grateful for any pointers.
>>
>> (The relevant bit of code is below...)
>>
>> Thanks
>>
>> Chris
>>
>> private void authoriseUser(String cred_str) throws
>> SessionManagerException {
>> String[] cred_arr = StringUtils.splitToArray(cred_str, ":");
>> if (2 == cred_arr.length) {
>> String login = cred_arr[0];
>> String password = cred_arr[1];
>> String role = getPropertyString("role");
>> RoleUser credentials = new RoleUser(login, password, role);
>>
>> SessionManager session_manager =
>> DatabaseSessionsFactory.getInstance(_datasource);
>> DatabaseUsers     credentials_manager =
>> DatabaseUsersFactory.getInstance(_datasource);
>>
>> HierarchicalProperties props = new HierarchicalProperties();
>> props.put("datasource", _datasource);
>>
>> SessionValidator   validator = new
>> DatabaseSessionValidatorFactory().getValidator(props);
>> validator.setCredentialsManager(credentials_manager);
>> validator.setSessionManager(session_manager);
>> validator.setRememberManager(null);
>>
>> if (credentials.validate()) {
>> long userid = credentials_manager.verifyCredentials(credentials);
>> if (userid >= 0) {
>> session_manager.startSession(userid, getRemoteAddr(), false);
>> getLogger().fine("User " + login + " authenticated in role " +
>> role + ".");
>>
>> ///////////////////////////////////
>> //  User identified OK but this is always null
>> ///////////////////////////////////
>> RoleUserIdentity identity =
>> (RoleUserIdentity)getRequestAttribute(Identified.IDENTITY_ATTRIBUTE_NAME);
>> child();
>> }
>> }
>> getLogger().warning("Authorisation failed for username " + login +
>> " for role " + role + ".");
>> }
>> }
>>
>> and the config is like this
>> <site>
>> <globalvar name="authid"/>
>>
>> <!-- database and http authenticated /-->
>> <element id="HttpAuth"
>> implementation="com.datadiscoveries.webapp.common.authentication.HttpDbAuthentication">
>>     <property name="role">admin</property>
>>     <property name="datasource"><datasource>authentication_datasource</
>> datasource></property>
>> </element>
>>
>> <group inherits="HttpAuth">
>>     <element id="HttpAuthTest" url="httpAuthTest"
>> implementation="com.datadiscoveries.webapp.common.authentication.TestAuthenticated" /
>> </group>
>> </site>
>>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "rife-users" group.
To post to this group, send email to rife-users@...
To unsubscribe from this group, send email to rife-users-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rife-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Chris - Stirling]

I've managed to get this to work by inserting the following lines of code before calling child() (along with some considerable code changes).

RoleUserAttributes attributes = ((RoleUsersManager)session_validator.getCredentialsManager()).getAttributes(credentials.getLogin());      RoleUserIdentity identity = new RoleUserIdentity(credentials.getLogin(), attributes);
setRequestAttribute(IDENTITY_ATTRIBUTE_NAME, identity);

I think the fundamental problem here is that this approach breaks away from the standard template / element based strategy and in particular doesn't support cookies.  There is probably a better way to do this which fits within the element hierarchy better but I haven't found it!

Thanks to Josh for his input

Chris

On Mon, Jul 28, 2008 at 7:44 PM, Chris Ellis <christian.ellis@...> wrote:

Hi Josh

Thanks for your reply.

I've confused you with this:

RoleUserIdentity identity = (RoleUserIdentity)getRequestAttribute(Identified.IDENTITY_ATTRIBUTE_NAME);

The purpose of this line is to check (in the debugger) whether the identity has been set - which at this stage it hasn't.

I was expecting it to be set either here:

 - credentials.validate() [DatabaseCredentials.validate()]

or here:

 - session_manager.startSession(userid, getRemoteAddr(), false);
 [DatabaseSessionManager.startSession(...)]

Which are both calls to RIFE classes - so I can't have messed these bits up :-)

I'll try the childtrigger first thing tomorrow (finished work for the day now!)

Cheers

Chris

Josh Hansen wrote:

Hi Chris,

Typically the RoleUserIdentity object would be _set_ (not retrieved) in your authentication element, then retrieved in whichever element is inheriting from your authentication element.

The built in RIFE authentication elements sets the request attribute by extending Identified, which uses a childtrigger.

For example:
PurgingMemoryAuthenticated extends RoleUserAuthenticated
RoleUserAuthenticated extends Authenticated
Authenticated extends Identified
Identified extends Element

Site definition:
------
       ...
       <globalcookie name="authid"/>
       <element id="AuthSuperAdmin" extends="rife/authenticated/memory.xml">
               <property name="password_encryption">SHA</property>
               <property name="template_name">authentication.admin</property>
               <property name="role">superadmin</property>
               <property name="authvar_type">cookie</property>
       
               <submission name="credentials">
                       <param name="login"/>
                       <param name="password"/>
               </submission>
       
               <childtrigger name="authid"/>
       </element>
       ...
-------

I'm not sure how the new custom authentication system works, but the underlying concept of needing to have the request attribute set before being able to retrieve should be pretty solid. :)

Hopefully the above will be somewhat helpful. :)

Josh
--
Joshua Hansen
Up Bear Enterprises
[phone]


Chris wrote:

Hi

I've succesfully implemented http authentication (for a web service)
into my code by following the example here:

http://rifers.org/wiki/display/RIFE/HTTP+authentication

I've changed it slightly to use a database instead of the memory users
participant, and it authenticates users quite happily.

However it doesn't seem to add any user information to the request
state - i.e. getRequestAttribute(Identified.IDENTITY_ATTRIBUTE_NAME)
is always null.

I've found some posts in the groups suggesting that the pattern for
custom authentication has changed and I think I might need to create a
custom CredentialsManager class.  However it seems that this is
_passed_ a Credentials object - and it's too late to take the
username / password from the http header at this stage.

I'm very grateful for any pointers.

(The relevant bit of code is below...)

Thanks

Chris

               private void authoriseUser(String cred_str) throws
SessionManagerException {
                       String[] cred_arr = StringUtils.splitToArray(cred_str, ":");
                       if (2 == cred_arr.length) {
                               String login = cred_arr[0];
                               String password = cred_arr[1];
                               String role = getPropertyString("role");
                               RoleUser credentials = new RoleUser(login, password, role);

                               SessionManager session_manager =
DatabaseSessionsFactory.getInstance(_datasource);
                               DatabaseUsers     credentials_manager =
DatabaseUsersFactory.getInstance(_datasource);

                               HierarchicalProperties props = new HierarchicalProperties();
                               props.put("datasource", _datasource);

                               SessionValidator   validator = new
DatabaseSessionValidatorFactory().getValidator(props);
                               validator.setCredentialsManager(credentials_manager);
                               validator.setSessionManager(session_manager);
                               validator.setRememberManager(null);

                               if (credentials.validate()) {
                                       long userid = credentials_manager.verifyCredentials(credentials);
                                       if (userid >= 0) {
                                               session_manager.startSession(userid, getRemoteAddr(), false);
                                               getLogger().fine("User " + login + " authenticated in role " +
role + ".");

                                               ///////////////////////////////////
                                               //  User identified OK but this is always null
                                               ///////////////////////////////////
                                               RoleUserIdentity identity =
(RoleUserIdentity)getRequestAttribute(Identified.IDENTITY_ATTRIBUTE_NAME);
                                               child();
                                       }
                               }
                               getLogger().warning("Authorisation failed for username " + login +
" for role " + role + ".");
                       }
               }

and the config is like this
<site>
       <globalvar name="authid"/>

       <!-- database and http authenticated /-->
       <element id="HttpAuth"
implementation="com.datadiscoveries.webapp.common.authentication.HttpDbAuthentication">
   <property name="role">admin</property>
   <property name="datasource"><datasource>authentication_datasource</
datasource></property>
       </element>

       <group inherits="HttpAuth">
   <element id="HttpAuthTest" url="httpAuthTest"
implementation="com.datadiscoveries.webapp.common.authentication.TestAuthenticated" /
       </group>
</site>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "rife-users" group.
To post to this group, send email to rife-users@...
To unsubscribe from this group, send email to rife-users-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rife-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Joshua Hansen]

Hi Chris,

Good to hear that you got something working. :)

As far as cookies go, a cookie can be a child trigger, and the RIFE
authentication classes support the use of cookies.  In the sample site
definition code I provided, the '<globalcookie name="authid"/>'
statement and the '<property name="authvar_type">cookie</property>' and
'<childtrigger name="authid"/>' element statements for the
AuthSuperAdmin element both indicate this.  The default variable name
for the authentication (in this case a cookie) is "authid", so it's not
explicitly stated in the example I provided.

In the RIFE 1.6.1 source for
'com/uwyn/rife/authentication/elements/Identified.java', the method
'childTriggered(String name, String[] values)' is what handles the
population of the request attribute.

Note that child triggers are currently poorly documented, so I'm taking
some guesses at how these work. :)

By defining the globalcookie 'authid', and then indicating
'<childtrigger name="authid"/>' in the element, RIFE looks at the
submission headers and/or request parameters, then looks through the
site definition for any elements with childtriggers on those items.

In our example, we've defined a cookie 'authid' and a child trigger on
this cookie, so whenever a request is received, if the header includes a
cookie named 'authid', then the element's 'childTriggered(String name,
String[] values)' method is called with name set to 'authid', and values
set to the values of the cookie.  From there, a lookup on the cookie
value is done to get the authenticated information.

The since you are working with both authentication and identification,
you will probably also want to look at the childTriggered(String,
String[]) method in
'com/uwyn/rife/authentication/elements/Authenticated.java', since for
authentication, that is called before Identified.childTriggered(...).

GoogleCode links:
Authenticated.java:589
http://www.google.com/codesearch?hl=en&q=show:tsWyz9b-wWM:a6zwkF4WcRg:tsWyz9b-wWM&sa=N&ct=rd&cs_p=https://svn.rifers.org/rife/trunk&cs_f=src/framework/com/uwyn/rife/authentication/elements/Authenticated.java&start=1

Identified.java
http://www.google.com/codesearch?hl=en&q=show:ToamIvdnc0A:a6zwkF4WcRg:ToamIvdnc0A&sa=N&ct=rd&cs_p=https://svn.rifers.org/rife/trunk&cs_f=src/framework/com/uwyn/rife/authentication/elements/Identified.java&start=1

Hopefully that will help.  I know my understanding is getting
progressively more clear. :)

Josh
--
Joshua Hansen
Up Bear Enterprises
[phone]


Christian Ellis wrote:

> I've managed to get this to work by inserting the following lines of code
> before calling child() (along with some considerable code changes).
>
> RoleUserAttributes attributes =
> ((RoleUsersManager)session_validator.getCredentialsManager()).getAttributes(credentials.getLogin());
>     RoleUserIdentity identity = new RoleUserIdentity(credentials.getLogin(),
> attributes);
> setRequestAttribute(IDENTITY_ATTRIBUTE_NAME, identity);
>
> I think the fundamental problem here is that this approach breaks away from
> the standard template / element based strategy and in particular doesn't
> support cookies.  There is probably a better way to do this which fits
> within the element hierarchy better but I haven't found it!
>
> Thanks to Josh for his input
>
> Chris
>
>
>
> On Mon, Jul 28, 2008 at 7:44 PM, Chris Ellis <christian.ellis@...>wrote:
>
>> Hi Josh
>>
>> Thanks for your reply.
>>
>> I've confused you with this:
>>
>> RoleUserIdentity identity =
>> (RoleUserIdentity)getRequestAttribute(Identified.IDENTITY_ATTRIBUTE_NAME);
>>
>> The purpose of this line is to check (in the debugger) whether the identity
>> has been set - which at this stage it hasn't.
>>
>> I was expecting it to be set either here:
>>
>>  - credentials.validate() [DatabaseCredentials.validate()]
>>
>> or here:
>>
>>  - session_manager.startSession(userid, getRemoteAddr(), false);
>>  [DatabaseSessionManager.startSession(...)]
>>
>> Which are both calls to RIFE classes - so I can't have messed these bits up
>> :-)
>>
>> I'll try the childtrigger first thing tomorrow (finished work for the day
>> now!)
>>
>> Cheers
>>
>> Chris
>>
>>
>>
>>
>>
>> Josh Hansen wrote:
>>
>>> Hi Chris,
>>>
>>> Typically the RoleUserIdentity object would be _set_ (not retrieved) in
>>> your authentication element, then retrieved in whichever element is
>>> inheriting from your authentication element.
>>>
>>> The built in RIFE authentication elements sets the request attribute by
>>> extending Identified, which uses a childtrigger.
>>>
>>> For example:
>>> PurgingMemoryAuthenticated extends RoleUserAuthenticated
>>> RoleUserAuthenticated extends Authenticated
>>> Authenticated extends Identified
>>> Identified extends Element
>>>
>>> Site definition:
>>> ------
>>>        ...
>>>        <globalcookie name="authid"/>
>>>        <element id="AuthSuperAdmin"
>>> extends="rife/authenticated/memory.xml">
>>>                <property name="password_encryption">SHA</property>
>>>                <property
>>> name="template_name">authentication.admin</property>
>>>                <property name="role">superadmin</property>
>>>                <property name="authvar_type">cookie</property>
>>>
>>>                <submission name="credentials">
>>>                        <param name="login"/>
>>>                        <param name="password"/>
>>>                </submission>
>>>
>>>                <childtrigger name="authid"/>
>>>        </element>
>>>        ...
>>> -------
>>>
>>> I'm not sure how the new custom authentication system works, but the
>>> underlying concept of needing to have the request attribute set before being
>>> able to retrieve should be pretty solid. :)
>>>
>>> Hopefully the above will be somewhat helpful. :)
>>>
>>> Josh
>>> --
>>> Joshua Hansen
>>> Up Bear Enterprises
>>> [phone]
>>>
>>>
>>> Chris wrote:
>>>
>>>> Hi
>>>>
>>>> I've succesfully implemented http authentication (for a web service)
>>>> into my code by following the example here:
>>>>
>>>> http://rifers.org/wiki/display/RIFE/HTTP+authentication
>>>>
>>>> I've changed it slightly to use a database instead of the memory users
>>>> participant, and it authenticates users quite happily.
>>>>
>>>> However it doesn't seem to add any user information to the request
>>>> state - i.e. getRequestAttribute(Identified.IDENTITY_ATTRIBUTE_NAME)
>>>> is always null.
>>>>
>>>> I've found some posts in the groups suggesting that the pattern for
>>>> custom authentication has changed and I think I might need to create a
>>>> custom CredentialsManager class.  However it seems that this is
>>>> _passed_ a Credentials object - and it's too late to take the
>>>> username / password from the http header at this stage.
>>>>
>>>> I'm very grateful for any pointers.
>>>>
>>>> (The relevant bit of code is below...)
>>>>
>>>> Thanks
>>>>
>>>> Chris
>>>>
>>>>                private void authoriseUser(String cred_str) throws
>>>> SessionManagerException {
>>>>                        String[] cred_arr =
>>>> StringUtils.splitToArray(cred_str, ":");
>>>>                        if (2 == cred_arr.length) {
>>>>                                String login = cred_arr[0];
>>>>                                String password = cred_arr[1];
>>>>                                String role = getPropertyString("role");
>>>>                                RoleUser credentials = new RoleUser(login,
>>>> password, role);
>>>>
>>>>                                SessionManager session_manager =
>>>> DatabaseSessionsFactory.getInstance(_datasource);
>>>>                                DatabaseUsers     credentials_manager =
>>>> DatabaseUsersFactory.getInstance(_datasource);
>>>>
>>>>                                HierarchicalProperties props = new
>>>> HierarchicalProperties();
>>>>                                props.put("datasource", _datasource);
>>>>
>>>>                                SessionValidator   validator = new
>>>> DatabaseSessionValidatorFactory().getValidator(props);
>>>>
>>>>  validator.setCredentialsManager(credentials_manager);
>>>>
>>>>  validator.setSessionManager(session_manager);
>>>>                                validator.setRememberManager(null);
>>>>
>>>>                                if (credentials.validate()) {
>>>>                                        long userid =
>>>> credentials_manager.verifyCredentials(credentials);
>>>>                                        if (userid >= 0) {
>>>>
>>>>  session_manager.startSession(userid, getRemoteAddr(), false);
>>>>                                                getLogger().fine("User " +
>>>> login + " authenticated in role " +
>>>> role + ".");
>>>>
>>>>
>>>>  ///////////////////////////////////
>>>>                                                //  User identified OK but
>>>> this is always null
>>>>
>>>>  ///////////////////////////////////
>>>>                                                RoleUserIdentity identity
>>>> =
>>>>
>>>> (RoleUserIdentity)getRequestAttribute(Identified.IDENTITY_ATTRIBUTE_NAME);
>>>>                                                child();
>>>>                                        }
>>>>                                }
>>>>                                getLogger().warning("Authorisation failed
>>>> for username " + login +
>>>> " for role " + role + ".");
>>>>                        }
>>>>                }
>>>>
>>>> and the config is like this
>>>> <site>
>>>>        <globalvar name="authid"/>
>>>>
>>>>        <!-- database and http authenticated /-->
>>>>        <element id="HttpAuth"
>>>>
>>>> implementation="com.datadiscoveries.webapp.common.authentication.HttpDbAuthentication">
>>>>    <property name="role">admin</property>
>>>>    <property name="datasource"><datasource>authentication_datasource</
>>>> datasource></property>
>>>>        </element>
>>>>
>>>>        <group inherits="HttpAuth">
>>>>    <element id="HttpAuthTest" url="httpAuthTest"
>>>> implementation="com.datadiscoveries.webapp.common.authentication.TestAuthenticated"
>>>> /
>>>>        </group>
>>>> </site>
>>>>
>>>>
>>>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "rife-users" group.
To post to this group, send email to rife-users@...
To unsubscribe from this group, send email to rife-users-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rife-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Geert Bevin]

Hi Chris,

What you did here is correct. The request attribute, as Josh perfectly
explained, is set by the elements that are responsible for the
authentication. I can see why you would expect
"credentials.validate()" or "session_manager.startSession(userid,
getRemoteAddr(), false);" to perfect this since it looks like a
generic behavior. However, setting a request attribute is purely a web
engine related task, and this should not bleed into the authentication
system itself.

Using the standard Identified element, extending it, or setting the
request attribute expicitly in your own authentication element is
totally correct.

I don't really understand why you bring cookies into the picture. The
request attribute is there so that an element can retrieve the
credentials of an authenticated use at the beginning of the request.
Setting the identity as a request attribute allows any other element
to access this data directly, without having to go through the same
retrieval process. Cookies can contain the authid that allow elements
to lookup the credentials, but storing the credentials in the cookies
is not a good idea for various reason, security being the most
important one.

Hope this helps,

Geert

On Tue, Jul 29, 2008 at 1:52 PM, Christian Ellis
<christian.ellis@...> wrote:

> I've managed to get this to work by inserting the following lines of code
> before calling child() (along with some considerable code changes).
>
> RoleUserAttributes attributes =
> ((RoleUsersManager)session_validator.getCredentialsManager()).getAttributes(credentials.getLogin());
>     RoleUserIdentity identity = new RoleUserIdentity(credentials.getLogin(),
> attributes);
> setRequestAttribute(IDENTITY_ATTRIBUTE_NAME, identity);
>
> I think the fundamental problem here is that this approach breaks away from
> the standard template / element based strategy and in particular doesn't
> support cookies.  There is probably a better way to do this which fits
> within the element hierarchy better but I haven't found it!
>
> Thanks to Josh for his input
>
> Chris
>
>
>
> On Mon, Jul 28, 2008 at 7:44 PM, Chris Ellis <christian.ellis@...>
> wrote:
>>
>> Hi Josh
>>
>> Thanks for your reply.
>>
>> I've confused you with this:
>>
>> RoleUserIdentity identity =
>> (RoleUserIdentity)getRequestAttribute(Identified.IDENTITY_ATTRIBUTE_NAME);
>>
>> The purpose of this line is to check (in the debugger) whether the
>> identity has been set - which at this stage it hasn't.
>>
>> I was expecting it to be set either here:
>>
>>  - credentials.validate() [DatabaseCredentials.validate()]
>>
>> or here:
>>
>>  - session_manager.startSession(userid, getRemoteAddr(), false);
>>  [DatabaseSessionManager.startSession(...)]
>>
>> Which are both calls to RIFE classes - so I can't have messed these bits
>> up :-)
>>
>> I'll try the childtrigger first thing tomorrow (finished work for the day
>> now!)
>>
>> Cheers
>>
>> Chris
>>
>>
>>
>>
>> Josh Hansen wrote:
>>>
>>> Hi Chris,
>>>
>>> Typically the RoleUserIdentity object would be _set_ (not retrieved) in
>>> your authentication element, then retrieved in whichever element is
>>> inheriting from your authentication element.
>>>
>>> The built in RIFE authentication elements sets the request attribute by
>>> extending Identified, which uses a childtrigger.
>>>
>>> For example:
>>> PurgingMemoryAuthenticated extends RoleUserAuthenticated
>>> RoleUserAuthenticated extends Authenticated
>>> Authenticated extends Identified
>>> Identified extends Element
>>>
>>> Site definition:
>>> ------
>>>        ...
>>>        <globalcookie name="authid"/>
>>>        <element id="AuthSuperAdmin"
>>> extends="rife/authenticated/memory.xml">
>>>                <property name="password_encryption">SHA</property>
>>>                <property
>>> name="template_name">authentication.admin</property>
>>>                <property name="role">superadmin</property>
>>>                <property name="authvar_type">cookie</property>
>>>
>>>                <submission name="credentials">
>>>                        <param name="login"/>
>>>                        <param name="password"/>
>>>                </submission>
>>>
>>>                <childtrigger name="authid"/>
>>>        </element>
>>>        ...
>>> -------
>>>
>>> I'm not sure how the new custom authentication system works, but the
>>> underlying concept of needing to have the request attribute set before being
>>> able to retrieve should be pretty solid. :)
>>>
>>> Hopefully the above will be somewhat helpful. :)
>>>
>>> Josh
>>> --
>>> Joshua Hansen
>>> Up Bear Enterprises
>>> [phone]
>>>
>>>
>>> Chris wrote:
>>>>
>>>> Hi
>>>>
>>>> I've succesfully implemented http authentication (for a web service)
>>>> into my code by following the example here:
>>>>
>>>> http://rifers.org/wiki/display/RIFE/HTTP+authentication
>>>>
>>>> I've changed it slightly to use a database instead of the memory users
>>>> participant, and it authenticates users quite happily.
>>>>
>>>> However it doesn't seem to add any user information to the request
>>>> state - i.e. getRequestAttribute(Identified.IDENTITY_ATTRIBUTE_NAME)
>>>> is always null.
>>>>
>>>> I've found some posts in the groups suggesting that the pattern for
>>>> custom authentication has changed and I think I might need to create a
>>>> custom CredentialsManager class.  However it seems that this is
>>>> _passed_ a Credentials object - and it's too late to take the
>>>> username / password from the http header at this stage.
>>>>
>>>> I'm very grateful for any pointers.
>>>>
>>>> (The relevant bit of code is below...)
>>>>
>>>> Thanks
>>>>
>>>> Chris
>>>>
>>>>                private void authoriseUser(String cred_str) throws
>>>> SessionManagerException {
>>>>                        String[] cred_arr =
>>>> StringUtils.splitToArray(cred_str, ":");
>>>>                        if (2 == cred_arr.length) {
>>>>                                String login = cred_arr[0];
>>>>                                String password = cred_arr[1];
>>>>                                String role = getPropertyString("role");
>>>>                                RoleUser credentials = new
>>>> RoleUser(login, password, role);
>>>>
>>>>                                SessionManager session_manager =
>>>> DatabaseSessionsFactory.getInstance(_datasource);
>>>>                                DatabaseUsers     credentials_manager =
>>>> DatabaseUsersFactory.getInstance(_datasource);
>>>>
>>>>                                HierarchicalProperties props = new
>>>> HierarchicalProperties();
>>>>                                props.put("datasource", _datasource);
>>>>
>>>>                                SessionValidator   validator = new
>>>> DatabaseSessionValidatorFactory().getValidator(props);
>>>>
>>>>  validator.setCredentialsManager(credentials_manager);
>>>>
>>>>  validator.setSessionManager(session_manager);
>>>>                                validator.setRememberManager(null);
>>>>
>>>>                                if (credentials.validate()) {
>>>>                                        long userid =
>>>> credentials_manager.verifyCredentials(credentials);
>>>>                                        if (userid >= 0) {
>>>>
>>>>  session_manager.startSession(userid, getRemoteAddr(), false);
>>>>                                                getLogger().fine("User "
>>>> + login + " authenticated in role " +
>>>> role + ".");
>>>>
>>>>
>>>>  ///////////////////////////////////
>>>>                                                //  User identified OK
>>>> but this is always null
>>>>
>>>>  ///////////////////////////////////
>>>>                                                RoleUserIdentity identity
>>>> =
>>>>
>>>> (RoleUserIdentity)getRequestAttribute(Identified.IDENTITY_ATTRIBUTE_NAME);
>>>>                                                child();
>>>>                                        }
>>>>                                }
>>>>                                getLogger().warning("Authorisation failed
>>>> for username " + login +
>>>> " for role " + role + ".");
>>>>                        }
>>>>                }
>>>>
>>>> and the config is like this
>>>> <site>
>>>>        <globalvar name="authid"/>
>>>>
>>>>        <!-- database and http authenticated /-->
>>>>        <element id="HttpAuth"
>>>>
>>>> implementation="com.datadiscoveries.webapp.common.authentication.HttpDbAuthentication">
>>>>    <property name="role">admin</property>
>>>>    <property name="datasource"><datasource>authentication_datasource</
>>>> datasource></property>
>>>>        </element>
>>>>
>>>>        <group inherits="HttpAuth">
>>>>    <element id="HttpAuthTest" url="httpAuthTest"
>>>>
>>>> implementation="com.datadiscoveries.webapp.common.authentication.TestAuthenticated"
>>>> /
>>>>        </group>
>>>> </site>
>>>>
>>>
>>>
>>>
>
>
> >
>

--
Geert Bevin
Terracotta - http://www.terracotta.org
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "rife-users" group.
To post to this group, send email to rife-users@...
To unsubscribe from this group, send email to rife-users-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rife-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Geert Bevin]

Thanks a lot for all your help Josh, it's really appreciated.

About child triggers, these are merely a method to quickly drop down
to a child element based on key value pairs, typically for
authentication. Initially it could seem bizarre that there's a
dedicate feature for this since you can achieve the same behavior by
just performing checks inside the processElement() method. However,
the benefit is that RIFE records all the child triggers and exit
triggers that have been ... euhm triggered ;-) This 'trail' towards to
active element is preserved and allows complex site structure flows to
work seemlessly.

Hope this helps,

Geert

On Tue, Jul 29, 2008 at 6:59 PM, Josh Hansen <joshuah@...> wrote:

>
> Hi Chris,
>
> Good to hear that you got something working. :)
>
> As far as cookies go, a cookie can be a child trigger, and the RIFE
> authentication classes support the use of cookies.  In the sample site
> definition code I provided, the '<globalcookie name="authid"/>'
> statement and the '<property name="authvar_type">cookie</property>' and
> '<childtrigger name="authid"/>' element statements for the
> AuthSuperAdmin element both indicate this.  The default variable name
> for the authentication (in this case a cookie) is "authid", so it's not
> explicitly stated in the example I provided.
>
> In the RIFE 1.6.1 source for
> 'com/uwyn/rife/authentication/elements/Identified.java', the method
> 'childTriggered(String name, String[] values)' is what handles the
> population of the request attribute.
>
> Note that child triggers are currently poorly documented, so I'm taking
> some guesses at how these work. :)
>
> By defining the globalcookie 'authid', and then indicating
> '<childtrigger name="authid"/>' in the element, RIFE looks at the
> submission headers and/or request parameters, then looks through the
> site definition for any elements with childtriggers on those items.
>
> In our example, we've defined a cookie 'authid' and a child trigger on
> this cookie, so whenever a request is received, if the header includes a
> cookie named 'authid', then the element's 'childTriggered(String name,
> String[] values)' method is called with name set to 'authid', and values
> set to the values of the cookie.  From there, a lookup on the cookie
> value is done to get the authenticated information.
>
> The since you are working with both authentication and identification,
> you will probably also want to look at the childTriggered(String,
> String[]) method in
> 'com/uwyn/rife/authentication/elements/Authenticated.java', since for
> authentication, that is called before Identified.childTriggered(...).
>
> GoogleCode links:
> Authenticated.java:589
> http://www.google.com/codesearch?hl=en&q=show:tsWyz9b-wWM:a6zwkF4WcRg:tsWyz9b-wWM&sa=N&ct=rd&cs_p=https://svn.rifers.org/rife/trunk&cs_f=src/framework/com/uwyn/rife/authentication/elements/Authenticated.java&start=1
>
> Identified.java
> http://www.google.com/codesearch?hl=en&q=show:ToamIvdnc0A:a6zwkF4WcRg:ToamIvdnc0A&sa=N&ct=rd&cs_p=https://svn.rifers.org/rife/trunk&cs_f=src/framework/com/uwyn/rife/authentication/elements/Identified.java&start=1
>
> Hopefully that will help.  I know my understanding is getting
> progressively more clear. :)
>
> Josh
> --
> Joshua Hansen
> Up Bear Enterprises
> [phone]
>
>
> Christian Ellis wrote:
>> I've managed to get this to work by inserting the following lines of code
>> before calling child() (along with some considerable code changes).
>>
>> RoleUserAttributes attributes =
>> ((RoleUsersManager)session_validator.getCredentialsManager()).getAttributes(credentials.getLogin());
>>     RoleUserIdentity identity = new RoleUserIdentity(credentials.getLogin(),
>> attributes);
>> setRequestAttribute(IDENTITY_ATTRIBUTE_NAME, identity);
>>
>> I think the fundamental problem here is that this approach breaks away from
>> the standard template / element based strategy and in particular doesn't
>> support cookies.  There is probably a better way to do this which fits
>> within the element hierarchy better but I haven't found it!
>>
>> Thanks to Josh for his input
>>
>> Chris
>>
>>
>>
>> On Mon, Jul 28, 2008 at 7:44 PM, Chris Ellis <christian.ellis@...>wrote:
>>
>>> Hi Josh
>>>
>>> Thanks for your reply.
>>>
>>> I've confused you with this:
>>>
>>> RoleUserIdentity identity =
>>> (RoleUserIdentity)getRequestAttribute(Identified.IDENTITY_ATTRIBUTE_NAME);
>>>
>>> The purpose of this line is to check (in the debugger) whether the identity
>>> has been set - which at this stage it hasn't.
>>>
>>> I was expecting it to be set either here:
>>>
>>>  - credentials.validate() [DatabaseCredentials.validate()]
>>>
>>> or here:
>>>
>>>  - session_manager.startSession(userid, getRemoteAddr(), false);
>>>  [DatabaseSessionManager.startSession(...)]
>>>
>>> Which are both calls to RIFE classes - so I can't have messed these bits up
>>> :-)
>>>
>>> I'll try the childtrigger first thing tomorrow (finished work for the day
>>> now!)
>>>
>>> Cheers
>>>
>>> Chris
>>>
>>>
>>>
>>>
>>>
>>> Josh Hansen wrote:
>>>
>>>> Hi Chris,
>>>>
>>>> Typically the RoleUserIdentity object would be _set_ (not retrieved) in
>>>> your authentication element, then retrieved in whichever element is
>>>> inheriting from your authentication element.
>>>>
>>>> The built in RIFE authentication elements sets the request attribute by
>>>> extending Identified, which uses a childtrigger.
>>>>
>>>> For example:
>>>> PurgingMemoryAuthenticated extends RoleUserAuthenticated
>>>> RoleUserAuthenticated extends Authenticated
>>>> Authenticated extends Identified
>>>> Identified extends Element
>>>>
>>>> Site definition:
>>>> ------
>>>>        ...
>>>>        <globalcookie name="authid"/>
>>>>        <element id="AuthSuperAdmin"
>>>> extends="rife/authenticated/memory.xml">
>>>>                <property name="password_encryption">SHA</property>
>>>>                <property
>>>> name="template_name">authentication.admin</property>
>>>>                <property name="role">superadmin</property>
>>>>                <property name="authvar_type">cookie</property>
>>>>
>>>>                <submission name="credentials">
>>>>                        <param name="login"/>
>>>>                        <param name="password"/>
>>>>                </submission>
>>>>
>>>>                <childtrigger name="authid"/>
>>>>        </element>
>>>>        ...
>>>> -------
>>>>
>>>> I'm not sure how the new custom authentication system works, but the
>>>> underlying concept of needing to have the request attribute set before being
>>>> able to retrieve should be pretty solid. :)
>>>>
>>>> Hopefully the above will be somewhat helpful. :)
>>>>
>>>> Josh
>>>> --
>>>> Joshua Hansen
>>>> Up Bear Enterprises
>>>> [phone]
>>>>
>>>>
>>>> Chris wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> I've succesfully implemented http authentication (for a web service)
>>>>> into my code by following the example here:
>>>>>
>>>>> http://rifers.org/wiki/display/RIFE/HTTP+authentication
>>>>>
>>>>> I've changed it slightly to use a database instead of the memory users
>>>>> participant, and it authenticates users quite happily.
>>>>>
>>>>> However it doesn't seem to add any user information to the request
>>>>> state - i.e. getRequestAttribute(Identified.IDENTITY_ATTRIBUTE_NAME)
>>>>> is always null.
>>>>>
>>>>> I've found some posts in the groups suggesting that the pattern for
>>>>> custom authentication has changed and I think I might need to create a
>>>>> custom CredentialsManager class.  However it seems that this is
>>>>> _passed_ a Credentials object - and it's too late to take the
>>>>> username / password from the http header at this stage.
>>>>>
>>>>> I'm very grateful for any pointers.
>>>>>
>>>>> (The relevant bit of code is below...)
>>>>>
>>>>> Thanks
>>>>>
>>>>> Chris
>>>>>
>>>>>                private void authoriseUser(String cred_str) throws
>>>>> SessionManagerException {
>>>>>                        String[] cred_arr =
>>>>> StringUtils.splitToArray(cred_str, ":");
>>>>>                        if (2 == cred_arr.length) {
>>>>>                                String login = cred_arr[0];
>>>>>                                String password = cred_arr[1];
>>>>>                                String role = getPropertyString("role");
>>>>>                                RoleUser credentials = new RoleUser(login,
>>>>> password, role);
>>>>>
>>>>>                                SessionManager session_manager =
>>>>> DatabaseSessionsFactory.getInstance(_datasource);
>>>>>                                DatabaseUsers     credentials_manager =
>>>>> DatabaseUsersFactory.getInstance(_datasource);
>>>>>
>>>>>                                HierarchicalProperties props = new
>>>>> HierarchicalProperties();
>>>>>                                props.put("datasource", _datasource);
>>>>>
>>>>>                                SessionValidator   validator = new
>>>>> DatabaseSessionValidatorFactory().getValidator(props);
>>>>>
>>>>>  validator.setCredentialsManager(credentials_manager);
>>>>>
>>>>>  validator.setSessionManager(session_manager);
>>>>>                                validator.setRememberManager(null);
>>>>>
>>>>>                                if (credentials.validate()) {
>>>>>                                        long userid =
>>>>> credentials_manager.verifyCredentials(credentials);
>>>>>                                        if (userid >= 0) {
>>>>>
>>>>>  session_manager.startSession(userid, getRemoteAddr(), false);
>>>>>                                                getLogger().fine("User " +
>>>>> login + " authenticated in role " +
>>>>> role + ".");
>>>>>
>>>>>
>>>>>  ///////////////////////////////////
>>>>>                                                //  User identified OK but
>>>>> this is always null
>>>>>
>>>>>  ///////////////////////////////////
>>>>>                                                RoleUserIdentity identity
>>>>> =
>>>>>
>>>>> (RoleUserIdentity)getRequestAttribute(Identified.IDENTITY_ATTRIBUTE_NAME);
>>>>>                                                child();
>>>>>                                        }
>>>>>                                }
>>>>>                                getLogger().warning("Authorisation failed
>>>>> for username " + login +
>>>>> " for role " + role + ".");
>>>>>                        }
>>>>>                }
>>>>>
>>>>> and the config is like this
>>>>> <site>
>>>>>        <globalvar name="authid"/>
>>>>>
>>>>>        <!-- database and http authenticated /-->
>>>>>        <element id="HttpAuth"
>>>>>
>>>>> implementation="com.datadiscoveries.webapp.common.authentication.HttpDbAuthentication">
>>>>>    <property name="role">admin</property>
>>>>>    <property name="datasource"><datasource>authentication_datasource</
>>>>> datasource></property>
>>>>>        </element>
>>>>>
>>>>>        <group inherits="HttpAuth">
>>>>>    <element id="HttpAuthTest" url="httpAuthTest"
>>>>> implementation="com.datadiscoveries.webapp.common.authentication.TestAuthenticated"
>>>>> /
>>>>>        </group>
>>>>> </site>
>>>>>
>>>>>
>>>>
>>
>> >
>>
>
> >
>

--
Geert Bevin
Terracotta - http://www.terracotta.org
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "rife-users" group.
To post to this group, send email to rife-users@...
To unsubscribe from this group, send email to rife-users-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rife-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Joshua Hansen]

Hi Geert,

Thanks! :)

I apologize -- my comment about child triggers being poorly documented
wasn't intended to imply they are a poor feature.  In fact, I think they
are quite neat.  Their use in the authentication system, along with the
inheritance system, provides a concrete example of a how an aspect
oriented solution can reduce effort and increase maintainability.

All the best, :)

Josh
--
Joshua Hansen
Up Bear Enterprises
[phone]


Geert Bevin wrote:

> Thanks a lot for all your help Josh, it's really appreciated.
>
> About child triggers, these are merely a method to quickly drop down
> to a child element based on key value pairs, typically for
> authentication. Initially it could seem bizarre that there's a
> dedicate feature for this since you can achieve the same behavior by
> just performing checks inside the processElement() method. However,
> the benefit is that RIFE records all the child triggers and exit
> triggers that have been ... euhm triggered ;-) This 'trail' towards to
> active element is preserved and allows complex site structure flows to
> work seemlessly.
>
> Hope this helps,
>
> Geert
>
> On Tue, Jul 29, 2008 at 6:59 PM, Josh Hansen <joshuah@...> wrote:
>> Hi Chris,
>>
>> Good to hear that you got something working. :)
>>
>> As far as cookies go, a cookie can be a child trigger, and the RIFE
>> authentication classes support the use of cookies.  In the sample site
>> definition code I provided, the '<globalcookie name="authid"/>'
>> statement and the '<property name="authvar_type">cookie</property>' and
>> '<childtrigger name="authid"/>' element statements for the
>> AuthSuperAdmin element both indicate this.  The default variable name
>> for the authentication (in this case a cookie) is "authid", so it's not
>> explicitly stated in the example I provided.
>>
>> In the RIFE 1.6.1 source for
>> 'com/uwyn/rife/authentication/elements/Identified.java', the method
>> 'childTriggered(String name, String[] values)' is what handles the
>> population of the request attribute.
>>
>> Note that child triggers are currently poorly documented, so I'm taking
>> some guesses at how these work. :)
>>
>> By defining the globalcookie 'authid', and then indicating
>> '<childtrigger name="authid"/>' in the element, RIFE looks at the
>> submission headers and/or request parameters, then looks through the
>> site definition for any elements with childtriggers on those items.
>>
>> In our example, we've defined a cookie 'authid' and a child trigger on
>> this cookie, so whenever a request is received, if the header includes a
>> cookie named 'authid', then the element's 'childTriggered(String name,
>> String[] values)' method is called with name set to 'authid', and values
>> set to the values of the cookie.  From there, a lookup on the cookie
>> value is done to get the authenticated information.
>>
>> The since you are working with both authentication and identification,
>> you will probably also want to look at the childTriggered(String,
>> String[]) method in
>> 'com/uwyn/rife/authentication/elements/Authenticated.java', since for
>> authentication, that is called before Identified.childTriggered(...).
>>
>> GoogleCode links:
>> Authenticated.java:589
>> http://www.google.com/codesearch?hl=en&q=show:tsWyz9b-wWM:a6zwkF4WcRg:tsWyz9b-wWM&sa=N&ct=rd&cs_p=https://svn.rifers.org/rife/trunk&cs_f=src/framework/com/uwyn/rife/authentication/elements/Authenticated.java&start=1
>>
>> Identified.java
>> http://www.google.com/codesearch?hl=en&q=show:ToamIvdnc0A:a6zwkF4WcRg:ToamIvdnc0A&sa=N&ct=rd&cs_p=https://svn.rifers.org/rife/trunk&cs_f=src/framework/com/uwyn/rife/authentication/elements/Identified.java&start=1
>>
>> Hopefully that will help.  I know my understanding is getting
>> progressively more clear. :)
>>
>> Josh
>> --
>> Joshua Hansen
>> Up Bear Enterprises
>> [phone]
>>
>>
>> Christian Ellis wrote:
>>> I've managed to get this to work by inserting the following lines of code
>>> before calling child() (along with some considerable code changes).
>>>
>>> RoleUserAttributes attributes =
>>> ((RoleUsersManager)session_validator.getCredentialsManager()).getAttributes(credentials.getLogin());
>>>     RoleUserIdentity identity = new RoleUserIdentity(credentials.getLogin(),
>>> attributes);
>>> setRequestAttribute(IDENTITY_ATTRIBUTE_NAME, identity);
>>>
>>> I think the fundamental problem here is that this approach breaks away from
>>> the standard template / element based strategy and in particular doesn't
>>> support cookies.  There is probably a better way to do this which fits
>>> within the element hierarchy better but I haven't found it!
>>>
>>> Thanks to Josh for his input
>>>
>>> Chris
>>>
>>>
>>>
>>> On Mon, Jul 28, 2008 at 7:44 PM, Chris Ellis <christian.ellis@...>wrote:
>>>
>>>> Hi Josh
>>>>
>>>> Thanks for your reply.
>>>>
>>>> I've confused you with this:
>>>>
>>>> RoleUserIdentity identity =
>>>> (RoleUserIdentity)getRequestAttribute(Identified.IDENTITY_ATTRIBUTE_NAME);
>>>>
>>>> The purpose of this line is to check (in the debugger) whether the identity
>>>> has been set - which at this stage it hasn't.
>>>>
>>>> I was expecting it to be set either here:
>>>>
>>>>  - credentials.validate() [DatabaseCredentials.validate()]
>>>>
>>>> or here:
>>>>
>>>>  - session_manager.startSession(userid, getRemoteAddr(), false);
>>>>  [DatabaseSessionManager.startSession(...)]
>>>>
>>>> Which are both calls to RIFE classes - so I can't have messed these bits up
>>>> :-)
>>>>
>>>> I'll try the childtrigger first thing tomorrow (finished work for the day
>>>> now!)
>>>>
>>>> Cheers
>>>>
>>>> Chris
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Josh Hansen wrote:
>>>>
>>>>> Hi Chris,
>>>>>
>>>>> Typically the RoleUserIdentity object would be _set_ (not retrieved) in
>>>>> your authentication element, then retrieved in whichever element is
>>>>> inheriting from your authentication element.
>>>>>
>>>>> The built in RIFE authentication elements sets the request attribute by
>>>>> extending Identified, which uses a childtrigger.
>>>>>
>>>>> For example:
>>>>> PurgingMemoryAuthenticated extends RoleUserAuthenticated
>>>>> RoleUserAuthenticated extends Authenticated
>>>>> Authenticated extends Identified
>>>>> Identified extends Element
>>>>>
>>>>> Site definition:
>>>>> ------
>>>>>        ...
>>>>>        <globalcookie name="authid"/>
>>>>>        <element id="AuthSuperAdmin"
>>>>> extends="rife/authenticated/memory.xml">
>>>>>                <property name="password_encryption">SHA</property>
>>>>>                <property
>>>>> name="template_name">authentication.admin</property>
>>>>>                <property name="role">superadmin</property>
>>>>>                <property name="authvar_type">cookie</property>
>>>>>
>>>>>                <submission name="credentials">
>>>>>                        <param name="login"/>
>>>>>                        <param name="password"/>
>>>>>                </submission>
>>>>>
>>>>>                <childtrigger name="authid"/>
>>>>>        </element>
>>>>>        ...
>>>>> -------
>>>>>
>>>>> I'm not sure how the new custom authentication system works, but the
>>>>> underlying concept of needing to have the request attribute set before being
>>>>> able to retrieve should be pretty solid. :)
>>>>>
>>>>> Hopefully the above will be somewhat helpful. :)
>>>>>
>>>>> Josh
>>>>> --
>>>>> Joshua Hansen
>>>>> Up Bear Enterprises
>>>>> [phone]
>>>>>
>>>>>
>>>>> Chris wrote:
>>>>>
>>>>>> Hi
>>>>>>
>>>>>> I've succesfully implemented http authentication (for a web service)
>>>>>> into my code by following the example here:
>>>>>>
>>>>>> http://rifers.org/wiki/display/RIFE/HTTP+authentication
>>>>>>
>>>>>> I've changed it slightly to use a database instead of the memory users
>>>>>> participant, and it authenticates users quite happily.
>>>>>>
>>>>>> However it doesn't seem to add any user information to the request
>>>>>> state - i.e. getRequestAttribute(Identified.IDENTITY_ATTRIBUTE_NAME)
>>>>>> is always null.
>>>>>>
>>>>>> I've found some posts in the groups suggesting that the pattern for
>>>>>> custom authentication has changed and I think I might need to create a
>>>>>> custom CredentialsManager class.  However it seems that this is
>>>>>> _passed_ a Credentials object - and it's too late to take the
>>>>>> username / password from the http header at this stage.
>>>>>>
>>>>>> I'm very grateful for any pointers.
>>>>>>
>>>>>> (The relevant bit of code is below...)
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Chris
>>>>>>
>>>>>>                private void authoriseUser(String cred_str) throws
>>>>>> SessionManagerException {
>>>>>>                        String[] cred_arr =
>>>>>> StringUtils.splitToArray(cred_str, ":");
>>>>>>                        if (2 == cred_arr.length) {
>>>>>>                                String login = cred_arr[0];
>>>>>>                                String password = cred_arr[1];
>>>>>>                                String role = getPropertyString("role");
>>>>>>                                RoleUser credentials = new RoleUser(login,
>>>>>> password, role);
>>>>>>
>>>>>>                                SessionManager session_manager =
>>>>>> DatabaseSessionsFactory.getInstance(_datasource);
>>>>>>                                DatabaseUsers     credentials_manager =
>>>>>> DatabaseUsersFactory.getInstance(_datasource);
>>>>>>
>>>>>>                                HierarchicalProperties props = new
>>>>>> HierarchicalProperties();
>>>>>>                                props.put("datasource", _datasource);
>>>>>>
>>>>>>                                SessionValidator   validator = new
>>>>>> DatabaseSessionValidatorFactory().getValidator(props);
>>>>>>
>>>>>>  validator.setCredentialsManager(credentials_manager);
>>>>>>
>>>>>>  validator.setSessionManager(session_manager);
>>>>>>                                validator.setRememberManager(null);
>>>>>>
>>>>>>                                if (credentials.validate()) {
>>>>>>                                        long userid =
>>>>>> credentials_manager.verifyCredentials(credentials);
>>>>>>                                        if (userid >= 0) {
>>>>>>
>>>>>>  session_manager.startSession(userid, getRemoteAddr(), false);
>>>>>>                                                getLogger().fine("User " +
>>>>>> login + " authenticated in role " +
>>>>>> role + ".");
>>>>>>
>>>>>>
>>>>>>  ///////////////////////////////////
>>>>>>                                                //  User identified OK but
>>>>>> this is always null
>>>>>>
>>>>>>  ///////////////////////////////////
>>>>>>                                                RoleUserIdentity identity
>>>>>> =
>>>>>>
>>>>>> (RoleUserIdentity)getRequestAttribute(Identified.IDENTITY_ATTRIBUTE_NAME);
>>>>>>                                                child();
>>>>>>                                        }
>>>>>>                                }
>>>>>>                                getLogger().warning("Authorisation failed
>>>>>> for username " + login +
>>>>>> " for role " + role + ".");
>>>>>>                        }
>>>>>>                }
>>>>>>
>>>>>> and the config is like this
>>>>>> <site>
>>>>>>        <globalvar name="authid"/>
>>>>>>
>>>>>>        <!-- database and http authenticated /-->
>>>>>>        <element id="HttpAuth"
>>>>>>
>>>>>> implementation="com.datadiscoveries.webapp.common.authentication.HttpDbAuthentication">
>>>>>>    <property name="role">admin</property>
>>>>>>    <property name="datasource"><datasource>authentication_datasource</
>>>>>> datasource></property>
>>>>>>        </element>
>>>>>>
>>>>>>        <group inherits="HttpAuth">
>>>>>>    <element id="HttpAuthTest" url="httpAuthTest"
>>>>>> implementation="com.datadiscoveries.webapp.common.authentication.TestAuthenticated"
>>>>>> /
>>>>>>        </group>
>>>>>> </site>
>>>>>>
>>>>>>
>
>
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "rife-users" group.
To post to this group, send email to rife-users@...
To unsubscribe from this group, send email to rife-users+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rife-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Geert Bevin]

No worries Josh, I didn't take it as a criticism ;-)

I just felt obliged to explain their purpose a bit better.

Take care,

Geert

On Tue, Jul 29, 2008 at 9:56 PM, Josh Hansen <joshuah@...> wrote:

>
> Hi Geert,
>
> Thanks! :)
>
> I apologize -- my comment about child triggers being poorly documented
> wasn't intended to imply they are a poor feature.  In fact, I think they
> are quite neat.  Their use in the authentication system, along with the
> inheritance system, provides a concrete example of a how an aspect
> oriented solution can reduce effort and increase maintainability.
>
> All the best, :)
>
> Josh
> --
> Joshua Hansen
> Up Bear Enterprises
> [phone]
>
>
> Geert Bevin wrote:
>> Thanks a lot for all your help Josh, it's really appreciated.
>>
>> About child triggers, these are merely a method to quickly drop down
>> to a child element based on key value pairs, typically for
>> authentication. Initially it could seem bizarre that there's a
>> dedicate feature for this since you can achieve the same behavior by
>> just performing checks inside the processElement() method. However,
>> the benefit is that RIFE records all the child triggers and exit
>> triggers that have been ... euhm triggered ;-) This 'trail' towards to
>> active element is preserved and allows complex site structure flows to
>> work seemlessly.
>>
>> Hope this helps,
>>
>> Geert
>>
>> On Tue, Jul 29, 2008 at 6:59 PM, Josh Hansen <joshuah@...> wrote:
>>> Hi Chris,
>>>
>>> Good to hear that you got something working. :)
>>>
>>> As far as cookies go, a cookie can be a child trigger, and the RIFE
>>> authentication classes support the use of cookies.  In the sample site
>>> definition code I provided, the '<globalcookie name="authid"/>'
>>> statement and the '<property name="authvar_type">cookie</property>' and
>>> '<childtrigger name="authid"/>' element statements for the
>>> AuthSuperAdmin element both indicate this.  The default variable name
>>> for the authentication (in this case a cookie) is "authid", so it's not
>>> explicitly stated in the example I provided.
>>>
>>> In the RIFE 1.6.1 source for
>>> 'com/uwyn/rife/authentication/elements/Identified.java', the method
>>> 'childTriggered(String name, String[] values)' is what handles the
>>> population of the request attribute.
>>>
>>> Note that child triggers are currently poorly documented, so I'm taking
>>> some guesses at how these work. :)
>>>
>>> By defining the globalcookie 'authid', and then indicating
>>> '<childtrigger name="authid"/>' in the element, RIFE looks at the
>>> submission headers and/or request parameters, then looks through the
>>> site definition for any elements with childtriggers on those items.
>>>
>>> In our example, we've defined a cookie 'authid' and a child trigger on
>>> this cookie, so whenever a request is received, if the header includes a
>>> cookie named 'authid', then the element's 'childTriggered(String name,
>>> String[] values)' method is called with name set to 'authid', and values
>>> set to the values of the cookie.  From there, a lookup on the cookie
>>> value is done to get the authenticated information.
>>>
>>> The since you are working with both authentication and identification,
>>> you will probably also want to look at the childTriggered(String,
>>> String[]) method in
>>> 'com/uwyn/rife/authentication/elements/Authenticated.java', since for
>>> authentication, that is called before Identified.childTriggered(...).
>>>
>>> GoogleCode links:
>>> Authenticated.java:589
>>> http://www.google.com/codesearch?hl=en&q=show:tsWyz9b-wWM:a6zwkF4WcRg:tsWyz9b-wWM&sa=N&ct=rd&cs_p=https://svn.rifers.org/rife/trunk&cs_f=src/framework/com/uwyn/rife/authentication/elements/Authenticated.java&start=1
>>>
>>> Identified.java
>>> http://www.google.com/codesearch?hl=en&q=show:ToamIvdnc0A:a6zwkF4WcRg:ToamIvdnc0A&sa=N&ct=rd&cs_p=https://svn.rifers.org/rife/trunk&cs_f=src/framework/com/uwyn/rife/authentication/elements/Identified.java&start=1
>>>
>>> Hopefully that will help.  I know my understanding is getting
>>> progressively more clear. :)
>>>
>>> Josh
>>> --
>>> Joshua Hansen
>>> Up Bear Enterprises
>>> [phone]
>>>
>>>
>>> Christian Ellis wrote:
>>>> I've managed to get this to work by inserting the following lines of code
>>>> before calling child() (along with some considerable code changes).
>>>>
>>>> RoleUserAttributes attributes =
>>>> ((RoleUsersManager)session_validator.getCredentialsManager()).getAttributes(credentials.getLogin());
>>>>     RoleUserIdentity identity = new RoleUserIdentity(credentials.getLogin(),
>>>> attributes);
>>>> setRequestAttribute(IDENTITY_ATTRIBUTE_NAME, identity);
>>>>
>>>> I think the fundamental problem here is that this approach breaks away from
>>>> the standard template / element based strategy and in particular doesn't
>>>> support cookies.  There is probably a better way to do this which fits
>>>> within the element hierarchy better but I haven't found it!
>>>>
>>>> Thanks to Josh for his input
>>>>
>>>> Chris
>>>>
>>>>
>>>>
>>>> On Mon, Jul 28, 2008 at 7:44 PM, Chris Ellis <christian.ellis@...>wrote:
>>>>
>>>>> Hi Josh
>>>>>
>>>>> Thanks for your reply.
>>>>>
>>>>> I've confused you with this:
>>>>>
>>>>> RoleUserIdentity identity =
>>>>> (RoleUserIdentity)getRequestAttribute(Identified.IDENTITY_ATTRIBUTE_NAME);
>>>>>
>>>>> The purpose of this line is to check (in the debugger) whether the identity
>>>>> has been set - which at this stage it hasn't.
>>>>>
>>>>> I was expecting it to be set either here:
>>>>>
>>>>>  - credentials.validate() [DatabaseCredentials.validate()]
>>>>>
>>>>> or here:
>>>>>
>>>>>  - session_manager.startSession(userid, getRemoteAddr(), false);
>>>>>  [DatabaseSessionManager.startSession(...)]
>>>>>
>>>>> Which are both calls to RIFE classes - so I can't have messed these bits up
>>>>> :-)
>>>>>
>>>>> I'll try the childtrigger first thing tomorrow (finished work for the day
>>>>> now!)
>>>>>
>>>>> Cheers
>>>>>
>>>>> Chris
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Josh Hansen wrote:
>>>>>
>>>>>> Hi Chris,
>>>>>>
>>>>>> Typically the RoleUserIdentity object would be _set_ (not retrieved) in
>>>>>> your authentication element, then retrieved in whichever element is
>>>>>> inheriting from your authentication element.
>>>>>>
>>>>>> The built in RIFE authentication elements sets the request attribute by
>>>>>> extending Identified, which uses a childtrigger.
>>>>>>
>>>>>> For example:
>>>>>> PurgingMemoryAuthenticated extends RoleUserAuthenticated
>>>>>> RoleUserAuthenticated extends Authenticated
>>>>>> Authenticated extends Identified
>>>>>> Identified extends Element
>>>>>>
>>>>>> Site definition:
>>>>>> ------
>>>>>>        ...
>>>>>>        <globalcookie name="authid"/>
>>>>>>        <element id="AuthSuperAdmin"
>>>>>> extends="rife/authenticated/memory.xml">
>>>>>>                <property name="password_encryption">SHA</property>
>>>>>>                <property
>>>>>> name="template_name">authentication.admin</property>
>>>>>>                <property name="role">superadmin</property>
>>>>>>                <property name="authvar_type">cookie</property>
>>>>>>
>>>>>>                <submission name="credentials">
>>>>>>                        <param name="login"/>
>>>>>>                        <param name="password"/>
>>>>>>                </submission>
>>>>>>
>>>>>>                <childtrigger name="authid"/>
>>>>>>        </element>
>>>>>>        ...
>>>>>> -------
>>>>>>
>>>>>> I'm not sure how the new custom authentication system works, but the
>>>>>> underlying concept of needing to have the request attribute set before being
>>>>>> able to retrieve should be pretty solid. :)
>>>>>>
>>>>>> Hopefully the above will be somewhat helpful. :)
>>>>>>
>>>>>> Josh
>>>>>> --
>>>>>> Joshua Hansen
>>>>>> Up Bear Enterprises
>>>>>> [phone]
>>>>>>
>>>>>>
>>>>>> Chris wrote:
>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> I've succesfully implemented http authentication (for a web service)
>>>>>>> into my code by following the example here:
>>>>>>>
>>>>>>> http://rifers.org/wiki/display/RIFE/HTTP+authentication
>>>>>>>
>>>>>>> I've changed it slightly to use a database instead of the memory users
>>>>>>> participant, and it authenticates users quite happily.
>>>>>>>
>>>>>>> However it doesn't seem to add any user information to the request
>>>>>>> state - i.e. getRequestAttribute(Identified.IDENTITY_ATTRIBUTE_NAME)
>>>>>>> is always null.
>>>>>>>
>>>>>>> I've found some posts in the groups suggesting that the pattern for
>>>>>>> custom authentication has changed and I think I might need to create a
>>>>>>> custom CredentialsManager class.  However it seems that this is
>>>>>>> _passed_ a Credentials object - and it's too late to take the
>>>>>>> username / password from the http header at this stage.
>>>>>>>
>>>>>>> I'm very grateful for any pointers.
>>>>>>>
>>>>>>> (The relevant bit of code is below...)
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> Chris
>>>>>>>
>>>>>>>                private void authoriseUser(String cred_str) throws
>>>>>>> SessionManagerException {
>>>>>>>                        String[] cred_arr =
>>>>>>> StringUtils.splitToArray(cred_str, ":");
>>>>>>>                        if (2 == cred_arr.length) {
>>>>>>>                                String login = cred_arr[0];
>>>>>>>                                String password = cred_arr[1];
>>>>>>>                                String role = getPropertyString("role");
>>>>>>>                                RoleUser credentials = new RoleUser(login,
>>>>>>> password, role);
>>>>>>>
>>>>>>>                                SessionManager session_manager =
>>>>>>> DatabaseSessionsFactory.getInstance(_datasource);
>>>>>>>                                DatabaseUsers     credentials_manager =
>>>>>>> DatabaseUsersFactory.getInstance(_datasource);
>>>>>>>
>>>>>>>                                HierarchicalProperties props = new
>>>>>>> HierarchicalProperties();
>>>>>>>                                props.put("datasource", _datasource);
>>>>>>>
>>>>>>>                                SessionValidator   validator = new
>>>>>>> DatabaseSessionValidatorFactory().getValidator(props);
>>>>>>>
>>>>>>>  validator.setCredentialsManager(credentials_manager);
>>>>>>>
>>>>>>>  validator.setSessionManager(session_manager);
>>>>>>>                                validator.setRememberManager(null);
>>>>>>>
>>>>>>>                                if (credentials.validate()) {
>>>>>>>                                        long userid =
>>>>>>> credentials_manager.verifyCredentials(credentials);
>>>>>>>                                        if (userid >= 0) {
>>>>>>>
>>>>>>>  session_manager.startSession(userid, getRemoteAddr(), false);
>>>>>>>                                                getLogger().fine("User " +
>>>>>>> login + " authenticated in role " +
>>>>>>> role + ".");
>>>>>>>
>>>>>>>
>>>>>>>  ///////////////////////////////////
>>>>>>>                                                //  User identified OK but
>>>>>>> this is always null
>>>>>>>
>>>>>>>  ///////////////////////////////////
>>>>>>>                                                RoleUserIdentity identity
>>>>>>> =
>>>>>>>
>>>>>>> (RoleUserIdentity)getRequestAttribute(Identified.IDENTITY_ATTRIBUTE_NAME);
>>>>>>>                                                child();
>>>>>>>                                        }
>>>>>>>                                }
>>>>>>>                                getLogger().warning("Authorisation failed
>>>>>>> for username " + login +
>>>>>>> " for role " + role + ".");
>>>>>>>                        }
>>>>>>>                }
>>>>>>>
>>>>>>> and the config is like this
>>>>>>> <site>
>>>>>>>        <globalvar name="authid"/>
>>>>>>>
>>>>>>>        <!-- database and http authenticated /-->
>>>>>>>        <element id="HttpAuth"
>>>>>>>
>>>>>>> implementation="com.datadiscoveries.webapp.common.authentication.HttpDbAuthentication">
>>>>>>>    <property name="role">admin</property>
>>>>>>>    <property name="datasource"><datasource>authentication_datasource</
>>>>>>> datasource></property>
>>>>>>>        </element>
>>>>>>>
>>>>>>>        <group inherits="HttpAuth">
>>>>>>>    <element id="HttpAuthTest" url="httpAuthTest"
>>>>>>> implementation="com.datadiscoveries.webapp.common.authentication.TestAuthenticated"
>>>>>>> /
>>>>>>>        </group>
>>>>>>> </site>
>>>>>>>
>>>>>>>
>>
>>
>>
>
> >
>

--
Geert Bevin
Terracotta - http://www.terracotta.org
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "rife-users" group.
To post to this group, send email to rife-users@...
To unsubscribe from this group, send email to rife-users+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rife-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Chris - Stirling]

On Tue, Jul 29, 2008 at 9:29 PM, Geert Bevin <gbevin@...> wrote:

No worries Josh, I didn't take it as a criticism ;-)

I just felt obliged to explain their purpose a bit better.

Take care,

Geert

On Tue, Jul 29, 2008 at 9:56 PM, Josh Hansen <joshuah@...> wrote:
>
> Hi Geert,
>
> Thanks! :)
>
> I apologize -- my comment about child triggers being poorly documented
> wasn't intended to imply they are a poor feature.  In fact, I think they
> are quite neat.  Their use in the authentication system, along with the
> inheritance system, provides a concrete example of a how an aspect
> oriented solution can reduce effort and increase maintainability.

>
> All the best, :)
>
> Josh
> --
> Joshua Hansen
> Up Bear Enterprises
> [phone]
>
>

> Geert Bevin wrote:
>> Thanks a lot for all your help Josh, it's really appreciated.
>>
>> About child triggers, these are merely a method to quickly drop down
>> to a child element based on key value pairs, typically for
>> authentication. Initially it could seem bizarre that there's a
>> dedicate feature for this since you can achieve the same behavior by
>> just performing checks inside the processElement() method. However,
>> the benefit is that RIFE records all the child triggers and exit
>> triggers that have been ... euhm triggered ;-) This 'trail' towards to
>> active element is preserved and allows complex site structure flows to
>> work seemlessly.
>>
>> Hope this helps,
>>
>> Geert
>>
>> On Tue, Jul 29, 2008 at 6:59 PM, Josh Hansen <joshuah@...> wrote:
>>> Hi Chris,
>>>
>>> Good to hear that you got something working. :)
>>>
>>> As far as cookies go, a cookie can be a child trigger, and the RIFE
>>> authentication classes support the use of cookies.  In the sample site
>>> definition code I provided, the '<globalcookie name="authid"/>'
>>> statement and the '<property name="authvar_type">cookie</property>' and
>>> '<childtrigger name="authid"/>' element statements for the
>>> AuthSuperAdmin element both indicate this.  The default variable name
>>> for the authentication (in this case a cookie) is "authid", so it's not
>>> explicitly stated in the example I provided.
>>>
>>> In the RIFE 1.6.1 source for
>>> 'com/uwyn/rife/authentication/elements/Identified.java', the method
>>> 'childTriggered(String name, String[] values)' is what handles the
>>> population of the request attribute.
>>>
>>> Note that child triggers are currently poorly documented, so I'm taking
>>> some guesses at how these work. :)
>>>
>>> By defining the globalcookie 'authid', and then indicating
>>> '<childtrigger name="authid"/>' in the element, RIFE looks at the
>>> submission headers and/or request parameters, then looks through the
>>> site definition for any elements with childtriggers on those items.
>>>
>>> In our example, we've defined a cookie 'authid' and a child trigger on
>>> this cookie, so whenever a request is received, if the header includes a
>>> cookie named 'authid', then the element's 'childTriggered(String name,
>>> String[] values)' method is called with name set to 'authid', and values
>>> set to the values of the cookie.  From there, a lookup on the cookie
>>> value is done to get the authenticated information.
>>>
>>> The since you are working with both authentication and identification,
>>> you will probably also want to look at the childTriggered(String,
>>> String[]) method in
>>> 'com/uwyn/rife/authentication/elements/Authenticated.java', since for
>>> authentication, that is called before Identified.childTriggered(...).
>>>
>>> GoogleCode links:
>>> Authenticated.java:589
>>> http://www.google.com/codesearch?hl=en&q=show:tsWyz9b-wWM:a6zwkF4WcRg:tsWyz9b-wWM&sa=N&ct=rd&cs_p=https://svn.rifers.org/rife/trunk&cs_f=src/framework/com/uwyn/rife/authentication/elements/Authenticated.java&start=1
>>>
>>> Identified.java
>>> http://www.google.com/codesearch?hl=en&q=show:ToamIvdnc0A:a6zwkF4WcRg:ToamIvdnc0A&sa=N&ct=rd&cs_p=https://svn.rifers.org/rife/trunk&cs_f=src/framework/com/uwyn/rife/authentication/elements/Identified.java&start=1
>>>
>>> Hopefully that will help.  I know my understanding is getting
>>> progressively more clear. :)
>>>
>>> Josh
>>> --
>>> Joshua Hansen
>>> Up Bear Enterprises
>>> [phone]
>>>
>>>
>>> Christian Ellis wrote:
>>>> I've managed to get this to work by inserting the following lines of code
>>>> before calling child() (along with some considerable code changes).
>>>>
>>>> RoleUserAttributes attributes =
>>>> ((RoleUsersManager)session_validator.getCredentialsManager()).getAttributes(credentials.getLogin());
>>>>     RoleUserIdentity identity = new RoleUserIdentity(credentials.getLogin(),
>>>> attributes);
>>>> setRequestAttribute(IDENTITY_ATTRIBUTE_NAME, identity);
>>>>
>>>> I think the fundamental problem here is that this approach breaks away from
>>>> the standard template / element based strategy and in particular doesn't
>>>> support cookies.  There is probably a better way to do this which fits
>>>> within the element hierarchy better but I haven't found it!
>>>>
>>>> Thanks to Josh for his input
>>>>
>>>> Chris
>>>>
>>>>
>>>>
>>>> On Mon, Jul 28, 2008 at 7:44 PM, Chris Ellis <christian.ellis@...>wrote:
>>>>
>>>>> Hi Josh
>>>>>
>>>>> Thanks for your reply.
>>>>>
>>>>> I've confused you with this:
>>>>>
>>>>> RoleUserIdentity identity =
>>>>> (RoleUserIdentity)getRequestAttribute(Identified.IDENTITY_ATTRIBUTE_NAME);
>>>>>
>>>>> The purpose of this line is to check (in the debugger) whether the identity
>>>>> has been set - which at this stage it hasn't.
>>>>>
>>>>> I was expecting it to be set either here:
>>>>>
>>>>>  - credentials.validate() [DatabaseCredentials.validate()]
>>>>>
>>>>> or here:
>>>>>
>>>>>  - session_manager.startSession(userid, getRemoteAddr(), false);
>>>>>  [DatabaseSessionManager.startSession(...)]
>>>>>
>>>>> Which are both calls to RIFE classes - so I can't have messed these bits up
>>>>> :-)
>>>>>
>>>>> I'll try the childtrigger first thing tomorrow (finished work for the day
>>>>> now!)
>>>>>
>>>>> Cheers
>>>>>
>>>>> Chris
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Josh Hansen wrote:
>>>>>
>>>>>> Hi Chris,
>>>>>>
>>>>>> Typically the RoleUserIdentity object would be _set_ (not retrieved) in
>>>>>> your authentication element, then retrieved in whichever element is
>>>>>> inheriting from your authentication element.
>>>>>>
>>>>>> The built in RIFE authentication elements sets the request attribute by
>>>>>> extending Identified, which uses a childtrigger.
>>>>>>
>>>>>> For example:
>>>>>> PurgingMemoryAuthenticated extends RoleUserAuthenticated
>>>>>> RoleUserAuthenticated extends Authenticated
>>>>>> Authenticated extends Identified
>>>>>> Identified extends Element
>>>>>>
>>>>>> Site definition:
>>>>>> ------
>>>>>>        ...
>>>>>>        <globalcookie name="authid"/>
>>>>>>        <element id="AuthSuperAdmin"
>>>>>> extends="rife/authenticated/memory.xml">
>>>>>>                <property name="password_encryption">SHA</property>
>>>>>>                <property
>>>>>> name="template_name">authentication.admin</property>
>>>>>>                <property name="role">superadmin</property>
>>>>>>                <property name="authvar_type">cookie</property>
>>>>>>
>>>>>>                <submission name="credentials">
>>>>>>                        <param name="login"/>
>>>>>>                        <param name="password"/>
>>>>>>                </submission>
>>>>>>
>>>>>>                <childtrigger name="authid"/>
>>>>>>        </element>
>>>>>>        ...
>>>>>> -------
>>>>>>
>>>>>> I'm not sure how the new custom authentication system works, but the
>>>>>> underlying concept of needing to have the request attribute set before being
>>>>>> able to retrieve should be pretty solid. :)
>>>>>>
>>>>>> Hopefully the above will be somewhat helpful. :)
>>>>>>
>>>>>> Josh
>>>>>> --
>>>>>> Joshua Hansen
>>>>>> Up Bear Enterprises
>>>>>> [phone]
>>>>>>
>>>>>>
>>>>>> Chris wrote:
>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> I've succesfully implemented http authentication (for a web service)
>>>>>>> into my code by following the example here:
>>>>>>>
>>>>>>> http://rifers.org/wiki/display/RIFE/HTTP+authentication
>>>>>>>
>>>>>>> I've changed it slightly to use a database instead of the memory users
>>>>>>> participant, and it authenticates users quite happily.
>>>>>>>
>>>>>>> However it doesn't seem to add any user information to the request
>>>>>>> state - i.e. getRequestAttribute(Identified.IDENTITY_ATTRIBUTE_NAME)
>>>>>>> is always null.
>>>>>>>
>>>>>>> I've found some posts in the groups suggesting that the pattern for
>>>>>>> custom authentication has changed and I think I might need to create a
>>>>>>> custom CredentialsManager class.  However it seems that this is
>>>>>>> _passed_ a Credentials object - and it's too late to take the
>>>>>>> username / password from the http header at this stage.
>>>>>>>
>>>>>>> I'm very grateful for any pointers.
>>>>>>>
>>>>>>> (The relevant bit of code is below...)
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> Chris
>>>>>>>
>>>>>>>                private void authoriseUser(String cred_str) throws
>>>>>>> SessionManagerException {
>>>>>>>                        String[] cred_arr =
>>>>>>> StringUtils.splitToArray(cred_str, ":");
>>>>>>>                        if (2 == cred_arr.length) {
>>>>>>>                                String login = cred_arr[0];
>>>>>>>                                String password = cred_arr[1];
>>>>>>>                                String role = getPropertyString("role");
>>>>>>>                                RoleUser credentials = new RoleUser(login,
>>>>>>> password, role);
>>>>>>>
>>>>>>>                                SessionManager session_manager =
>>>>>>> DatabaseSessionsFactory.getInstance(_datasource);
>>>>>>>                                DatabaseUsers     credentials_manager =
>>>>>>> DatabaseUsersFactory.getInstance(_datasource);
>>>>>>>
>>>>>>>                                HierarchicalProperties props = new
>>>>>>> HierarchicalProperties();
>>>>>>>                                props.put("datasource", _datasource);
>>>>>>>
>>>>>>>                                SessionValidator   validator = new
>>>>>>> DatabaseSessionValidatorFactory().getValidator(props);
>>>>>>>
>>>>>>>  validator.setCredentialsManager(credentials_manager);
>>>>>>>
>>>>>>>  validator.setSessionManager(session_manager);
>>>>>>>                                validator.setRememberManager(null);
>>>>>>>
>>>>>>>                                if (credentials.validate()) {
>>>>>>>                                        long userid =
>>>>>>> credentials_manager.verifyCredentials(credentials);
>>>>>>>                                        if (userid >= 0) {
>>>>>>>
>>>>>>>  session_manager.startSession(userid, getRemoteAddr(), false);
>>>>>>>                                                getLogger().fine("User " +
>>>>>>> login + " authenticated in role " +
>>>>>>> role + ".");
>>>>>>>
>>>>>>>
>>>>>>>  ///////////////////////////////////
>>>>>>>                                                //  User identified OK but
>>>>>>> this is always null
>>>>>>>
>>>>>>>  ///////////////////////////////////
>>>>>>>                                                RoleUserIdentity identity
>>>>>>> =
>>>>>>>
>>>>>>> (RoleUserIdentity)getRequestAttribute(Identified.IDENTITY_ATTRIBUTE_NAME);
>>>>>>>                                                child();
>>>>>>>                                        }
>>>>>>>                                }
>>>>>>>                                getLogger().warning("Authorisation failed
>>>>>>> for username " + login +
>>>>>>> " for role " + role + ".");
>>>>>>>                        }
>>>>>>>                }
>>>>>>>
>>>>>>> and the config is like this
>>>>>>> <site>
>>>>>>>        <globalvar name="authid"/>
>>>>>>>
>>>>>>>        <!-- database and http authenticated /-->
>>>>>>>        <element id="HttpAuth"
>>>>>>>
>>>>>>> implementation="com.datadiscoveries.webapp.common.authentication.HttpDbAuthentication">
>>>>>>>    <property name="role">admin</property>
>>>>>>>    <property name="datasource"><datasource>authentication_datasource</
>>>>>>> datasource></property>
>>>>>>>        </element>
>>>>>>>
>>>>>>>        <group inherits="HttpAuth">
>>>>>>>    <element id="HttpAuthTest" url="httpAuthTest"
>>>>>>> implementation="com.datadiscoveries.webapp.common.authentication.TestAuthenticated"
>>>>>>> /
>>>>>>>        </group>
>>>>>>> </site>
>>>>>>>
>>>>>>>
>>
>>
>>
>
> >
>



--

Geert Bevin
Terracotta - http://www.terracotta.org
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "rife-users" group.
To post to this group, send email to rife-users@...
To unsubscribe from this group, send email to rife-users+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rife-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Chris - Stirling]

Hmm - text of my last message vanished - sorry.

What I said was something like...

Hi guys

Thanks for the further explanations.  Sorry about the bit about the cookies - this was just confusion on my part and of course isn't relevant in this context.

Thanks Geert for confirmation that I've done the right thing in the end.  It all makes sense now I have a fuller picture.

This was the final piece in a web service which will be used to schedule jobs using the rife scheduler.  Clients can create jobs and check their status, and then download output when complete.  Setting up the scheduler was a breeze - thanks!

Cheers

Chris

On Wed, Jul 30, 2008 at 9:19 AM, Christian Ellis <christian.ellis@...> wrote:

On Tue, Jul 29, 2008 at 9:29 PM, Geert Bevin <gbevin@...> wrote:

No worries Josh, I didn't take it as a criticism ;-)

I just felt obliged to explain their purpose a bit better.

Take care,

Geert

On Tue, Jul 29, 2008 at 9:56 PM, Josh Hansen <joshuah@...> wrote:
>
> Hi Geert,
>
> Thanks! :)
>
> I apologize -- my comment about child triggers being poorly documented
> wasn't intended to imply they are a poor feature.  In fact, I think they
> are quite neat.  Their use in the authentication system, along with the
> inheritance system, provides a concrete example of a how an aspect
> oriented solution can reduce effort and increase maintainability.
>
> All the best, :)
>
> Josh
> --
> Joshua Hansen
> Up Bear Enterprises
> [phone]
>
>
> Geert Bevin wrote:
>> Thanks a lot for all your help Josh, it's really appreciated.
>>
>> About child triggers, these are merely a method to quickly drop down
>> to a child element based on key value pairs, typically for
>> authentication. Initially it could seem bizarre that there's a
>> dedicate feature for this since you can achieve the same behavior by
>> just performing checks inside the processElement() method. However,
>> the benefit is that RIFE records all the child triggers and exit
>> triggers that have been ... euhm triggered ;-) This 'trail' towards to
>> active element is preserved and allows complex site structure flows to
>> work seemlessly.
>>
>> Hope this helps,
>>
>> Geert
>>
>> On Tue, Jul 29, 2008 at 6:59 PM, Josh Hansen <joshuah@...> wrote:
>>> Hi Chris,
>>>
>>> Good to hear that you got something working. :)
>>>
>>> As far as cookies go, a cookie can be a child trigger, and the RIFE
>>> authentication classes support the use of cookies.  In the sample site
>>> definition code I provided, the '<globalcookie name="authid"/>'
>>> statement and the '<property name="authvar_type">cookie</property>' and
>>> '<childtrigger name="authid"/>' element statements for the
>>> AuthSuperAdmin element both indicate this.  The default variable name
>>> for the authentication (in this case a cookie) is "authid", so it's not
>>> explicitly stated in the example I provided.
>>>
>>> In the RIFE 1.6.1 source for
>>> 'com/uwyn/rife/authentication/elements/Identified.java', the method
>>> 'childTriggered(String name, String[] values)' is what handles the
>>> population of the request attribute.
>>>
>>> Note that child triggers are currently poorly documented, so I'm taking
>>> some guesses at how these work. :)
>>>
>>> By defining the globalcookie 'authid', and then indicating
>>> '<childtrigger name="authid"/>' in the element, RIFE looks at the
>>> submission headers and/or request parameters, then looks through the
>>> site definition for any elements with childtriggers on those items.
>>>
>>> In our example, we've defined a cookie 'authid' and a child trigger on
>>> this cookie, so whenever a request is received, if the header includes a
>>> cookie named 'authid', then the element's 'childTriggered(String name,
>>> String[] values)' method is called with name set to 'authid', and values
>>> set to the values of the cookie.  From there, a lookup on the cookie
>>> value is done to get the authenticated information.
>>>
>>> The since you are working with both authentication and identification,
>>> you will probably also want to look at the childTriggered(String,
>>> String[]) method in
>>> 'com/uwyn/rife/authentication/elements/Authenticated.java', since for
>>> authentication, that is called before Identified.childTriggered(...).
>>>
>>> GoogleCode links:
>>> Authenticated.java:589
>>> http://www.google.com/codesearch?hl=en&q=show:tsWyz9b-wWM:a6zwkF4WcRg:tsWyz9b-wWM&sa=N&ct=rd&cs_p=https://svn.rifers.org/rife/trunk&cs_f=src/framework/com/uwyn/rife/authentication/elements/Authenticated.java&start=1
>>>
>>> Identified.java
>>> http://www.google.com/codesearch?hl=en&q=show:ToamIvdnc0A:a6zwkF4WcRg:ToamIvdnc0A&sa=N&ct=rd&cs_p=https://svn.rifers.org/rife/trunk&cs_f=src/framework/com/uwyn/rife/authentication/elements/Identified.java&start=1
>>>
>>> Hopefully that will help.  I know my understanding is getting
>>> progressively more clear. :)
>>>
>>> Josh
>>> --
>>> Joshua Hansen
>>> Up Bear Enterprises
>>> [phone]
>>>
>>>
>>> Christian Ellis wrote:
>>>> I've managed to get this to work by inserting the following lines of code
>>>> before calling child() (along with some considerable code changes).
>>>>
>>>> RoleUserAttributes attributes =
>>>> ((RoleUsersManager)session_validator.getCredentialsManager()).getAttributes(credentials.getLogin());
>>>>     RoleUserIdentity identity = new RoleUserIdentity(credentials.getLogin(),
>>>> attributes);
>>>> setRequestAttribute(IDENTITY_ATTRIBUTE_NAME, identity);
>>>>
>>>> I think the fundamental problem here is that this approach breaks away from
>>>> the standard template / element based strategy and in particular doesn't
>>>> support cookies.  There is probably a better way to do this which fits
>>>> within the element hierarchy better but I haven't found it!
>>>>
>>>> Thanks to Josh for his input
>>>>
>>>> Chris
>>>>
>>>>
>>>>
>>>> On Mon, Jul 28, 2008 at 7:44 PM, Chris Ellis <christian.ellis@...>wrote:
>>>>
>>>>> Hi Josh
>>>>>
>>>>> Thanks for your reply.
>>>>>
>>>>> I've confused you with this:
>>>>>
>>>>> RoleUserIdentity identity =
>>>>> (RoleUserIdentity)getRequestAttribute(Identified.IDENTITY_ATTRIBUTE_NAME);
>>>>>
>>>>> The purpose of this line is to check (in the debugger) whether the identity
>>>>> has been set - which at this stage it hasn't.
>>>>>
>>>>> I was expecting it to be set either here:
>>>>>
>>>>>  - credentials.validate() [DatabaseCredentials.validate()]
>>>>>
>>>>> or here:
>>>>>
>>>>>  - session_manager.startSession(userid, getRemoteAddr(), false);
>>>>>  [DatabaseSessionManager.startSession(...)]
>>>>>
>>>>> Which are both calls to RIFE classes - so I can't have messed these bits up
>>>>> :-)
>>>>>
>>>>> I'll try the childtrigger first thing tomorrow (finished work for the day
>>>>> now!)
>>>>>
>>>>> Cheers
>>>>>
>>>>> Chris
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Josh Hansen wrote:
>>>>>
>>>>>> Hi Chris,
>>>>>>
>>>>>> Typically the RoleUserIdentity object would be _set_ (not retrieved) in
>>>>>> your authentication element, then retrieved in whichever element is
>>>>>> inheriting from your authentication element.
>>>>>>
>>>>>> The built in RIFE authentication elements sets the request attribute by
>>>>>> extending Identified, which uses a childtrigger.
>>>>>>
>>>>>> For example:
>>>>>> PurgingMemoryAuthenticated extends RoleUserAuthenticated
>>>>>> RoleUserAuthenticated extends Authenticated
>>>>>> Authenticated extends Identified
>>>>>> Identified extends Element
>>>>>>
>>>>>> Site definition:
>>>>>> ------
>>>>>>        ...
>>>>>>        <globalcookie name="authid"/>
>>>>>>        <element id="AuthSuperAdmin"
>>>>>> extends="rife/authenticated/memory.xml">
>>>>>>                <property name="password_encryption">SHA</property>
>>>>>>                <property
>>>>>> name="template_name">authentication.admin</property>
>>>>>>                <property name="role">superadmin</property>
>>>>>>                <property name="authvar_type">cookie</property>
>>>>>>
>>>>>>                <submission name="credentials">
>>>>>>                        <param name="login"/>
>>>>>>                        <param name="password"/>
>>>>>>                </submission>
>>>>>>
>>>>>>                <childtrigger name="authid"/>
>>>>>>        </element>
>>>>>>        ...
>>>>>> -------
>>>>>>
>>>>>> I'm not sure how the new custom authentication system works, but the
>>>>>> underlying concept of needing to have the request attribute set before being
>>>>>> able to retrieve should be pretty solid. :)
>>>>>>
>>>>>> Hopefully the above will be somewhat helpful. :)
>>>>>>
>>>>>> Josh
>>>>>> --
>>>>>> Joshua Hansen
>>>>>> Up Bear Enterprises
>>>>>> [phone]
>>>>>>
>>>>>>
>>>>>> Chris wrote:
>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> I've succesfully implemented http authentication (for a web service)
>>>>>>> into my code by following the example here:
>>>>>>>
>>>>>>> http://rifers.org/wiki/display/RIFE/HTTP+authentication
>>>>>>>
>>>>>>> I've changed it slightly to use a database instead of the memory users
>>>>>>> participant, and it authenticates users quite happily.
>>>>>>>
>>>>>>> However it doesn't seem to add any user information to the request
>>>>>>> state - i.e. getRequestAttribute(Identified.IDENTITY_ATTRIBUTE_NAME)
>>>>>>> is always null.
>>>>>>>
>>>>>>> I've found some posts in the groups suggesting that the pattern for
>>>>>>> custom authentication has changed and I think I might need to create a
>>>>>>> custom CredentialsManager class.  However it seems that this is
>>>>>>> _passed_ a Credentials object - and it's too late to take the
>>>>>>> username / password from the http header at this stage.
>>>>>>>
>>>>>>> I'm very grateful for any pointers.
>>>>>>>
>>>>>>> (The relevant bit of code is below...)
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> Chris
>>>>>>>
>>>>>>>                private void authoriseUser(String cred_str) throws
>>>>>>> SessionManagerException {
>>>>>>>                        String[] cred_arr =
>>>>>>> StringUtils.splitToArray(cred_str, ":");
>>>>>>>                        if (2 == cred_arr.length) {
>>>>>>>                                String login = cred_arr[0];
>>>>>>>                                String password = cred_arr[1];
>>>>>>>                                String role = getPropertyString("role");
>>>>>>>                                RoleUser credentials = new RoleUser(login,
>>>>>>> password, role);
>>>>>>>
>>>>>>>                                SessionManager session_manager =
>>>>>>> DatabaseSessionsFactory.getInstance(_datasource);
>>>>>>>                                DatabaseUsers     credentials_manager =
>>>>>>> DatabaseUsersFactory.getInstance(_datasource);
>>>>>>>
>>>>>>>                                HierarchicalProperties props = new
>>>>>>> HierarchicalProperties();
>>>>>>>                                props.put("datasource", _datasource);
>>>>>>>
>>>>>>>                                SessionValidator   validator = new
>>>>>>> DatabaseSessionValidatorFactory().getValidator(props);
>>>>>>>
>>>>>>>  validator.setCredentialsManager(credentials_manager);
>>>>>>>
>>>>>>>  validator.setSessionManager(session_manager);
>>>>>>>                                validator.setRememberManager(null);
>>>>>>>
>>>>>>>                                if (credentials.validate()) {
>>>>>>>                                        long userid =
>>>>>>> credentials_manager.verifyCredentials(credentials);
>>>>>>>                                        if (userid >= 0) {
>>>>>>>
>>>>>>>  session_manager.startSession(userid, getRemoteAddr(), false);
>>>>>>>                                                getLogger().fine("User " +
>>>>>>> login + " authenticated in role " +
>>>>>>> role + ".");
>>>>>>>
>>>>>>>
>>>>>>>  ///////////////////////////////////
>>>>>>>                                                //  User identified OK but
>>>>>>> this is always null
>>>>>>>
>>>>>>>  ///////////////////////////////////
>>>>>>>                                                RoleUserIdentity identity
>>>>>>> =
>>>>>>>
>>>>>>> (RoleUserIdentity)getRequestAttribute(Identified.IDENTITY_ATTRIBUTE_NAME);
>>>>>>>                                                child();
>>>>>>>                                        }
>>>>>>>                                }
>>>>>>>                                getLogger().warning("Authorisation failed
>>>>>>> for username " + login +
>>>>>>> " for role " + role + ".");
>>>>>>>                        }
>>>>>>>                }
>>>>>>>
>>>>>>> and the config is like this
>>>>>>> <site>
>>>>>>>        <globalvar name="authid"/>
>>>>>>>
>>>>>>>        <!-- database and http authenticated /-->
>>>>>>>        <element id="HttpAuth"
>>>>>>>
>>>>>>> implementation="com.datadiscoveries.webapp.common.authentication.HttpDbAuthentication">
>>>>>>>    <property name="role">admin</property>
>>>>>>>    <property name="datasource"><datasource>authentication_datasource</
>>>>>>> datasource></property>
>>>>>>>        </element>
>>>>>>>
>>>>>>>        <group inherits="HttpAuth">
>>>>>>>    <element id="HttpAuthTest" url="httpAuthTest"
>>>>>>> implementation="com.datadiscoveries.webapp.common.authentication.TestAuthenticated"
>>>>>>> /
>>>>>>>        </group>
>>>>>>> </site>
>>>>>>>
>>>>>>>
>>
>>
>>
>
> >
>



--

Geert Bevin
Terracotta - http://www.terracotta.org
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "rife-users" group.
To post to this group, send email to rife-users@...
To unsubscribe from this group, send email to rife-users+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rife-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Geert Bevin]

Hi Christian,

thanks for reporting your success, it's always nice to hear from  
people when things work. Usually we only hear from the users when  
problems arise :-)

Take care,

Geert

On 30 Jul 2008, at 10:30, Christian Ellis wrote:

> Hmm - text of my last message vanished - sorry.
>
> What I said was something like...
>
> Hi guys
>
> Thanks for the further explanations.  Sorry about the bit about the  
> cookies - this was just confusion on my part and of course isn't  
> relevant in this context.
>
> Thanks Geert for confirmation that I've done the right thing in the  
> end.  It all makes sense now I have a fuller picture.
>
> This was the final piece in a web service which will be used to  
> schedule jobs using the rife scheduler.  Clients can create jobs and  
> check their status, and then download output when complete.  Setting  
> up the scheduler was a breeze - thanks!
>
> Cheers
>
> Chris

--
Geert Bevin
Terracotta - http://www.terracotta.org
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "rife-users" group.
To post to this group, send email to rife-users@...
To unsubscribe from this group, send email to rife-users+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rife-users?hl=en
-~----------~----~----~----~------~----~------~--~---