shiro-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lenny Primak <>
Subject Re: Change Shiro configuration at runtime
Date Thu, 28 Jan 2016 21:17:05 GMT
Storing roles / permissions / etc. in shiro.ini is a bad practice, and is shown in the docs
for simplicity only.
In production system, any roles / permissions, etc. would be stored in a data store, not shiro.ini,
and thus would not require any changes to the application when users / roles change.

You can use JdbcRealm, custom realm or Sormpath for the above data store.

> On Jan 28, 2016, at 3:13 PM, midiman <> wrote:
> Hi,
> Many thanks for your quick reply!
> It's an interesting take on it.
> I guess I look at this the other way round - I would have thought this would
> not only be standard, it would be needed in 90-100% of Use Cases.
> In a web environment, and in particular a role-based one, you'll have
> admins, users, guests, etc.
> The admins will typically have rights to change the roles/permissions of
> other users.
> So let's say for example the admin changes the guest user's role from one
> that can read some stuff to one that can read all stuff.
> The changes, in this case are going into an ini file (in a secure area on
> the web server's file system, so there's no additional security risks that
> aren't there at startup) but it could equally be anywhere else - db or
> similar. Now the rbac configuration is changed, but Shiro doesn't take these
> changes until the web app is restarted.
> In a production environment, restarting a web app just to apply some
> permission changes for one user isn't really ideal. Flushing a cache and/or
> re-initializing would be the expected behaviour.
> I would have thought that just about all implementations of shiro would, at
> some point, want to change the configuration, but without needing to restart
> their app (unless it's a standalone/short-lived app - e.g. desktop calendar
> app or similar).
> Interestingly, when I use shiro in a non-web environment (i.e. not using
> web.xml) it does reload changes to the ini file. But when loaded via a web
> container (I'm using Jetty 8.1), it doesn't.
> Yes, I can programmatically detect the changes, reload permissions etc. but
> that feels a lot like writing my own rbac system, there seems no need for it
> when shiro could (or should) just reinit itself, and carry on.
> I'm really surprised Shiro wouldn't have a [strightforward] mechanism to
> perform runtime config changes.
> Before asking this question, I had a search around as I figured this is a
> very common use case. There are lots of questions asking about this. Yours,
> so far, is the only answer (and I thank you for that)!
> Many thanks
> Peter
> --
> View this message in context:
> Sent from the Shiro User mailing list archive at

View raw message