<div dir="ltr"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> I'd rather not alter the flow itself, but it seems that by the time it gets to the template, requestParameters is lost and all<br>
> that's available is the conversation state.<br>
<br>
Yes, but that's because this feature just isn't supported. We will never use them ourselves, but I'm willing to code in a default capture of any parameters into that specific flow/URL into the scratch context if somebody files a request for it.<br></blockquote><div><br></div><div>Done.   I'd really like to find the least awful / offensive way to implement this.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Proprietary locations that aren't in metadata should never be shared with anybody and should go through redirection of some kind to separate the published location from the mechanics of the software. Mine is at /cgi-bin/logout.cgi</blockquote><div><br></div><div>Our legacy logout CGI on the our IDPs tries to kill some IDP related cookies before sending the user on to the legacy SLO.</div><div>Would it be possible to get at the IDP session externally (from a CGI) and destroy it?  It seemed like the surest way to do that was to go through the IDP itself.</div><div><br></div><div>I assume that if we using client storage, we could just kill the shib_idp_session_ss cookie / storage key w/o having to tie into an IDP functionality.</div><div><br></div><div>Liam</div></div></div></div>