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 <[email protected]> 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: > http://shiro-user.582556.n2.nabble.com/Change-Shiro-configuration-at-runtime-tp7580921p7580924.html > Sent from the Shiro User mailing list archive at Nabble.com. >
