EDS fatal error "No URL return parameter provided"

[Peter Schober]

* Cantor, Scott <cantor.2 at osu.edu> [2020-12-07 17:40]:
> I think you probably have something in the web server
> interfering. The EDS on shibboleth.net works fine (defaultReturn is
> null), and given that it was using the defaultReturn value when
> something else was supplied, it's clearly not seeing the actual
> parameter.

Ha! I couldn't explain how I could have managed to prevent the EDS
from seeing the parameter. But Rod could. Turns out I also had
set this in both (see below) of my EDS configs on that machine by
mistake:

  // Cf. EDS-51, avoids error about missing params when accessed outside of SAMLDS requests
  this.ignoreURLParams = true;     

So the EDS didn't see its own parameters because I told it to
"ignoreURLParams"!
That couldn't be more clear -- though of course I only needed that
setting to have the EDS ignore *other*, i.e., non-SAMLDS-protocol, URL
parameters, not also its own.

Thanks a lot to Rod for finding this when it was right in front of me!

If you're wondering why I needed ignoreURLParams set or 2 EDS config
files:
The application in question doesn't allow you to do anything unless
you're logged in (in general) so I opted to put the EDS right there on
the front page of the website. There it is not ever approached using
SAMLDS protocol messages (i.e., it's not a SAMLDS, as Rod would put
it) and so it needs to ignore (other) URL parameters in order to allow
subjects to change the language of the front page via URL parameters,
for example, without the EDS complaining about extra/unknown parameters.

(In that context hard-coding this.defaultReturn also causes no issues
since entering the app from the front page doesn't create relay state,
i.e., ending up at the front page after returning from the IDP is fine.)

Now, the application also sends out email containing self-referencing
URLs that do have relay state (so to speak, they'd either point to the
SP's session initiator with the target= parameter or to actively
proteced content) and those requests can now either:
* have their relay state lost (my current issie, by hard-coding
  defaultReturn), or
* will cause the EDS to complain once someone switches language on the
  page the EDS is rendered on (by not setting ignoreURLParams=true).

So I had added an another request URI pointing to that same instance
of the EDS but loaded with a different idpselect_config.js file --
where that second "copy" of the EDS is *only* used for real SAMLDS
requests (e.g. this one is set as the Shib SP's SSO/@discoveryURL).

In that idpselect_config.js copy I had unset the hard-coded
this.defaultReturn (setting it to null) *BUT* had forgotten to disable
the ignoreURLParams=true, since that's not needed in that copy (no
other parameters are possible on that second instance).

So my use-case now works, even if I now have to load the EDS in 2
different places using 2 differing config files.
I'll file an RFI about this to make avoid having to load 2 config
files.

Thanks again,
-peter