On 08/07/2014 15:28, Christopher Schultz wrote: > All, > > In order to help me with a few sundry operations, I've written > some crude command-line tools that use JMXProxyServlet to do my > bidding. > > Here's a gem: > > for sessionid in `wget -qO - > 'http://localhost/manager/jmxproxy?invoke=Catalina:type=Manager,context=/myapp,host=localhost&op=listSessionIds' > > | sed -e "s/ /\n/g" | grep '^[0-9A-Z]\+\(\..*\)\?$' | grep -v "^OK$"` ; > do wget -qO - > "http://localhost/manager/jmxproxy?invoke=Catalina:type=Manager,context=/myapp,host=localhost&op=getSessionAttribute&ps=$sessionid,user"; > > ; done > > That dumps out all the users currently logged-in, plus a bunch of > "OK - Operation getSessionAttribute without return value" outputs. > > Tweaking the above command, I can get Tomcat to give me the list > of sessions for which there is no user, for example. > > Now, let's say that I want to expire all the sessions for which > there is no user. I can run the above command (with obvious > modifications) and get a list of session ids for which there are > are no users, and then I can execute /another/ call to > JMXProxyServlet calling expireSession with the id of the session. > > While that sounds like fun, I wonder if there isn't a better way. I > also think this idea could be useful for other operations as well: > allow the use of an EL expression that can be used to match > sessions. > > For instance, one could write an EL expression that would be > executed on each session and return a true/false (or maybe just > true/not-true), and then expireSessions (plural, to distinguish it > from the existing single-session expiration operation). Something > like this: > > ${!empty session.user && ((now - session.lastAccessedTime) > > 120000)} > > Asking JMXProxyServlet to expire all sessions matching the above > expression would then kill any session that had no user attribute > (might have to use session.getAttribute('user')... I'm no EL > expert) and was also left unattended for 2-minutes or more. > > Is there any interest in this kind of thing? Parsing (specifically) > and executing EL expressions on the fly might be a bit expensive > for administrative operations, but of course one does not need to > use such features if one does not want to. > > I haven't really thought about it too much, but I suspect there > would be other situations where being able to filter objects using > an EL-based predicate might be useful.
Executing arbitrary user provided EL expressions often creates all sorts of security problems. My concern is that the complexity of implementing this securely may outweigh the benefit it brings. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
