We have a similar setup, sounds like you need two filters. First is your application filter - in it's init method it spools up all your system services (that's about all it does, exception handling maybe but no certainly no session stuff). Next you have the standard shiro filter. Then you write your own shiro filter to use in shiro.ini which deals with the other stuff. Nice and flexible and you can configure it against any urls etc.
Luke On 21 September 2011 01:31, dan <[email protected]> wrote: > Hi Les, > > Your idea was right on .. my shiro filter is second in line. Our > application has a filter which is first. The reason shiro is second is > that > a number of services need to be initialized in order for shiro to operate. > Here are some examples to give you a flavor: > > 1. We only permit logins if the user is enabled. This boolean is pulled > from > the database, so the database subsystem needs to be initialized. > > 2. We allow access based on a client's company license. What we do is go > to > the database and retrieve the company license info. > > 3. We have properties which we read in from files. Some of these > properties > help in the decision process. > > Perhaps our app is "backwards", but can you comment on how you would > structure an application to support all this? > > Many thanks, > Dan > > -- > View this message in context: > http://shiro-user.582556.n2.nabble.com/Using-native-web-sessions-tp6799265p6814424.html > Sent from the Shiro User mailing list archive at Nabble.com. >
