If you have JdbcRealm / CustomRealm / Stormpath as your
data store, you would have the exact solution you desire.
shiro.ini is considered a “read-only” initialization file, and not a substitute 
for a data store.

> On Jan 28, 2016, at 3:56 PM, midiman <[email protected]> wrote:
> 
> Hi,
> Yeah, restarting the web app I can do - but that's not a real solution for a
> production system.
> 
> The Use Case is simple, and I would have thought very common:
> * Start the web app
> * Load the RBAC system
> * Admin changes roles/permissions (in my case it's outside the web app for
> security, but could just as easily be within the app)
> * RBAC flushes/reinitializes to reflect the changes in the running web app
> * Web app carries on running
> 
> Surely every web app in the world would want to do this, yes?
> 
> If I added a new user to this mailing list as a sysop, I wouldn't want to
> bring Nabble down for those user changes to take effect?
> If I do it programmatically via the API, that's extra coding logic that
> shouldn't need to be in the app code. Moreover, that logic would be separate
> from the persistent state (e.g. ini or db) when the app does restart (e.g.
> after system maintenance reboot). Having to do the configuration twice -
> once persistently and once via runtime api isn't an ideal way to solve this
> problem.
> 
> You must have come across this when using Shiro (or any rbac). How have you
> solved this if Shiro doesn't have a built-in mechanism? Maybe I'm missing
> something from the Shiro docs - I've had a good look through but there is no
> information on this subject.
> 
> Thanks,
> Peter
> 
> 
> 
> 
> --
> View this message in context: 
> http://shiro-user.582556.n2.nabble.com/Change-Shiro-configuration-at-runtime-tp7580921p7580928.html
> Sent from the Shiro User mailing list archive at Nabble.com.
> 

Reply via email to