mdui:Logo not shown in discovery

[mrvanes]

We are investigating deployment of pyFF upstream/master again but noticed the absence of the carefully supplied IdP mdui:Logo in the discovery interface.

Code Version

git master

Expected Behavior

A discovery page that shows IdP logo's in selection list

Current Behavior

IdP's are shown, but without logo

Steps to Reproduce

1. Deploy master
2. Configure SATOSA to use pyFF as discovery service
3. Configure IdP with correct mdui:Logo element
4. Test discovery
5. See that IdP logo is missing in front of IdP description

[leifj]

Is this still an issue? There has been a lot of work in the ra21 branch and some of it has not been backported to the main branch.

[leifj]

Also note that there are some new options for controlling the discovery display that might be involved here.

[mrvanes]

I discussed this with Scott during last IdPy VC's and he told me this new behaviour was by-design. But if there's a switch to restore the display of IdP logo's I'm curious to find out!

[leifj]

On 2018-09-07 08:42, Martin wrote: I discussed this with Scott during last IdPy VC's and he told me this new behaviour was by-design. But if there's a switch to restore the display of IdP logo's I'm curious to find out!

Yeah there is - you can basically create your own page and call the disco JS yourself. There are hooks for all the rendering functions in there. The ds.html template is doing exactly this in fact. If you checkout the ra21.html you can see how an alternative disco implementation works - just another call to the discovery js. This is moving very fast tho. PRs welcome!

[mrvanes]

ra21.html isn't showing logo's either, so it's quite difficult to extract the logic to show them from it?

I see some {{#entity_icon}} and {{^entity_icon}} logic in ra21.html for the saved var, but if I blindly copy that to the search var compile statement I only get the empty svg circle, as if entity_icon wasn't set so ds resorts to some sort of fallback?

[leifj]

What I meant was that if you look at ra21.html you can see how to override the rendering code entirely. The mustache templates are just one way of doing this. I'm sorry the documentation is lagging quite a bit here.

[peppelinux]

Probably this issue do not depend by this js call, that is the following:

/role/idp.s?query=unica&entity_filter={http://macedir.org/entity-category}http://pyff.io/category/discoverable

its returning JSON is

[{"title": "IDP testunical", "descr": "IDP testunical", "entity_id": "http://idp1.testunical.it:9000/idp/metadata", "entityID": "http://idp1.testunical.it:9000/idp/metadata", "domains": "testunical.it", "id": "{sha1}389f287742186085faa2fba56d796470c8b24010", "matched": "IDP testunical", "ddist": 2} ...]

As we can see there isn't any icon item in the JSON response, despite of ".json" call, that is the following and it have:

[{"entityID": "http://idp1.testunical.it:9000/idp/metadata","type": "idp","title": "IDP testunical","icon": "http://idp1.testunical.it:9000/static/img/logo.svg","descr": "IDP testunical","auth": "saml"},
{"entityID": "http://idpspid.testunical.it:8088","type": "idp","title": "idpspid.testunical.it:8088","auth": "saml"}]

Even if we choose the .json resource as url for the search, as follow:

 <div id="dsclient"
                     data-href="{{ entity['entity_id'] }}"
                     data-mdq="/metadata/"
                     data-store="{{storage}}"
                     data-search="{{list}}" <- instead of {{ search }}
                     data-list="{{list}}"
                     data-related="{{ entity['domains'] }}"
                     data-inputfieldselector="#searchinput">

the data is not coherent and the logo will not be rendered as we expect.... I also noticed that .json call is slower then .s call.... By the way I fixed this here: #166

I just added d['logo'] in samlmd.entity_simple_summary and then added this into var search = Hogan.compile in ra21.html.

I got it to work, I just have to take a look also to ra21 related branches... If you have something to say I'm curious, please tell me more! :-)

[leifj]

Note that this is now legacy code. The roadmap will do away with all of this in favor of a new DS interface from the TheIdentitySelector project

[peppelinux]

Great to hear this, @leifj.
I made a bet on IdentityPython to put all the suite in a production context, so I need to patch all the things to get them ready. I cannot read any roadmap and I cannot see the future of all this great software, the only things I can do is to patch on every occourence and build a public fork with my patchy branches.

If someone of you can publish a roadmap or tell us what will be the features and in which release date they will come, I could follow you better in a active collaborationship.

Otherwise I'll do my best, continuing sharing as you are also doing, hoping to help someone like me with a lot of questions and little time!

thank you all

[leifj]

The roadmap is right here in the github wiki.

[peppelinux]

...so, probably IdentitySelector is the following:
https://github.com/TheIdentitySelector

I'd like to merge all these library in a django project, you probably already know this.
Thank you for the roadmap, I read it some days ago but cannot still understand goals in relation to time and personal needs, thank you for the remind!

Probably you need more time to reach those goals, hope to see those things working with a robust documentation too. Hope to help you also in a productive way. Good job

[leifj]

...so, probably IdentitySelector is the following:
https://github.com/TheIdentitySelector

yes

I'd like to merge all these library in a django project, you probably already know this.

I'm less convinced about that. There really is no need to serve up HTML, JS and CSS from the same point as your backend API (which pyFF is).

Thank you for the roadmap, I read it some days ago but cannot still understand goals in relation to time and personal needs, thank you for the remind!

Probably you need more time to reach those goals, hope to see those things working with a robust documentation too. Hope to help you also in a productive way. Good job

Yes

[peppelinux]

I meant Django as a app to deploy a frontend that used js libs to do the call. No serverside processing at all.

Django is so modular that everything would come as an app.

My next step would be the inspection of pyffd' main(). I'll run It with uwsgi, to set the Number of workers and other customizations. Argparse refactoring related to this #165 (comment) would be coupled with this. Thank you for your time and Sorry for the off topic

[leifj]

Skickat från min iPhone

26 apr. 2019 kl. 19:14 skrev Giuseppe De Marco ***@***.***>: I meant Django as a app to deploy a frontend that used js libs to do the call. No serverside processing at all.

How does django help? The frontend is static resources. lighthttpd/ngnix/apache in a container is enough... or even deploy to a cdn

…

Django is so modular that everything would come as an app. My next step would be the inspection of pyffd' main(). I'll run It with uwsgi, to set the Number of workers and other customizations. Argparse refactoring related to this #165 (comment) would be coupled with this. Thank you for your time and Sorry for the off topic — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[peppelinux]

Ok, I understand that Django Is a warm topic 😂
It's Just an idea to embed discoservice in a djangosaml2 SP as an app, nothing else. I Will not Say "Django" anymore, I promise!

[leifj]

I'm going to close this issue since it is referring to code that is about to be deprecated and removed from pyFF. Work on the UX has moved to mdq-browser and theidentityselector/thiss-js for the admin ui and discovery service respectively.