<div dir="ltr"><div>Hi all - <br></div><div><br></div><div>I hope that I'm messaging the correct list. Apologies if I'm not in the right place.</div><div><br></div><div>We're working with a vendor to deep link into their product and pass the target (ie: redirect) parameter correctly through the authentication sequence. The target URL is a bit tricky as it itself contains not only parameters but also URL encoded parameters: </div>
<div><br></div><div>/path/to/servlet?param1=abc&param2=123&param3={URLencoded_URL}</div><div><br></div><div>From what we can tell, the target parameter is being encoded and passed along - but we just don't know enough to determine if it is entirely correct. The vendor replies:</div>
<div><br></div><div><div>"Once authentication against the IDP is complete, you're brought back to the site and redirected to a URL which contains the decoded form of the target querystring parameter. We have tested this process against an internal IDP to confirm what the status of the Target parameter should be, and internally it is not decoded when it gets to request 14. This suggests that your IDP is decoding the URL, which would be the root cause of this issue. If the decoding of the Target parameter at your IDP can be avoided, that should allow this whole process to work correctly."</div>
</div><div><br></div><div>Historically, other systems we've linked to in this manner have seemed to work just fine with our configuration as-is, and we're unsure where to look next. Has anyone maybe run across this scenario before? Or could anyone please offer a hint of what we should look for in the documentation to dive deeper into this issue? We're very grateful for any direction.</div>
<div><br></div><div>Thank you,</div><div>-George</div><div><br></div></div>