-
Notifications
You must be signed in to change notification settings - Fork 132
BASE must not include a path in mod_wsgi-hosted deployments #179
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Cf. my posts to the satosa-users mailing list: https://lists.sunet.se/pipermail/satosa-users/2018-February/000029.html |
Is there any update to this issue? I imagine, that the same limitations apply to running e.g. the docker container with a reverse proxy web server in front of it, since you'd have to set BASE in proxy_conf.yaml to the real path anyways. Has anyone gotten the SAML plugins to work with SATOSA deployed on a BASE path other than root? |
I assume this is still an open issue? I have a hard time getting SATOSA up in any case but I certainly need it to run behind a URL path. |
Hello, this is still an issue. I will try to boost development and move forward with this. |
declare only relative URLs in configuration, so as to fix registration when base URL contains a path (issue IdentityPython#179), and expose those endpoints to outer world by appending base URL when needed. This is much simpler than parsing absolute URLs, and more consistent with OIDC frontends behaviour.
declare only relative URLs in configuration, so as to fix registration when base URL contains a path (issue IdentityPython#179), and expose those endpoints to outer world by appending base URL when needed. This is much simpler than parsing absolute URLs, and more consistent with OIDC frontends behaviour.
declare only relative URLs in configuration, so as to fix registration when base URL contains a path (issue IdentityPython#179), and expose those endpoints to outer world by appending base URL when needed. This is much simpler than parsing absolute URLs, and more consistent with OIDC frontends behaviour.
Uh oh!
There was an error while loading. Please reload this page.
Code Version
master (v3.4.8)
Expected Behavior
I should be able to host SATOSA at any valid URL path, e.g., setting BASE to
https://federation.example.com/satosa
.Likewise, the following values of BASE should be treated the same:
https://federation.example.com/
andhttps://federation.example.com
. However, only the latter value of BASE results in a working configuration.Current Behavior
If one hosts the SATOSA WSGI application at a path other than
/
, and if one sets BASE in the SATOSA proxy configuration file to something other than<scheme>://<host>
, then the SAML back end registers invalid endpoint mappings, e.g. with BASE set tohttps://federation.example.com/satosa
, it sets up these mappings (url_map):This results in the following error:
Whereas with BASE set to
https://federation.example.com
, it sets up these mappingsDue to differences in how the SAML front end configures endpoint mappings, it works as expected for both values of BASE.
Possible Solution
This might be related to issue #148.
As a workaround for situations where one might wish to co-locate SATOSA and other web applications or content on the same virtual host, use the
WSGIScriptAliasMatch
directive with a negative lookahead; for example:Steps to Reproduce
WSGIScriptAlias /satosa ...
instead ofWSGIScriptAlias / ...
.<scheme>://<host>/satosa
.The text was updated successfully, but these errors were encountered: