The problem you're experiencing is similar to a problem i got will ago!

I was using the authentication framework but that wasn't good enough. So
i just decided to create my own auth framework!

I build up a user class hierarchy like :

       +--> Anonymous
       |
User --+                    +--> Customer --> VIP
       |                    |
       +--> Authenticated --+
                            |
                            +--> Operator --> Administrator

Matching each role to a java Class/Interface

Then i created a authentication manager ( initialized in the
cocoon.xconf ) as a component which makes it accessible wherever in
cocoon.

The manager stores the user state in the session and checks the state to
see if it matches a given role! if not logged in it just returns an
Anonymous Object.

the match of a given role is given by the "instanceof" operator which
allows me to match any give hierarchy!

if you which to use this implementation just reply to this asking for it
and i'll post in the mailing list!


On Fri, 2003-07-04 at 01:10, Adam Flegman wrote:
> Hello All,
> 
> I have recently been delivered to the wonderful world of cocoon. I am very
> impressed but what I have seen (and somewhat confused to - so many different
> ways to do things). I have been given an almost complete cocoon based web site
> to finish in a very short amount of time.
> 
> 
> Client Side:
> ------------
> The client side of the web-app is in need of some form on session/login
> processing, but its not quite as formal as an offical login....
> 
> The client side is avaiable to anyone, anytime (both the general public, and
> employees of the company). 
> 
> The client side of the web site could be accessed at any given page (some
> user's will bookmark certain pages)
> 
> All the pages in the client side need to know a few things about the user (that
> can be calculated from their IP and some info in the database).
> 
> Almost every page on the client side will perform some sort of search against
> the database. These searches are identical for all users - its just the 'where'
> clause that may need some extra conditions based on the type of user (public or
> employee).  
> 
> 
> The Solution???
> ---------------
> Write the code to calculate the usertype once [public|employee]
> 
> Perform the calcultion of user details only once.
> 
> Ensure that user details have been calculated before the sql code of any page
> executes.
> 
> 
> Current Position:
> ------------------
> Java code is no problem, and I have used xml and a bit of xslt. 
> 
> I know the actual java code required to determine the usertype.
> 
> I'm guessing the solution will require the usertype details to be carried
> around in the session.
> 
> I just dont know how to use the power of cocoon to ensure that the usertype
> details are calculated before any xsp page is executed.
> 
> 
> 
> Any help/hints/tips/references would be greatly appreciated. 
> 
> 
> 
> 
> Regards,
> 
> 
>      Adam.
> 
> =====
> Adam Flegman - Senior Software Engineer
> 
> Mobile:     (0414) 375 735
> Phone:     (07) 5547 8530
> Facsimile: (07) 5547 8532
> Email #1: [EMAIL PROTECTED] 
> Email #2: [EMAIL PROTECTED]
> 
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
-- 
Nuno Santos <[EMAIL PROTECTED]>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to