On Tuesday, August 27, 2019 9:39:31 AM CEST Leif Johansson wrote:
Ok I now
understand what went wrong. I was mislead by the "Read the
documentation" link that points to the documentation on
https://thiss-ds.readthedocs.io/ which is a work-in-progress. Therefor I
missed the /docs directory and am now catching up on everything npm!
you mean thiss-js.readthedocs.io right?
No, there is a typo on the thiss-js github README.md that points to an empty
readthedocs page, hence my confusion.
I'm trying to get satosa to interact with the new pyFF, but pyFF now complains
on the /entities request satosa fires:
2019-08-27 07:48:23,560 ERROR [pyff.api:31][MainThread] "application/
samlmetadata+xml" is not a valid mime type
So either we need to fix satosa or have pyFF accept satosa's "weird" Accept
header?
2019-08-27 07:48:02,760 DEBUG [pyff.api:31][MainThread] GET /entities/
%7Bsha1%7D9cf868c63facb578874f88ec55eb097ee2bbb2bb HTTP/1.0
Accept: application/samlmetadata+xml
Accept-Encoding: gzip, deflate
Connection: close
Host: 127.0.0.1:8083
User-Agent: python-requests/2.20.1
I changed the pipeline to have a "when accept application/samlmetadata+xml"
line, but that doesn't seem to do the trick?
2019-08-27 07:48:23,560 DEBUG [pyff.api:31][MainThread] Traceback (most recent
call last):
File "/opt/pyFF/lib/python3.7/site-packages/pyff/api.py", line 152, in
process_handler
accepter = MediaAccept(accept)
File "/opt/pyFF/lib/python3.7/site-packages/pyff/api.py", line 54, in
__init__
self._type = AcceptableType(accept)
File "/opt/pyFF/lib/python3.7/site-packages/accept_types/accept_types.py",
line 20, in __init__
raise ValueError('"%s" is not a valid mime type' % mime_type)
ValueError: "application/samlmetadata+xml" is not a valid mime type
M.