Jonathan, The code that Adam is referring is and always has been considered example code (I'm pretty sure its been mentioned that way multiple times on the mailing lists since the 3.x release). While the code worked for its intended purpose, it had many short-comings including not capturing the entire request. Despite that, people have been using it (I may even be guilty of letting people know of its existence and helping people use it, which may have given a false impression). But again, the code has been unsupported and considered example code that through legacy transfer has always ended up in the core despite that fact that it wasn't.
Since the 3.2 release, we've introduced a supported, end-to-end request auditing library. Because we now have a supported, production ready method, we have removed the example/unsupported code. As usual, with any release, we do not remove or change any major supported APIs. Unsupported/example code does not fall under that rule. This has also applied to the only other example/unsupported code which was the old Services Restriction code which has been replaced with the Services Management tool. We were careful such that these changes only occurred under major releases (3.1 for Services Management and 3.2 for the new library) even though they were unsupported/example code. The library we are also now using can be embedded in other applications, allowing for knowledge transfer to other projects (similar to how anyone who learns Spring has a better understanding of projects that use Spring). We've documented the library as best as possible due to time constraints on the Inspektr web site. Unfortunately, we haven't had time to do extensive documentation on the CAS web site or mailing list other than refer people to the library web site and our example configuration file and answer questions as they pop up. If you are aware of people who can help out with documentation, please let me know. Thanks -Scott On Fri, May 16, 2008 at 4:20 PM, Jonathan Markow <[EMAIL PROTECTED]> wrote: > I would like to interject a few questions into this thread in hope of being > helpful. Apologies in advance for my technical naivete on these matters. > I'd simply like to see if we can a) arrive at a solution to the current > problem that satisfies everyone, and b) avoid any future misunderstandings. > > It sounds like Adam was surprised to find that some API's he was counting > on had disappeared in 3.2. I know that API's sometimes go away, but was > this, in fact, a surprise, or had there been warning that this would happen? > > I know it's often a practice to deprecate stuff in a previous release. Had > that happened in this case, or was there any other documentation that would > have signaled the change? > > In any case, surprise or not, since Adam seems to have production code that > has stopped working, does it make sense to restore the missing API's for > now, with the understanding that it will be temporary, as the intent is to > replace them with Inspektr, which offers many other advantages? > > Finally, can anyone suggest a practice that would help avoid similar > misunderstandings in the future? > > Thanks, > Jonathan > > > On Fri, May 16, 2008 at 2:11 PM, Andrew R Feller <[EMAIL PROTECTED]> wrote: > >> 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/springframework/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/springframework/web/servlet/handler/SimpleUrlHandlerMapping.html >> >> >> http://static.springframework.org/spring/docs/2.5.x/api/org/springframework/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] <[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 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 >> >> > > _______________________________________________ > 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
