On Thu 18.10.2012 13:18, Carl-Eric Menzel wrote:
[X] I use Shiro
We use Shiro on our project (using wicketstuff's shiro integration and
our own custom Shiro realm implementation). We use it because it gives
us a permission-based approach (not just roles-based) and is more
easily configured
[ X ] I use my own custom framework
[ X ] I use Shiro
For my current Wicket project we started out with Shiro as it promised
to be easy to use. However, even though Shiro is feature rich, it still
lacks the feature we needed to make it secure (1) and stable (2). We
ended up using Shiro as
[x] I use WASP/Swarm
Since we started our project we adopted Swarm as our security framework and
for several reasons we didn't scout other possibilities to secure our pages.
By the way our experience with Swarm is pretty good, we don't need any
changes in our dependencies...
--
View this
[X] I use Shiro
Because it's simple in use and simple to integrate with Wicket or other
frameworks, but still powerful enough for most security related tasks.
And because I liked it more than Spring Security three years or so ago.
I think Spring Security is more feature complete out of the box
[X] I use Shiro
We use Shiro on our project (using wicketstuff's shiro integration and
our own custom Shiro realm implementation). We use it because it gives
us a permission-based approach (not just roles-based) and is more
easily configured than e.g. SWARM/WASP. I also quite like the
[X] I use my own custom framework
We rolled our own because it gave us the most flexibility (components are
annotated and the permissions are kept separate from users and
groups/roles). We can reconfigure the permissions on the fly (since
everything is stored in the DB, cached in mem) and plug
We use an in house designed system very similar to Shiro. The security
framework only works on permissions (not roles), but the permissions
that a user has depends on the roles they belong to (implementation
detail the framework does not care about).
It also does not allow Shiro style string
[x] I use my own custom framework
We needed to have a group-based authentication: a relation between a
secured-item (a bean, linked to a DB item) and some allowed-groups for that
item.
But the relation itself is quite complex to establish (because Items are in
a graph), so we decided to implement
[ ] I use my own custom framework
We rolled our own too because we needed multi-tenant support on
steroids for our enterprise content management system.
Eg, A group called admin can not give administer rights to all
organizations in the system - only one specific organization.
In other words