Thank you for your insights. I guess my only complaint is I don't like
forcing pages to implement their security, even through inheritance. I
don't guess there's a filtering system of some sort? Page extention isnt
the end of the world, I'm just curious if this way is a best practice.
Andrea Chiumenti wrote:
> And if you are practice you can also implement you custom jaas login
> module,
> so to keep atuhentication and authorization business logic outside
> your web
> application, like I do un my WL or JBoss counsultancy activity.
>
> Good work,
> kiuma
>
> On 7/18/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>>
>> > Thanks Kiuma,
>> >
>> > Being that when a new user is added to the system, the system
should
>> > create a default role/set of perms, I don't think relying on
>> web.xml is
>> > workable. It seems like a db table (mapped via hibernate) would be
the
>> > best way, but as I'm just migrating to tapestry/java web
development,
>> > any opinions are welcome.
>> >
>> > chris
>>
>> Yes we store user information in a Person table and hold on to the
>> currently logged in user inside the Visit object (we use a custom
class
>> called "Session"). The Person table has a relationship to the role
table
>> which has a relationship with the permissions table. We store
permission
>> check methods inside an "Authority" class, gettable from the Session.
So
>> you could have:
>>
>> child page class:
>>
>> @Override
>> public void checkPerms() throws PermissionException {
>> if (!getSession().getAuthority().canAccessSomethingReport()) {
>> throw new PermissionException("User is not allowed to access
this
>> page.");
>> }
>> }
>>
>> parent page class:
>>
>> public abstract checkPerms() throws PermissionException;
>>
>> public void pageValidate(PageEvent event) {
>> try {
>> checkPerms();
>> }
>> catch (PermissionException e) {
>> throw new PageRedirectException("Forbidden");
>> }
>> }
>>
>> It seems to work for us, but there may be better ways of doing it.
I've
>> never used JAAS either.
>>
>> Damien
>>
>> >
>> > Andrea Chiumenti wrote:
>> >> yes for every Q!
>> >>
>> >> "It looks like this method checks against a role list in the
>> deplyment
>> >> descriptor" -> JAAS (if u mean web.xml)
>> >>
>> >> Ciao,
>> >> kiuma
>> >>
>> >> On 7/17/07, Chris Lewis <[EMAIL PROTECTED]> wrote:
>> >>>
>> >>> So all pages that are restricted must extend a page that
implements
>> the
>> >>> security checks perms and handles enforcement, correct?
>> >>> Regarding jaas, I've not used it before, but the
>> >>> HttpServletRequest#isUserInRole method uses it? It looks like
this
>> >>> method checks against a role list in the deplyment descriptor.
>> >>>
>> >>> Thanks tons for your input!
>> >>>
>> >>> chris
>> >>>
>> >>> Andrea Chiumenti wrote:
>> >>> > do u want jaas ?
>> >>> > if so:
>> >>> > <inject property="request" object="service:
>> >>> > tapestry.globals.HttpServletRequest"/>
>> >>> > in ur code:
>> >>> >
>> >>> > getRequest().isUserInRole('somerole');
>> >>> >
>> >>> > Ciao,
>> >>> > kiuma
>> >>> >
>> >>> > On 7/17/07, Damien Uern <[EMAIL PROTECTED]> wrote:
>> >>> >>
>> >>> >> Chris Lewis wrote:
>> >>> >> > Hello all,
>> >>> >> >
>> >>> >> > I am seeking information/code samples on how to implement
user
>> >>> access
>> >>> >> > control in Tapestry (4.1.2). Specifically, restricting pages
to
>> >>> >> > authenticated users. I assume that all restricted pages
would
>> >>> have to
>> >>> >> > make a call to an authentication system, checking if the
>> user is
>> >>> >> logged
>> >>> >> > in and if they have access to the page. If a user tries to
>> access
>> >>> a
>> >>> >> page
>> >>> >> > they are not authorized to view, then "something" should
>> happen.
>> >>> This
>> >>> >> > something may just be a message or an error page - the
>> important
>> >>> >> part is
>> >>> >> > how to implement this across pages or a group of pages.
Thanks
>> for
>> >>> >> your
>> >>> >> > input!
>> >>> >> >
>> >>> >> > chris
>> >>> >>
>> >>> >> Piece of cake, you can create a page that handles
authentication
>> >>> >> checking as follows:
>> >>> >>
>> >>> >> public abstract class AbstractSecurePage extends AbstractPage
>> >>> implements
>> >>> >> PageValidateListener {
>> >>> >>
>> >>> >> InjectState("visit")
>> >>> >> public abstract Session getSession();
>> >>> >>
>> >>> >> public void pageValidate(PageEvent event) {
>> >>> >> //check user permissions here e.g.:
>> >>> >>
>> >>> >> if (!getSession().isUserLoggedIn()) {
>> >>> >> throw new PageRedirectException("LoginPage");
>> >>> >> }
>> >>> >> }
>> >>> >>
>> >>> >>
>> >>> >> }
>> >>> >>
>> >>> >> Hope that helps :D
>> >>> >>
>> >>> >> Damien
>> >>> >> --
>> >>> >>
>> >>> >>
>> >>> >> Damien Uern
>> >>> >> Online Applications Developer
>> >>> >> Synect Online Solutions
>> >>> >>
>> >>> >>
>> ---------------------------------------------------------------------
>> >>> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >>> >> For additional commands, e-mail:
[EMAIL PROTECTED]
>> >>> >>
>> >>> >>
>> >>> >
>> >>>
>> >>>
>> >>>
>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >>> For additional commands, e-mail: [EMAIL PROTECTED]
>> >>>
>> >>>
>> >>
>> >
>> >
>> >
---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>> >
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
