I believe I've already stated this via the mailing list, but if not, I'll re-iterate it here (and maybe our documentation coordinator can turn this into living documentation in the wiki):
There is example configuration for the Inspektr package here: https://www.ja-sig.org/svn/cas3/trunk/cas-server-webapp/src/main/webapp/WEB-INF/unused-spring-configuration/auditTrailContext.xml Documentation and code exists for the Inspektr package here: http://code.google.com/p/inspektr/wiki/EnablingStatisticsAndAuditing If you enable that auditTrailContext.xml and execute a few CAS statements you'll notice some audit stuff written to the console (since the ConsoleAuditTrailManager is enabled). That should give you a pretty good idea of how that works. Writing your own AuditTrailManagers, which are similar in concept to EventHandlers, should meet your needs. There are only minor differences: 1. The "event" has been made generic so you'll need to look at the action to find out what happened 2. The "event" contains a collection of information about the overall request (i.e. action, user, resource, etc.) Again, letting the ConsoleAuditTrailManager execute a few times will give you a pretty good idea of what happens. You can configure any number of AuditTrailManagers. I understand and sympathize that you need information quickly for a deadline, but you also need to be aware that I've been out of the office, and even though I am back in the country and responding to emails I am still on vacation until Tuesday and thus any responses are on my own time and interfering with my vacation ;-) -Scott On Fri, May 16, 2008 at 1:22 PM, Adam Rybicki <[EMAIL PROTECTED]> wrote: > Scott, > > Please forgive my mentioning Ben. You sent a public e-mail on May 6th > notifying the list that you would be out May 10 to May 16, and that you will > have no Internet or phone access. I am under pressure to make my code work > in 3.2, and no amount of looking at 3.2 will help me. > > So you show me that CentralAuthenticationServiceImpl now, with the use of > annotations, emits TICKET_GRANTING_TICKET_DESTROYED and > TICKET_GRANTING_TICKET_CREATED > *something*. What is it? An event? A log file entry? This really isn't > clear to someone who didn't write the code. You are saying that "they > should both give you the resource (ticket id), the user they were created > for, and some additional information." Perfect! That's exactly what I > need. What do I do to receive these? > > You also say that "if you merely need to do certain things at the web tier > level, you should be using Spring's Handler Interceptors which are designed > to be used with the Handler Mappings and should thus not require > modification to core classes." Well, I don't merely need to do things at > the Web tier. In fact, I would expect to handle these ticket notifications > without any Web interaction. And what are "Spring's Handler Interceptors" > or "Handler Mappings" anyway? A quick Google search seems to indicate some > association with Spring's Web MVC. I'll add this to my list of things to > read about one day when I'm not busy. > > In 3.1 there was a sample TestEventHandler. As simplistic as it was, I was > able to follow it and write my handler without ever bothering this list. I > have had no luck finding anything like this in 3.2. > > Look, you know this stuff inside and out. Few others do, and I certainly > don't. You also get and answer tons of e-mail including the ones i write. > Wouldn't it be easier to point people like myself to a CAS Manual page? > Point me in the direction of sample code or documentation that I can use, > and I promise to write a Confluence page on how to write a handler to > consume these events or whatever they are supposed to be called. > > Thank you, > Adam > > Scott Battaglia wrote: > > The current Inspektr package is perfectly capable of intercepting both > ticket creation and ticket destruction events (as well as service ticket > validation and creation). Its also designed to collect data from the entire > flow from web tier to service layer (something the original event handler > structure could not do). > > Take a look at the auditable annotations on the > CentralAuthenticationServiceImpl: > > http://developer.ja-sig.org/source/browse/jasigsvn/cas3/trunk/cas-server-core/src/main/java/org/jasig/cas/CentralAuthenticationServiceImpl.java?r=43396 > > There is one defined for "TICKET_GRANTING_TICKET_DESTROYED" and one also > defined for TICKET_GRANTING_TICKET_CREATED. They should both give you the > resource (ticket id), the user they were created for, and some additional > information. > > If you merely need to do certain things at the web tier level, you should > be using Spring's Handler Interceptors which are designed to be used with > the Handler Mappings and should thus not require modification to core > classes. > > Regardless of whether you ask Ben or myself, Rutgers is committed to > supporting the Inspektr package as the means of notifying the system of > actions that occur within CAS. The goal is to create an extensible auditing > and statistics package that can be used in any Java application. We > currently use it in both CAS and our online Web Registration system with > great success, and are looking at additional applications. It will continue > to evolve separately as a product, with CAS gaining any of the new features > introduced in the package. It has the benefit of being developed outside of > the scope of CAS, thus getting additional developers looking at it, while > the CAS use cases will always remain one of factors driving its evolution. > > Our recommendation for extending the web tier is and has always been to > utilize the methods provided with Spring Web Flow and the Spring MVC layer > which can either include additional actions or the Handler Interceptor > Adaptors. > > -Scott > > On Thu, May 15, 2008 at 9:17 PM, Adam Rybicki <[EMAIL PROTECTED]> wrote: > >> Andrew, >> >> I think that you and I both have stumbled into requirements that the >> EventHandler interface in 3.1 was capable of solving. I managed to find >> that interface, and even though its original intent was to facilitate >> auditing, I was able to use it to monitor TGT creation and destruction and >> act on those events (TicketEvent). My EventHandler implementation had >> nothing to do with auditing. >> >> Your requirements, if I understand them correctly, could have a solution >> by implementing a 3.1 EventHandler that would process the HttpRequestEvent. >> >> Which makes me think that the event model, which allows CAS "extensions" >> without modifying CAS code itself, is useful. Perhaps I made a mistake of >> using an interface intended for auditing for a different purpose entirely. >> Still, I had a real-life need to be notified of TicketEvents, and you have a >> need to be notified of HttpRequestEvents. Perhaps the EventHandler >> interface and the entire event pattern is useful enough to preserve in CAS. >> This pattern neatly hides the AOP details, which is a good thing for >> AOP-handicapped people like me. ;-) >> >> This whole ApplicationEvent pattern on which the CAS 3.1 events were built >> seemed like a useful thing in CAS. I found a use case for it, and perhaps >> others would. What do you think? It would be good to know Scott's opinion, >> but Scott is out this week. I wonder if Ben Oshrin has an opinion on this >> matter. >> >> I have a feeling that it should be possible to "resurrect" the >> org.jasig.cas.event package. >> >> Thanks, >> Adam >> >> Andrew R Feller wrote: >> >> Adam, >> >> I spent a day or so reviewing the possible pointcuts to apply advice to, >> however depending on what you want, you may or not be able to use AOP to tie >> into the creation and destruction of ticket granting tickets. With Spring >> AOP, it cannot apply advice to classes and methods that are marked as final >> as it cannot override them. >> >> >> In my case, I need to have access to the HttpServletRequest and >> HttpServletResponse along with users' credentials, so the pointcuts I need >> are the LogoutController's handleRequestInternal() method and the >> AuthenticationViaFormAction's submit() method. >> >> >> If you do need access to either HttpServletRequest or HttpServletResponse, >> then you can write some advice that goes against the >> CentralAuthenticationServices interface's createTicketGrantingTicket() and >> destroyTicketGrantingTicket() methods as this is not a problem for AOP. >> >> >> Scott: What would you recommend in my situation to tie into creation and >> destruction of TGTs but with access to HttpServletRequest / >> HttpServletResponse? I currently have a custom Spring Webflow Action that I >> have configured to be called if a success event occurs from the >> AuthenticationViaFormAction state. However, in order to hook into logout, I >> had to design a custom logout controller. >> >> >> Thanks, >> >> Andrew R Feller, Analyst >> University Information Systems >> 200 Fred Frey Building >> Louisiana State University >> Baton Rouge, LA, 70803 >> (225) 578-3737 (Office) >> (225) 578-6400 (Fax) >> >> -----Original Message----- >> >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] <[EMAIL PROTECTED]>] On >> Behalf Of Andrew R Feller >> >> Sent: Monday, May 12, 2008 10:22 AM >> To: Yale CAS mailing list >> Subject: RE: How to integrate a login & logout event listener in CAS Server ? >> >> Adam, >> >> I encountered the same issue whenever I deployed CAS 3.0.7 / 3.1.0 as I >> needed CAS to create and destroy an additional cookie upon login / logout. >> At the time, the only solution available was to create a custom Spring >> WebFlow state for the login process and extend the logout controller to >> expire my cookie upon logout. >> >> >> I am perfectly aware that this isn't elegant or desirable as I am dealing >> with upgrading to CAS 3.2.1, so I would love to hear a solution, too! I am >> available for private conversation about this if you want to talk more. >> >> >> Thanks, >> Andy >> >> Andrew R Feller, Analyst >> University Information Systems >> 200 Fred Frey Building >> Louisiana State University >> Baton Rouge, LA, 70803 >> (225) 578-3737 (Office) >> (225) 578-6400 (Fax) >> >> >> ________________________________________ >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] <[EMAIL PROTECTED]>] On >> Behalf Of Adam Rybicki >> >> Sent: Wednesday, May 07, 2008 9:01 PM >> To: Yale CAS mailing list >> Subject: Re: How to integrate a login & logout event listener in CAS Server ? >> >> Scott, >> >> I am back from the conferences and resolving this issue has come to the top >> of my priority list. I spent some time looking at 3.2.1, and I have not >> been able to figure out how to weave my custom code into this new package. >> Let me elaborate... >> >> >> My custom code needs to perform some work when a TGT is created or >> destroyed. I looked at the sample auditTrailContext.xml. This sample has >> no comments that would hint at "hooking in" custom auditing code. I am not >> schooled in AOP, and while I understand the concepts, some additional hints >> would help. I just do not see how to configure the system to notify my code >> of TGT creation and destruction. >> >> >> CAS manual on the JA-SIG Wiki has nothing on the subject. Can you please >> point me in the right direction? >> >> Thanks, >> Adam >> >> Scott Battaglia wrote: >> We switched to the Inspektr package for a few reasons: >> >> >> 1. It provides end-to-end auditing, it can track user, ip address, and >> action all in one transaction >> 2. its an open-source library developed by two coworkers and myself that can >> be incorporated into other projects, allowing for knowledge re-use. >> Eventually the tool will include a web application to view the results. >> >> 3. supports statistics gathering >> 4. code is completely externalized from the CAS code so enabling/disabling >> it adds/removes the code rather than the events being fired anyway and then >> ignored >> 5. its generic so we can add new things to audit without creating new events >> >> 6. The code in the source tree was actually sample/example code on how to do >> auditing using events, and not designed for production use (though it was >> capable of being used that way). We stated this when it was put in place in >> 3.0, but I'm sure by now everyone's forgotten about that :-) >> >> >> -Scott >> On Tue, Apr 22, 2008 at 4:18 PM, Adam Rybicki <[EMAIL PROTECTED]> <[EMAIL >> PROTECTED]> wrote: >> Scott, >> >> Was there anything wrong with EventHandler or TicketEvent? I ask because I >> have used them, and now upgrading to 3.2.1 will be more difficult. :-( >> >> >> Adam >> >> Scott Battaglia wrote: >> Cyrille, >> >> Since CAS is now using the Inspektr package (detailed here: >> http://code.google.com/p/inspektr/) that's our preferred way of doing >> things. You'll merely need to write an AuditTrailManager that does the JMS >> call. >> >> >> -Scott >> On Tue, Apr 22, 2008 at 6:14 AM, Cyrille Le Clerc <[EMAIL PROTECTED]> >> <[EMAIL PROTECTED]> wrote: >> Hello, >> >> I would like to capture login and logout events in CAS Server to >> broadcast these events to a JMS Topic (backend data preloading, etc). >> >> >> The package org.jasig.cas.event (AuthenticationEvent, TicketEvent and >> EventHandler interface) has been removed in CAS 3.2, the SVN comment says >> "started move to Google Code Inspektr library". >> >> What is the preferred way to integrate a login/logout/ticket event >> listener in CAS ? >> >> >> Thanks in advance, >> >> Cyrille >> >> >> >> _______________________________________________ >> Yale CAS mailing list >> [email protected] >> http://tp.its.yale.edu/mailman/listinfo/cas >> >> > > > -- > -Scott Battaglia > PGP Public Key Id: 0x383733AA > LinkedIn: http://www.linkedin.com/in/scottbattaglia > > ------------------------------ > > _______________________________________________ > Yale CAS mailing [EMAIL PROTECTED]://tp.its.yale.edu/mailman/listinfo/cas > > > _______________________________________________ > Yale CAS mailing list > [email protected] > http://tp.its.yale.edu/mailman/listinfo/cas > > -- -Scott Battaglia PGP Public Key Id: 0x383733AA LinkedIn: http://www.linkedin.com/in/scottbattaglia
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
