In an attempt to do test-driven development from the start, I've run
into a problem. The real meat of ITicketValidator is in the
parseResponseFromServer method, which is protected. That makes
testing the method much more difficult than needed.
Thinking about CAS as a multiprotocol system, ticket validation is
much more about interpreting the various responses the server sends.
The process of fetching a response, on the other hand, is pretty much
constant -- an HTTP get to a URL. That suggests ITicketValidator look
like the following:
public interface ITicketValidator
{
IAssertion validate(TextReader reader);
}
Where the reader is a StreamReader built from the HTTP response stream
obtained from the CAS server. Each validator would use another common
component (e.g. CasTicketResponseRetriever) to build the validation
URL, send the HTTP request, and pass the response to the validator.
We can then focus on the real meat of validation semantics in our unit
tests by just passing in StringReader objects with various
success/fail payloads.
This design assumes ticket validation is always a single
request/response process, but that would suit CAS 1/2 protocols and
SAML 1.1. Would that work for OpenID as well?
Thoughts?
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
