> we made the decision to encapsulate all of > the logic for validating a ticket behind the interface this way applications > the depend on the client (i.e. Spring Security, etc.) merely need to > configure the TicketValidator and everything is handled for them.
I appreciate that background, Scott. The Spring Security integration sounds like a strong justification for the Java client design. > This works well for future protocols where the validation of the ticket > might not be parsing a URL endpoint but confirming a digitital signature. I believe the design I recommended could accommodate the case of digital signatures and other strategies that are not based on HTTP request/response. A component separate from the validator would be responsible for obtaining the artifact to validate, and would pass that artifact to the validator. A TextReader is generic enough to accommodate both strings and streams. You'd need another component like the HttpModule (ServletFilter in Java) to wire together the fetching component and the validator. We clearly have such a component, though, since each protocol requires its own HttpModule. M -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
