Re: user access control
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: user access control
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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: user access control
like mine :), anyway On 7/18/07, Siddhartha Argollo <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: user access control
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: user access control
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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, [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:
>> >&
Re: user access control
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 <[EMAIL PROTECTED]> 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, [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:
>> >>> >
>> >>> > in ur code:
>> >>> >
>> >>> > getRequest().isUserInRole('somerole');
>> >>> >
>> >>> > Ciao,
>> >>> > kiuma
>> >>> >
>> >>> > On 7/17/07, Damien Uern <[EMAIL PROTECTED]> wrote:
>> >>> >>
>> >>> >> Chris Lewis wrote:
>> >>> >> > Hello all,
&
Re: user access control
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 <[EMAIL PROTECTED]> 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, [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:
>> >>> >
>> >>> > 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
Re: user access control
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:
>>> >
>>> > 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 pageV
Re: user access control
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:
>>> >
>>> > 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]
Re: user access control
> 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:
>>> >
>>> > 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]
Re: user access control
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 <[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:
>
> 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]
Re: user access control
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:
>
> 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]
Re: user access control
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:
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]
Re: user access control
do u want jaas ?
if so:
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]
Re: user access control
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]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
