Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »


Creating security checks in your application code is labor-intensive and a dangerous practice as you can very easily miss a check and leave a big security hole open. Standard container-managed authentication and authorization was create to address this issue, but as a role and URL-based security, it's typically too constricting for modern web applications. With Tapestry, it's relatively easy to get started with more generic security checks by creating custom filters and dispatchers, but really, every user of Tapestry shouldn't need to create their own security framework. Developing comprehensive, proven bullet-proof security framework is difficult and therefore, Tynamo's tapestry-security module provides tight integration with Apache Shiro, an established, high-performing and easy-to-use security framework, for Tapestry applications.

Using security

There are several aspects to providing security. Technically you can either hide functionality from user's view if he doesn't have permissions to it, visibly disable or lock certain functionality or display errors if user is trying to do something illegal. There are several possible integration points for making security checks: for example, you may restrict users' access to certain URLs, secure access to the data itself or make specific checks before executing certain functionality. Tapestry-security module supports all of the above types of authorization.

In a typical case, you need

Providing configuration

Shiro's default configuration model uses an INI file (a property file with sections). You can use a standard Shiro INI configuration file (see Shiro's documentation for more info) with tapestry-security and in addition, you can configure security in code and with annotations.

The simplest and most typical security models are based on role/type permissions. This is very simple to do with the provided security annotations.

Configuring security

To configure security, you need to make these main changes:

  • Add an Acegi Filter proxy in your web.xml so Acegi can process and provide security for incoming requests
  • Configure Acegi beans to fit your purposes. It's easiest to keep Acegi configuration in a separate Spring configuration and then load multiple configuration files.
  • Configure Trails Security Service and Security Decorator so Trails so Trails know to use the security annotation to process the UI. * In case of Hibernate, change your Trails persistence implementation to use SecurePersistenceServiceImpl and TrailsSecurityInterceptor.

You may use the trails-secure-archetype to add security to your project. This security archetype is meant to be run on an existing Trails project. It's not ideal as it'll overwrite your pom.xml (to declare dependency to trails-security and web.xml (to set the Acegi filter proxy), as unfortunately the current version of the Maven archetype plugin is a bit too primitive to provide better support for more complex cases like this. As such, trails-secure-archetype is most suitable for adding security into test projects or newly created projects with Trails-archetype (as described in the Quick start).

To use the security archetype, run (on a single line) the following command in the parent directory of your project:



Above, use -DremoteRepositories= if the version of archetype you are trying to use is not yet available in (mostly with snapshots)

To modify the sample authentication to fit your use case, it's worth to familiarize yourself with Acegi framework, as it offers heaps of authentication options and security models. The archetype adds two default users (user:user, admin:admin) as a sample using the aforementioned SpringSeedEntityInitializer. The configuration of these beans is in Spring configuration file applicationContext-seedData.xml.

#labels Featured
= Annotation =

For a declaratory security management at our disposal is the following annotations
/* For methods */

/* For classes */

== Secure pages ==

public class AdminPage {

== Secure actions ==

public class Index {

public void onActionFromDeleteNews(EventContext eventContext)

Unknown macro: { ... }

== Secure Services ==

=== Secure Service Method ===

public interface AlphaService

Unknown macro: { @RequiresAuthentication void secureMethod(); }

public class AlphaServiceImpl implements AlphaService {

public void secureMethod()

Unknown macro: { ... }



=== Secure Service Class ===

public interface AlphaService {

void secureMethod1();

void secureMethod2();

public class AlphaServiceImpl implements AlphaService {

public void secureMethod1()

public void secureMethod2()

Unknown macro: { ... }



= Filters =

The configuration of filters is fully consistent with the documentation JSecurity. By default configuration is configured in the file security.conf section [url]

/authc/signup = anon
/authc/** = authc

/user/signup = anon
/user/** = user

/site/user/** = roles[user]
/site/manager/** = roles[manager]

/news/view/** = perms[news:view]
/news/edit/** = perms[news:edit]

= Components =
== Examples ==
Hello, $

Unknown macro: {username}


<t:actionlink t:id="createAccount">Create account</t:actionlink>

<t:jsec.hasRole role="admin">
<t:actionlink t:id="delete">delete user</t:actionlink>

= Spring Integration =
Tapestry-JSecurity can be used in spring environment.

  • No labels