Re: [Pas-dev] LoggedInPage and Authentication/Authorization

[Justin B. <ju...@le...>]

I agree it would be simple.  I'm not sure if I agree it should be part of PAS. 
Maybe as an example of what you can do in PAS or if we create a web based 
administrator interface for PAS or revive the E-commerce in a box project based 
on PAS.  This kind of thing works great there.  Or are we commited to having a 
more rigid architecture that provides solutions-in-a-box for specific things.  I 
know other application servers provide specific solutions for people to develop 
with but most of the time they end up severely constraining the developer.  You 
also end up forcing upon people a specific database structure.  In the end, the 
developer ends up creating their own solutions.

I think it would be neat to provide solutions people can plug-in and start 
working with right away.  Where in the project it belongs, I don't know.

Justin

Kyle R . Burton wrote:
> Kaare's questions about security issues, and Justin's response with the
> LoggedInPage example got me thinking about authentication and authorization
> issues.
> 
> LoggedInPage is an example of this class of isses.  A user visits the site,
> we give them a security token (session id cookie).  They authenticate (log 
> in), and we update their security token with 'logged in' (we set a flag
> in their session). 
> 
> There is no reason why we couldn't additionaly load a list of user
> roles into the user profile object (and therefore into the session),
> and then have an AuthSystemPage that had a simple api, like a method
> named allowedUserRoles() that returned an array (or hash or whatever)
> of user roles that were allowed to access the page in question.  This
> method would be abstract in the AuthSystemPage, but implemented in
> derived pages.  The AuthSystemPage, like LoggedInPage, could use the
> allowedUserRoles() from the derived class and verify the user roles
> from the profile stored in the session (it could do this within
> request_init(), the same way LoggedInPage works).
> 
> Then you just derived your page object from AuthSystemPage, implement
> allowedUserRoles() to return the list of 'groups' that are allowed to
> access your page, and you're done.  If you have a bunch of pages taht
> all fall under the same role relationship, like an administrative interface,
> then you could derive an intermediate class, say AdminSystemPage that
> derived from AuthSystemPage, and implemented allowedUserRoles().  That
> way your actual admin pages could then just derive from AdminSystemPage,
> and nothing else.
> 
> It would be quite simlpe, no?
> 
> 
> What do you guys think?
> 
> Now that you guys are starting to add alot of features, maybe it's time
> to start thinking about adding on common high level functionality, like
> content management, user profiles, an auth system, security (one possible
> approach is described above, there may be others that are better).