Adam,
In the /WEB-INF/cas-servlet.xml, it defines the two Spring Web Mapping Handlers used by CAS; handlerMappingB and handlerMappingC. As you can see with handlerMappingC, you can define interceptors (http://static.springframework.org/spring/docs/2.5.x/api/org/springframe work/web/servlet/HandlerInterceptor.html) to be called in conjunction with the mappings they are applied to. http://static.springframework.org/spring/docs/2.5.x/reference/mvc.html http://static.springframework.org/spring/docs/2.5.x/api/org/springframew ork/web/servlet/handler/SimpleUrlHandlerMapping.html http://static.springframework.org/spring/docs/2.5.x/api/org/springframew ork/web/servlet/HandlerInterceptor.html HTH, Andrew R Feller, Analyst University Information Systems 200 Fred Frey Building Louisiana State University <http://www.lsu.edu/> Baton Rouge, LA, 70803 (225) 578-3737 (Office) (225) 578-6400 (Fax) ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Rybicki Sent: Friday, May 16, 2008 12:23 PM To: Yale CAS mailing list Subject: Re: How to integrate a login & logout event listener in CAS Server ? 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] 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] 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]> <mailto:[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]> <mailto:[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 list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
