26 aug. 2019 kl. 19:50 skrev Martin van Es <martin
at surfnet.nl>:
Hi Leif,
On Monday, August 26, 2019 6:58:45 PM CEST Leif Johansson wrote:
2.
Without PYFF_UPDATE_FREQUENCY one needs to call POST
PYFF_PUBLIC_URL/api/ call/update oneself, which results in a "404 Not
found". THIS IS A RED HERRING, the update succeeded anyway (my oh my).
Documentation is admittedly a bit behind... but you should get a 404
there if your pipeline is setup to have an 'update' entrypoint. What
does your pipeline look like?
It's the example pipeline from documentation, with the edugain md url replaced
by a local filesystem folder:
- when update:
- load:
- /opt/pyff.old/metadata
- when request:
- select:
- pipe:
- when accept application/xml:
- first
- finalize:
cacheDuration: PT12H
validUntil: P10D
- sign:
key: certs/signing.key
cert: certs/signing.crt
- emit application/xml
- break
- when accept application/json:
- discojson
- emit application/json
- break
Logging is a bit of a dark art in wsgi (at least
to me) but if you set
PYFF_LOGGING to point to examples/debug.ini you'll see a lot more and
also hopefully understand what logging looks like.
Scott's logging.ini helped a lot, I'm having loads of debug info now.
Which brings me to my next question: thiss.io
There are roughly three github repositories: thiss-js, thiss-ds-js and thiss-
jquery-plugin. It is my understanding thiss-ds-js is used when building one's
own DS. I'm simply looking for a
replacement of the old pyff built-in DS
service. thiss-js seems to supply an - index.html and /ds endpoint that look
promising, but when fed to a simplified nginx conf based on the one found in
the docker recipe I'm greeted with something that remotely looks like a broken
DS, with missing pictures and failing requests to URL's like
https://urlproxy.sunet.se/canit/urlproxy.php?_q=aHR0cHM6Ly9tZHE%3D&_s=b…
What am I missing here?
Also, I'm curious what mdq and ds endpoints I
should configure in satosa to
make this work again once I get a decent DS interface up and running?