You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Chris Lewis <ch...@bellsouth.net> on 2007/07/17 00:36:32 UTC
user access control
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: user access control
Posted by Andrea Chiumenti <ki...@gmail.com>.
Chris,
you haven't read carefully!!!
look here:
http://tapestry-jfly.svn.sourceforge.net/viewvc/tapestry-jfly/trunk/JFlyWebCommons/src/main/java/org/jfly/webcommons/filters/SynchronizerFilter.java?view=markup
and here:
http://tapestry-jfly.svn.sourceforge.net/viewvc/tapestry-jfly/trunk/JFlyWebCommons/src/main/resources/META-INF/hivemodule.xml?view=markup
ciao,
kiuma
On 7/18/07, Chris Lewis <ch...@bellsouth.net> wrote:
>
> I apologize for being vague. I don't mean a servlet filter, I mean a
> filter/filtering system with in the tapestry framework. Something that
> might allow me to supply access logic before page rendering, so that I
> don't have to require pages to know about the access control system
> used. I know this can be implemented in pages and simplified by
> subclassing, but I'm wondering if there is a cleaner way, a more
> 'separation of concerns' oriented way (a page is page, not an access
> controller).
>
> Andrea Chiumenti wrote:
> > Of course there is a filter:
> > check my project for some filter samples:
> >
> http://tapestry-jfly.svn.sourceforge.net/viewvc/tapestry-jfly/trunk/JFlyWebCommons/src/main/
> >
> >
> > ciao,
> > kiuma
> >
> > On 7/18/07, Chris Lewis <ch...@bellsouth.net> wrote:
> >>
> >> 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, damien@synect.com <da...@synect.com> 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 <ch...@bellsouth.net> 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 <da...@synect.com> 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: users-unsubscribe@tapestry.apache.org
> >> >> >>> >> For additional commands, e-mail:
> >> users-help@tapestry.apache.org
> >> >> >>> >>
> >> >> >>> >>
> >> >> >>> >
> >> >> >>>
> >> >> >>>
> >> >> >>>
> >> >>
> ---------------------------------------------------------------------
> >> >> >>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> >> >>> For additional commands, e-mail: users-help@tapestry.apache.org
> >> >> >>>
> >> >> >>>
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> ---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> >> > For additional commands, e-mail: users-help@tapestry.apache.org
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >> >>
> >> >>
> >> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: user access control
Posted by Chris Lewis <ch...@bellsouth.net>.
Andrea,
I will look more into JFly, but those from 2 files I can't see any
authentication/access control happening. Again, I am just getting
started with Tap, so my oversight is likely due to that.
thanks again
chris
Andrea Chiumenti wrote:
> like mine :), anyway ....
>
> On 7/18/07, Siddhartha Argollo <sl...@tre-ba.gov.br> wrote:
>>
>> I think so too.
>> My solution was to contribute to MasterDispatcher with a
>> SecurityDispatcher, that is responsible to verify if the user is
>> authenticated, before he has access to a page.
>> It is a request filter, but inside the tapestry framework, not a servlet
>> filter.
>>
>> Chris Lewis wrote:
>> > I apologize for being vague. I don't mean a servlet filter, I mean a
>> > filter/filtering system with in the tapestry framework. Something that
>> > might allow me to supply access logic before page rendering, so that I
>> > don't have to require pages to know about the access control system
>> > used. I know this can be implemented in pages and simplified by
>> > subclassing, but I'm wondering if there is a cleaner way, a more
>> > 'separation of concerns' oriented way (a page is page, not an access
>> > controller).
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: user access control
Posted by Andrea Chiumenti <ki...@gmail.com>.
like mine :), anyway ....
On 7/18/07, Siddhartha Argollo <sl...@tre-ba.gov.br> wrote:
>
> I think so too.
> My solution was to contribute to MasterDispatcher with a
> SecurityDispatcher, that is responsible to verify if the user is
> authenticated, before he has access to a page.
> It is a request filter, but inside the tapestry framework, not a servlet
> filter.
>
> Chris Lewis wrote:
> > I apologize for being vague. I don't mean a servlet filter, I mean a
> > filter/filtering system with in the tapestry framework. Something that
> > might allow me to supply access logic before page rendering, so that I
> > don't have to require pages to know about the access control system
> > used. I know this can be implemented in pages and simplified by
> > subclassing, but I'm wondering if there is a cleaner way, a more
> > 'separation of concerns' oriented way (a page is page, not an access
> > controller).
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: user access control
Posted by Chris Lewis <ch...@bellsouth.net>.
Ok I realize this thread has been dormant for a while, but I'm back to
the issue again. First of all I neglected to mention the first time that
I'm using T5. Siddhartha, I dug into MasterDispatcher after finding it
and thinking this was how it could be done, but I haven't figured it out
yet. I've contributed to it, but the problem is that its configuration
is ordered. So what happens is any Dispatcher I contribute doesn't get
called until after all the rest (PageRender, ComponentAction, etc).
UPDATE!!!!
As I'm writing this I looked at TapestryModule again and notice that
there is an argument allowing me to manipulate where my dispatcher gets
inserted! I have to run, but if you could expand on your implementation
(assuming you can't provide code), that would be great!
Either way, thanks!
Siddhartha Argollo wrote:
> I think so too.
> My solution was to contribute to MasterDispatcher with a
> SecurityDispatcher, that is responsible to verify if the user is
> authenticated, before he has access to a page.
> It is a request filter, but inside the tapestry framework, not a
> servlet filter.
>
> Chris Lewis wrote:
>> I apologize for being vague. I don't mean a servlet filter, I mean a
>> filter/filtering system with in the tapestry framework. Something
>> that might allow me to supply access logic before page rendering, so
>> that I don't have to require pages to know about the access control
>> system used. I know this can be implemented in pages and simplified
>> by subclassing, but I'm wondering if there is a cleaner way, a more
>> 'separation of concerns' oriented way (a page is page, not an access
>> controller).
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: user access control
Posted by Siddhartha Argollo <sl...@tre-ba.gov.br>.
I think so too.
My solution was to contribute to MasterDispatcher with a
SecurityDispatcher, that is responsible to verify if the user is
authenticated, before he has access to a page.
It is a request filter, but inside the tapestry framework, not a servlet
filter.
Chris Lewis wrote:
> I apologize for being vague. I don't mean a servlet filter, I mean a
> filter/filtering system with in the tapestry framework. Something that
> might allow me to supply access logic before page rendering, so that I
> don't have to require pages to know about the access control system
> used. I know this can be implemented in pages and simplified by
> subclassing, but I'm wondering if there is a cleaner way, a more
> 'separation of concerns' oriented way (a page is page, not an access
> controller).
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: user access control
Posted by Chris Lewis <ch...@bellsouth.net>.
I apologize for being vague. I don't mean a servlet filter, I mean a
filter/filtering system with in the tapestry framework. Something that
might allow me to supply access logic before page rendering, so that I
don't have to require pages to know about the access control system
used. I know this can be implemented in pages and simplified by
subclassing, but I'm wondering if there is a cleaner way, a more
'separation of concerns' oriented way (a page is page, not an access
controller).
Andrea Chiumenti wrote:
> Of course there is a filter:
> check my project for some filter samples:
> http://tapestry-jfly.svn.sourceforge.net/viewvc/tapestry-jfly/trunk/JFlyWebCommons/src/main/
>
>
> ciao,
> kiuma
>
> On 7/18/07, Chris Lewis <ch...@bellsouth.net> wrote:
>>
>> 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, damien@synect.com <da...@synect.com> 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 <ch...@bellsouth.net> 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 <da...@synect.com> 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: users-unsubscribe@tapestry.apache.org
>> >> >>> >> For additional commands, e-mail:
>> users-help@tapestry.apache.org
>> >> >>> >>
>> >> >>> >>
>> >> >>> >
>> >> >>>
>> >> >>>
>> >> >>>
>> >> ---------------------------------------------------------------------
>> >> >>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >> >>> For additional commands, e-mail: users-help@tapestry.apache.org
>> >> >>>
>> >> >>>
>> >> >>
>> >> >
>> >> >
>> >> >
>> ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >> > For additional commands, e-mail: users-help@tapestry.apache.org
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >> For additional commands, e-mail: users-help@tapestry.apache.org
>> >>
>> >>
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: user access control
Posted by Andrea Chiumenti <ki...@gmail.com>.
Of course there is a filter:
check my project for some filter samples:
http://tapestry-jfly.svn.sourceforge.net/viewvc/tapestry-jfly/trunk/JFlyWebCommons/src/main/
ciao,
kiuma
On 7/18/07, Chris Lewis <ch...@bellsouth.net> wrote:
>
> 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, damien@synect.com <da...@synect.com> 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 <ch...@bellsouth.net> 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 <da...@synect.com> 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: users-unsubscribe@tapestry.apache.org
> >> >>> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >> >>> >>
> >> >>> >>
> >> >>> >
> >> >>>
> >> >>>
> >> >>>
> >> ---------------------------------------------------------------------
> >> >>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> >>> For additional commands, e-mail: users-help@tapestry.apache.org
> >> >>>
> >> >>>
> >> >>
> >> >
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> > For additional commands, e-mail: users-help@tapestry.apache.org
> >> >
> >> >
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: user access control
Posted by Chris Lewis <ch...@bellsouth.net>.
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, damien@synect.com <da...@synect.com> 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 <ch...@bellsouth.net> 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 <da...@synect.com> 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: users-unsubscribe@tapestry.apache.org
>> >>> >> For additional commands, e-mail: users-help@tapestry.apache.org
>> >>> >>
>> >>> >>
>> >>> >
>> >>>
>> >>>
>> >>>
>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >>> For additional commands, e-mail: users-help@tapestry.apache.org
>> >>>
>> >>>
>> >>
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> > For additional commands, e-mail: users-help@tapestry.apache.org
>> >
>> >
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: user access control
Posted by Andrea Chiumenti <ki...@gmail.com>.
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, damien@synect.com <da...@synect.com> 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 <ch...@bellsouth.net> 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 <da...@synect.com> 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: users-unsubscribe@tapestry.apache.org
> >>> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>> >>
> >>> >>
> >>> >
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>
> >>>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: user access control
Posted by da...@synect.com.
> 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 <ch...@bellsouth.net> 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 <da...@synect.com> 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: users-unsubscribe@tapestry.apache.org
>>> >> For additional commands, e-mail: users-help@tapestry.apache.org
>>> >>
>>> >>
>>> >
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: user access control
Posted by Chris Lewis <ch...@bellsouth.net>.
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
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 <ch...@bellsouth.net> 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 <da...@synect.com> 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: users-unsubscribe@tapestry.apache.org
>> >> For additional commands, e-mail: users-help@tapestry.apache.org
>> >>
>> >>
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: user access control
Posted by Andrea Chiumenti <ki...@gmail.com>.
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 <ch...@bellsouth.net> 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 <da...@synect.com> 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: users-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: user access control
Posted by Chris Lewis <ch...@bellsouth.net>.
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 <da...@synect.com> 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: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: user access control
Posted by Andrea Chiumenti <ki...@gmail.com>.
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 <da...@synect.com> 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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: user access control
Posted by Damien Uern <da...@synect.com>.
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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org