6:56 p.m.
Hi,
I've been experimenting with thiss.io combined with pyff as mdq and tried to
use the pyff "select as" construct to narrow down the list of available
IdP's
in the DS. It doesn't work? Pyff correctly reports a request on the ds, for
alias test, but thiss.io returns a 404?
pyffd[1318]: 2019-09-24 15:48:21,415 DEBUG [pyff.api:31][MainThread] handling
entry=request, alias=test, path=ds
I suspect this is caused by the (example) nginx conf, as the /test alias can
not be served by thiss.io it is directly forwarded to pyff, bypassing the DS?
server {
include "mime.types";
listen 0.0.0.0:8081 default_server;
location / {
root /opt/thiss-js/dist;
try_files $uri $uri/index.html $uri.html @mdq;
}
location @mdq {
proxy_pass http://127.0.0.1:8083;
}
}
But then, even if we could solve the nginx conf, thiss.io should be "alias"
aware and fire the correct query on pyff. Will it?
Best regards,
Martin
9:57 p.m.
On 2019-09-24 17:56, Martin van Es wrote:
Hi,
I've been experimenting with thiss.io combined with pyff as mdq and tried to
use the pyff "select as" construct to narrow down the list of available
IdP's
in the DS. It doesn't work? Pyff correctly reports a request on the ds, for
alias test, but thiss.io returns a 404?
pyffd[1318]: 2019-09-24 15:48:21,415 DEBUG [pyff.api:31][MainThread] handling
entry=request, alias=test, path=ds
I suspect this is caused by the (example) nginx conf, as the /test alias can
not be served by thiss.io it is directly forwarded to pyff, bypassing the DS?
yeah that sounds reasonable
you can easily craft a different nginx config right?
server {
include "mime.types";
listen 0.0.0.0:8081 default_server;
location / {
root /opt/thiss-js/dist;
try_files $uri $uri/index.html $uri.html @mdq;
}
location @mdq {
proxy_pass http://127.0.0.1:8083
}
}
But then, even if we could solve the nginx conf, thiss.io should be "alias"
aware and fire the correct query on pyff. Will it?
Best regards,
Martin
_______________________________________________
Idpy-discuss mailing list
Idpy-discuss at lists.sunet.se
https://lists.sunet.se/listinfo/idpy-discuss
____________
Idpy-discuss mailing list
Idpy-discuss at lists.sunet.se
https://lists.sunet.se/listinfo/idpy-discuss
11:48 p.m.
On Tuesday, September 24, 2019 8:57:41 PM CEST Leif Johansson wrote:
I might, but the challenge is to match on (.*)/$uri, and then thiss.io's
SEARCH_URL should be augmented with the match from (.*) if I wanted to keep
things flexible on pyff's side?
Hence my second question:
I suspect this
is caused by the (example) nginx conf, as the /test alias
can not be served by thiss.io it is directly forwarded to pyff, bypassing
the DS?
yeah that sounds reasonable
you can easily craft a different nginx config right? > But then, even if we could solve the nginx conf,
thiss.io should be
> "alias"
> aware and fire the correct query on pyff. Will it?
So, has thiss.io been developed and/or used with pyff's select as alias in
mind and, will pyff allow the alias on the /api/search endpoint? Maybe Scott
made it work as he needs select as in some of his deployments?
Martin
midnight
So, has thiss.io been developed and/or used with
pyff's select as alias in
mind and, will pyff allow the alias on the /api/search endpoint? Maybe Scott
made it work as he needs select as in some of his deployments?
Still working on it...
What I can tell you is that if my pipeline has this
- select as ligo_approved:
- "https://login.ligo.org/idp/shibboleth"
- "https://shibbi.pki.itc.u-tokyo.ac.jp/idp/shibboleth"
- "https://orcid-saml-gateway.gw-astronomy.org/idp"
Then I can do a query like this:
curl -H 'Accept: application/json'
http://127.0.0.1:8080/entities/ligo_approved?query=kagra | python -m json.tool
and "find" the KAGRA IdP (second in the list above).
So my hope is that I can create from a thiss-js repository clone a second
discovery service that has/uses a SEARCH_URL that points to
http://127.0.0.1:8080/entities/ligo_approved
and thereby deliver a second discovery service with the limited set of IdPs.
Note that the URL
http://127.0.0.1:8080/entities/ligo_approved?query=kagra
is NOT using the search API calls. It is processed using the full pipeline
mechanism. So it is slightly slower, but that is not a problem for my use
case.
I don't know if Leif will extend pyFF so that the search API calls will
respect the alias.
HTH,
Scott K
12:24 a.m.
So, has
thiss.io been developed and/or used with pyff's select as alias in
mind and, will pyff allow the alias on the /api/search endpoint? Maybe Scott
made it work as he needs select as in some of his deployments?
Still working on it...
What I can tell you is that if my pipeline has this
- select as ligo_approved:
- "https://login.ligo.org/idp/shibboleth"
- "https://shibbi.pki.itc.u-tokyo.ac.jp/idp/shibboleth"
- "https://orcid-saml-gateway.gw-astronomy.org/idp"
Then I can do a query like this:
curl -H 'Accept: application/json'
http://127.0.0.1:8080/entities/ligo_approved?query=kagra | python -m json.tool
and "find" the KAGRA IdP (second in the list above).
So my hope is that I can create from a thiss-js repository clone a second
discovery service that has/uses a SEARCH_URL that points to
http://127.0.0.1:8080/entities/ligo_approved
and thereby deliver a second discovery service with the limited set of IdPs.
Note that the URL
http://127.0.0.1:8080/entities/ligo_approved?query=kagra
is NOT using the search API calls. It is processed using the full pipeline
mechanism. So it is slightly slower, but that is not a problem for my use
case.
I don't know if Leif will extend pyFF so that the search API calls will
respect the alias.
9:09 a.m.
Skickat från min iPhone
24 sep. 2019 kl. 23:24 skrev Scott Koranda <skoranda at gmail.com>:
So using the alias almost works...
The problem is that the JSON payloads returned from the API call and the
JSON returned from the alias/pipeline call are different.
The API call returns
[
{
"title":"KAGRA",
"descr":"KAGRA Large-scale Cryogenic Gravitational Wave Telescope
Project",
"entity_id":"https://shibbi.pki.itc.u-tokyo.ac.jp/idp/shibboleth",
"entityID":"https://shibbi.pki.itc.u-tokyo.ac.jp/idp/shibboleth",
"domains":"pki.itc.u-tokyo.ac.jp;itc.u-tokyo.ac.jp;u-tokyo.ac.jp;ac.jp",
"id":"{sha1}c24878218fd7873becb1ef44c68b513c69d168e5",
"scopes":"shibbi.pki.itc.u-tokyo.ac.jp",
"matched":"KAGRA",
"ddist":0
}
]
The alias/pipeline call returns
[
{
"title":"KAGRA",
"descr":"KAGRA Large-scale Cryogenic Gravitational Wave Telescope
Project",
"auth":"saml",
"entityID":"https://shibbi.pki.itc.u-tokyo.ac.jp/idp/shibboleth",
"type":"idp",
"hidden":"false",
"scope":"shibbi.pki.itc.u-tokyo.ac.jp",
"domain":"shibbi.pki.itc.u-tokyo.ac.jp",
"name_tag":"SHIBBI",
"entity_icon_url":{
"url":"https://shibbi.pki.itc.u-tokyo.ac.jp/SAML2/metadata/ui/KAGRA-logo-60x80.png",
"width":"80",
"height":"60"
}
}
]
The thiss-js code is looking in the payload for key 'entity_id', not
'entityID'.
Leif is this a limitation of thiss-js, or a bug in pyFF, or ?
Bug!
So, has thiss.io been developed and/or used with
pyff's select as alias in
mind and, will pyff allow the alias on the /api/search endpoint? Maybe Scott
made it work as he needs select as in some of his deployments?
Still working on it...
What I can tell you is that if my pipeline has this
- select as ligo_approved:
- "https://login.ligo.org/idp/shibboleth"
- "https://shibbi.pki.itc.u-tokyo.ac.jp/idp/shibboleth"
- "https://orcid-saml-gateway.gw-astronomy.org/idp"
Then I can do a query like this:
curl -H 'Accept: application/json'
http://127.0.0.1:8080/entities/ligo_approved?query=kagra | python -m json.tool
and "find" the KAGRA IdP (second in the list above).
So my hope is that I can create from a thiss-js repository clone a second
discovery service that has/uses a SEARCH_URL that points to
http://127.0.0.1:8080/entities/ligo_approved
and thereby deliver a second discovery service with the limited set of IdPs.
Note that the URL
http://127.0.0.1:8080/entities/ligo_approved?query=kagra
is NOT using the search API calls. It is processed using the full pipeline
mechanism. So it is slightly slower, but that is not a problem for my use
case.
I don't know if Leif will extend pyFF so that the search API calls will
respect the alias.
Thanks,
Scott K
_______________________________________________
Idpy-discuss mailing list
Idpy-discuss at lists.sunet.se
https://lists.sunet.se/listinfo/idpy-discuss
.png",
"width":"80",
"height":"60"
}
}
]
The thiss-js code is looking in the payload for key 'entity_id', not
'entityID'.
Leif is this a limitation of thiss-js, or a bug in pyFF, or ?
Thanks,
Scott K
_______________________________________________
Idpy-discuss mailing list
Idpy-discuss at lists.sunet.se
https://lists.sunet.se/listinfo/idpy-discuss
10:10 a.m.
Skickat från min iPhone
25 sep. 2019 kl. 08:09 skrev Leif Johansson <leifj
at sunet.se>:
Skickat från min iPhone
24 sep. 2019 kl. 23:24 skrev Scott Koranda <skoranda at gmail.com>:
So using the alias almost works...
The problem is that the JSON payloads returned from the API call and the
JSON returned from the alias/pipeline call are different.
The API call returns
[
{
"title":"KAGRA",
"descr":"KAGRA Large-scale Cryogenic Gravitational Wave Telescope
Project",
"entity_id":"https://shibbi.pki.itc.u-tokyo.ac.jp/idp/shibboleth",
"entityID":"https://shibbi.pki.itc.u-tokyo.ac.jp/idp/shibboleth",
"domains":"pki.itc.u-tokyo.ac.jp;itc.u-tokyo.ac.jp;u-tokyo.ac.jp;ac.jp",
"id":"{sha1}c24878218fd7873becb1ef44c68b513c69d168e5",
"scopes":"shibbi.pki.itc.u-tokyo.ac.jp",
"matched":"KAGRA",
"ddist":0
}
]
The alias/pipeline call returns
[
{
"title":"KAGRA",
"descr":"KAGRA Large-scale Cryogenic Gravitational Wave Telescope
Project",
"auth":"saml",
"entityID":"https://shibbi.pki.itc.u-tokyo.ac.jp/idp/shibboleth",
"type":"idp",
"hidden":"false",
"scope":"shibbi.pki.itc.u-tokyo.ac.jp",
"domain":"shibbi.pki.itc.u-tokyo.ac.jp",
"name_tag":"SHIBBI",
"entity_icon_url":{
"url":"https://shibbi.pki.itc.u-tokyo.ac.jp/SAML2/metadata/ui/KAGRA-logo-60x80.png",
"width":"80",
"height":"60"
}
}
]
The thiss-js code is looking in the payload for key 'entity_id', not
'entityID'.
Leif is this a limitation of thiss-js, or a bug in pyFF, or ?
Bug!
To be clear: the bug is that entity_id isn’t present in both cases.
So, has thiss.io been developed and/or used with
pyff's select as alias in
mind and, will pyff allow the alias on the /api/search endpoint? Maybe Scott
made it work as he needs select as in some of his deployments?
Still working on it...
What I can tell you is that if my pipeline has this
- select as ligo_approved:
- "https://login.ligo.org/idp/shibboleth"
- "https://shibbi.pki.itc.u-tokyo.ac.jp/idp/shibboleth"
- "https://orcid-saml-gateway.gw-astronomy.org/idp"
Then I can do a query like this:
curl -H 'Accept: application/json'
http://127.0.0.1:8080/entities/ligo_approved?query=kagra | python -m json.tool
and "find" the KAGRA IdP (second in the list above).
So my hope is that I can create from a thiss-js repository clone a second
discovery service that has/uses a SEARCH_URL that points to
http://127.0.0.1:8080/entities/ligo_approved
and thereby deliver a second discovery service with the limited set of IdPs.
Note that the URL
http://127.0.0.1:8080/entities/ligo_approved?query=kagra
is NOT using the search API calls. It is processed using the full pipeline
mechanism. So it is slightly slower, but that is not a problem for my use
case.
I don't know if Leif will extend pyFF so that the search API calls will
respect the alias.
>
> Thanks,
>
> Scott K
> _______________________________________________
> Idpy-discuss mailing list
> Idpy-discuss at lists.sunet.se
> https://lists.sunet.se/listinfo/idpy-discuss
> .png",
> "width":"80",
> "height":"60"
> }
> }
> ]
>
> The thiss-js code is looking in the payload for key 'entity_id', not
> 'entityID'.
>
> Leif is this a limitation of thiss-js, or a bug in pyFF, or ?
>
> Thanks,
>
> Scott K
> _______________________________________________
> Idpy-discuss mailing list
> Idpy-discuss at lists.sunet.se
> https://lists.sunet.se/listinfo/idpy-discuss
9:28 a.m.
On Tuesday, September 24, 2019 11:24:09 PM CEST Scott Koranda wrote:
> What I can tell you is that if my pipeline has
this
>
> - select as ligo_approved:
> - "https://login.ligo.org/idp/shibboleth"
> - "https://shibbi.pki.itc.u-tokyo.ac.jp/idp/shibboleth"
> - "https://orcid-saml-gateway.gw-astronomy.org/idp"
>
> Then I can do a query like this:
>
> curl -H 'Accept: application/json'
> http://127.0.0.1:8080/entities/ligo_approved?query=kagra | python -m
> json.tool
>
> and "find" the KAGRA IdP (second in the list above).
But that assumes meticulously crafted configuration throughout the whole
stack, which means "knowing" the alias on every level (including nginx)? No
room for flexible alias'es in pyff's configuration and seamless adaptation in
thiss.io?
Grtz
Martin
9:08 a.m.
Skickat från min iPhone
24 sep. 2019 kl. 23:00 skrev Scott Koranda <skoranda at gmail.com>:
Right.
So, has
thiss.io been developed and/or used with pyff's select as alias in
mind and, will pyff allow the alias on the /api/search endpoint? Maybe Scott
made it work as he needs select as in some of his deployments?
Still working on it...
What I can tell you is that if my pipeline has this
- select as ligo_approved:
- "https://login.ligo.org/idp/shibboleth"
- "https://shibbi.pki.itc.u-tokyo.ac.jp/idp/shibboleth"
- "https://orcid-saml-gateway.gw-astronomy.org/idp"
Then I can do a query like this:
curl -H 'Accept: application/json'
http://127.0.0.1:8080/entities/ligo_approved?query=kagra | python -m json.tool
and "find" the KAGRA IdP (second in the list above).
So my hope is that I can create from a thiss-js repository clone a second
discovery service that has/uses a SEARCH_URL that points to
http://127.0.0.1:8080/entities/ligo_approved
and thereby deliver a second discovery service with the limited set of IdPs.
Note that the URL
http://127.0.0.1:8080/entities/ligo_approved?query=kagra
is NOT using the search API calls. It is processed using the full pipeline
mechanism. So it is slightly slower, but that is not a problem for my use
case.
I don't know if Leif will extend pyFF so that the
search API calls will
respect the alias.
Ok so now the penny drops on my end!
> HTH,
>
> Scott K
> _______________________________________________
> Idpy-discuss mailing list
> Idpy-discuss at lists.sunet.se
> https://lists.sunet.se/listinfo/idpy-discuss
> ls. It is processed using the full pipeline
> mechanism. So it is slightly slower, but that is not a problem for my use
> case.
>
I don't know if Leif will extend pyFF so that the
search API calls will
respect the alias.
> HTH,
>
> Scott K
> _______________________________________________
> Idpy-discuss mailing list
> Idpy-discuss at lists.sunet.se
> https://lists.sunet.se/listinfo/idpy-discuss
1914
days inactive
1915
days old
9 comments
3 participants
participants (3)
-
leifj＠sunet.se -
martin＠surfnet.nl -
skoranda＠gmail.com