-
-
Notifications
You must be signed in to change notification settings - Fork 309
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
Documentation for request_data? #273
Comments
The request_data is not officially documented. Each demo defines how request_data should look like: Ex. Django Feel free to contribute with such documentation |
Right – the Django example, for one, is hopelessly incorrect in the common case where you have an application server running on e.g. port 8000, and reverse proxied & TLS terminated by e.g. Nginx at port 443 (let's say the user visits In that case In cases where the app is accessed on a non-standard port (not 80 for HTTP or 443 for HTTPS), I think EDIT: On the topic of ports, by the way, the port-splitting-and-checking-and-reinstating logic in |
`server_port` is unnecessary, since the HTTP Host header sent by the client already includes any non-standard port. In addition, when the Python application server is sitting behind a reverse proxy/TLS terminator, SERVER_PORT is likely to be wrong anyway (since it would be the server port of the non-reverse-proxied server). See SAML-Toolkits#273 (comment)
`server_port` is unnecessary, since the HTTP Host header sent by the client already includes any non-standard port. In addition, when the Python application server is sitting behind a reverse proxy/TLS terminator, SERVER_PORT is likely to be wrong anyway (since it would be the server port of the non-reverse-proxied server). See SAML-Toolkits#273 (comment)
`server_port` is unnecessary, since the HTTP Host header sent by the client already includes any non-standard port. In addition, when the Python application server is sitting behind a reverse proxy/TLS terminator, SERVER_PORT is likely to be wrong anyway (since it would be the server port of the non-reverse-proxied server). See SAML-Toolkits#273 (comment)
Are the fields for the
request_data
dictionary documented anywhere? I was just bit by the fact that there's apparently an'https'
field you need to set to the string'on'
so using HTTPS works at all when aDestination
is set in a SAML response document from an IdP.This was "fixed for demos" in 15a331e but doesn't seem otherwise documented.
The validation chain for Destinations is:
current_url
is https://github.com/onelogin/python3-saml/blob/174ecfaf6f69c0ac13087b8233c293072b271742/src/onelogin/saml2/response.py#L122https
key, or alternatively whether the port is 443.The text was updated successfully, but these errors were encountered: