Hi Jack,
Where does the cache reside? In the client application? Or in the
server hosting the Shiro environment?
Without understanding your environment further, the way I would do
this is the following:
Every time the client application calls into your server hosting the
Shiro environment, it needs to provide some information that the
server can use to build a Subject instance that represents the calling
application. This information is almost always an application-level
username/password pair (e.g. via headers for HTTP Basic
authentication) or a session id for an application-level session that
was established earlier. For most modern 'RESTy' environments, it's
usually common these days for the client application to authenticate
on every request, always sending the username/password in the headers.
Once this information enters the server, the request is authenticated,
and a Subject instance is created and bound to the current thread. If
doing this via HTTP and headers, the Shiro web support (with the
'authcBasic' filter) does this automatically. If you're not using the
web support + filters, you'll need to build the Subject your self and
then bind/unbind it from the thread (e.g. for RMI or other type of
non-http remoting). This is covered in Shiro's Subject documentation
(Custom Subject Instances)
Once the subject is set up and bound to the thread, you can check
against it like any other user - except in these cases, the Subject
represents the client application, not a person (this is why we use
the name 'Subject' instead of 'User' since the 'currently executing
entity' can be anything, not just a person).
Then you can check whatever you want, e.g.
if ( !SecurityUtils.getSubject().isAuthenticated()) {
//don't allow access to the cache
}
HTH,
--
Les Hazlewood
CTO, Katasoft | http://www.katasoft.com | 888.391.5282
twitter: http://twitter.com/lhazlewood
katasoft blog: http://www.katasoft.com/blogs/lhazlewood
personal blog: http://leshazlewood.com
