davidjb
commented
8 years ago Thanks for the error report. The shibauthorizer looks to be behaving correctly as authorisation failures aren't considered errors by Shibboleth's SP and are returned as 403s. See the comment from Scott Cantor. If you're looking to show the user a custom 403 page, then Nginx's error_page will be what you're looking for.
If you do want to test/see the results of redirectErrors, try a request to something like /Shibboleth.sso/non-existent -- that redirects correctly for me with Shibboleth SP 2.5.5 and Nginx 1.8.0.
As for the latter issue about Gzipped content missing the Content-Encoding header (or being incorrect gzipped in the first place), I've reproduced this. This seems to also affect error_page output too -- eg error_page 403 =302 http://foobar.com is missing the Location header and calls to add_header aren't reflected in the response. The sub-request's headers are being returned to the client which is likely messing with Nginx's ability to change headers (Gzip, etc) just before they're returned.
I'll give this some more thought and see what I can come up with.
We have stumbled on two issues using shibboleth sp 2.5.3 with fastcgi and nginx 1.8.0. The first issue is that the shibauthoriser does not use redirectErrors from shibboleth2.xml and the second is that the response from shibauthorizer contains content type (type/html) but the gzip filter is applied anyway.
Our setup shibboleth2.xml
For the record, "standard" nginx sites-enabled:
Standard nginx.conf gzip
Nginx error log
Browser got these http response headers
and the actual response content is some garbage (gzipped stuff).
Setting
gzip_min_length 1000;solves the second issue and returnsHowever, the expected output would be a redirect to the url specified in shibboleth2.xml.