url modified by IdP redirect

[Peter Schober]

* Dr. Marco Lechner <mlechner at bfs.de> [2017-05-17 16:42]:
> But if the Location is configured requiring a shibboleth session:
>   AuthType shibboleth
>   ShibRequestSetting requireSession 1
>   require valid-user
> then the URL does not work if authenticating at the IdP.

What exactly means "the URL does not work"?

> It seems that the IdP redirect does some strange things (URL en- or
> decoding).
[...]
> 1. no session required or already existing
>     - https://foo.example.com/bar/#map/12345/67890 -> good
>     - https://foo.example.com/bar/%23map/12345/67890 -> fail

Whatever goes wrong here must be an application issue, as no redirect
happens and Shib does not change the URLs at all. (And I also wouldn't
expect this to work, as an urlencoded fragment identifier[1] probably
is not seen/understood as one, by the HTTP user agent.)

> 2. session required and no session yet available (go through IdP)
>     - https://foo.example.com/bar/#map/12345/67890 -> fail
>     - https://foo.example.com/bar/%23map/12345/67890 -> good

Encoding the fragment identifier probably prevents it from being one
and it's likely that is what preserves it across redirects (i.e., it's
sent to the HTTP server as part of the request, and so also causes it
to be "seen" by the server, which it normally isn't: A fragment
identifier is never sent from the HTTP user agent to the HTTP server
and therefore cannot be preserved across redirects by server-side
software. This has nothing to do with Shibboleth per se.)

If the encoded fragement identifier in the roundtrip-to-IDP-happens
case "works" for your deployment then I guess something (I can't think
of anything other than the web browser) must be decoding the encoded
fragment identifier before accessing the resource?

-peter

[1] https://en.wikipedia.org/wiki/Fragment_identifier