Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
titleVersion status: 0.5.1 stable for T5.3, 0.34.1 6 stable for T5.2 and 0.2.2 for T5.1

tapestry-security module is based on and depends on Apache Shiro. 0.4.1 depends on Apache Shiro 1.2.0, earlier versions depend on 1.1.0
0.3.x and 0.2.x are currently functionally the same but 0.3.x uses 5.2.x apis. Critical issues will be fixed for 0.4.x, feature development only for 0.45.x versions. Versions before 0.4.0 are not maintained anymore.
0.4.0 introduced fully Tapestry-style configuration and performance improvements.


0.4.1 also introduced a dependency to tapestry-exceptionpage. The security exceptions thrown from the filters annotation handlers are all handled by the same exception handler assistant. You can also handle other generic exceptions in your application the same way, read more about it at tapestry-exceptionpage guide. Configuration via shiro.ini is possible for


version before 0.4.0


titleHere's a simple example of configuring url/role permissions with *shiro.ini*
Code Block
/index.html = anon
/user/signup = anon
/user/** = authc
/admin/** = authc, roles[administrator]
/news/view/** = perms[news:view]

Use lowercase throughout the shiro.ini file configuration. If you prefer using a shiro.ini configuration file, place it at the root of your classpath and set SecuritySymbols.SHOULD_LOAD_INI_FROM_CONFIG_PATH to true in your ApplicationDefaults.

Code Block
public static void contributeApplicationDefaults(MappedConfiguration<String, String> configuration)
		configuration.add(SecuritySymbols.SHOULD_LOAD_INI_FROM_CONFIG_PATH, "true");


but the support for it was removed an unanimous community vote. anon() and authc() etc. above refer to the Shiro filter names. See all Shiro filters available by default.


You don't actually need an INI file - you can do the same in code, for example:

Code Block
public static void contributeSecurityRequestFilter(OrderedConfiguration<FilterChainDefinition> configuration)
		configuration.add("index-anon", new FilterChainDefinition("/index.html", "anon"));
		configuration.add("signup-anon", new FilterChainDefinition("/user/signup", "anon"));
		configuration.add("user-user", new FilterChainDefinition("/user/**", "authc"));
		configuration.add("admin-roles-administrator", new FilterChainDefinition("/admin/**", "roles[administrator]"));
		configuration.add("news-view", new FilterChainDefinition("/news/view/**", "perms[news:view]"));


titleT5.1.0.5 users

Beware that because of TAP5-1018 "Request to Application Root path ignores ComponentRequestFilter's (fixed in unreleased T5.1.0.8 and T5.2.x), annotations don't work correctly on Start page. Use Index pages instead.

To declaratively secure your pages, you can use the following annotations:


The names of following components should give you a pretty good hint of their purpose, can you guess what all of them do? 0.5.1 also added support for an p:else block for all the built-in security components.

Code Block