<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Mar 14, 2016 at 5:01 PM Lucia Siochi <<a href="mailto:Lucia.Siochi@cpcc.edu">Lucia.Siochi@cpcc.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-US" link="#0563C1" vlink="#954F72">
<div>
<p class="MsoNormal">I am setting up the built-in CAS service in IdPv3 and need to see what the CAS response is that’s being sent back to the CAS client.
<u></u><u></u></p>
<p class="MsoNormal">I tried setting idp.loglevel.messages  to DEBUG in conf/logback.xml:</p>
<p class="MsoNormal">    <variable name="idp.loglevel.messages" value="DEBUG" /></p><p class="MsoNormal"><u></u></p>
<p class="MsoNormal">but I didn’t notice any difference in the output.</p></div></div></blockquote><div>Sorry, that won't work for CAS protocol messages since they're not handled by the SAML machinery but instead by Velocity. I've needed to do this myself on a few occasions, but worked around it by turning up logging on the client. If that's not an option, I have a couple suggestions:</div><div><br></div><div>1. Servlet filter to log HTTP response, e.g. <a href="http://logback.qos.ch/recipes/captureHttp.html">http://logback.qos.ch/recipes/captureHttp.html</a></div><div>2. Log output of velocity template<br></div><div><br></div><div>I've used both approaches in other projects quite successfully. 1 is probably easier to configure, but broader in scope (which may or may not be preferable). Here's a gist for approach #2:</div><div><br></div><div><a href="https://gist.github.com/serac/211c65de13eec4914cf0">https://gist.github.com/serac/211c65de13eec4914cf0</a><br></div><div><br></div><div>Feel free to file a RFE issue for this if you'd like. I think I could work in approach #2 to apply just to CAS protocol views now that I think about it. Ideally the same logger that dumps SAML protocol messages would include CAS protocol messages as well.</div><div><br></div><div>M</div><div><br></div></div></div>