Attachments don't come through to the mailing list but so you have a table
that describes permissions for all of the entities? Obviously, visually
showing or hiding buttons on the client doesn't really enforce security but
you are right, Tynamo doesn't really offer anything for this case out of
the box. It'd relatively easy to write custom security annotations for your
case though, for example following the source code in tapesty-security-jpa
(see http://www.tynamo.org/tapestry-security-jpa+guide/). On the other
hand, if you used the same CRUD pages for all your entities (similar to
http://www.tynamo.org/tapestry-model+guide/), you'd only need to implement
the security checks in one place, making annotations quite useless. It all
depends on how complex your data is and how customizable you need your
pages to be. If you have a lot of entities but it editing the data is
mainly form-based, I'd almost encourage you to take a look at
tapestry-model and how well that would work for you. There's a fair bit to
learn there if you need to customize the pages heavily but it could give
you a lot for free, including having the security checks all in on page
(both visually and at the data level).
Kalle
On Sun, Nov 26, 2017 at 3:09 PM, Christopher Dodunski <
chrisfromtapes...@christopher.net.nz> wrote:
> Hi Basile,
>
> Thanks for replying. Yes, I'd discovered Tynamo, but wondered whether it
> might be overkill given that I'd already inherited authentication code
> from the Tapestry Hotel demo app.
>
> It wasn't clear on the Tynamo site how Tynamo acquires permissions from my
> (attached) 'role' table. And if I have to write code to do this, then why
> I need Tynamo rather than just creating a method in my user entity class
> along the lines of...
>
> if(currentUser.isPermitted("company:create")){
>
> //Show create company button
>
> }
> else{
>
> //Grey out or hide create company button
>
> }
>
> Regards,
>
> Chris.
>
>
> > http://www.tynamo.org/tapestry-security+guide/
> >
> > https://tapestry.apache.org/security.html
> >
> > Le 26/11/2017 à 05:16, Christopher Dodunski a écrit :
> >> Hi All,
> >>
> >> The Tapestry Hotel demo app has proven a good lesson in implementing
> >> AUTHENTICATION. Having developed a multi-user Tapestry app, I now need
> >> to
> >> implement AUTHORISATION, but the Hotel demo app is aimed at just one
> >> user
> >> type: visitors.
> >>
> >> I created a role table in my Tapestry application (screenshot attached).
> >> Permissions are specified in terms of CRUD actions, meaning there are
> >> four
> >> columns for each domain (Hibernate) entity: e.g. CAN_CREATE_USER,
> >> CAN_READ_USER, CAN_UPDATE_USER, CAN_DELETE_USER, etc.
> >>
> >> The Hotel demo app enforces authentication by including or excluding the
> >> @AnonymousAccess annotation on page classes. I imagine enforcing page
> >> authorisation could be done similarly, using a single annotation. This
> >> could prevent users lacking the necessary privilege from accessing
> >> certain
> >> pages, for instance 'pages/DeleteUser.java'. Ideally, though, it would
> >> be
> >> desirable to also prevent users from navigating to such pages in the
> >> first
> >> place. Either the PageLink icon is greyed out, or there is no link.
> >>
> >> I am seeking some direction - perhaps even some example code - in how to
> >> have my Tapestry application enforce the privileges specified in my role
> >> table.
> >>
> >> Thanks & regards,
> >>
> >> Chris.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> >> For additional commands, e-mail: users-h...@tapestry.apache.org
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
