Useless attributes names on Demo auth page

[Dick Visser]

Hi

The demo auth page /module.php/core/authenticate.php lists the various
authsources.
After clicking one and performing the actual auth, a table of
attributes is displayed.
That table shows the attribute names as 'user friendly'/translated
strings, see attached.

This page is almost exclusively used for debugging purposes ('what
attributes are you sending?'), and hence the desired behaviour is to
list the 'raw' attribute names.
Those can then be used to configure applications etc.
Seeing only a localised friendly name is not of much use here.

Would it be worth writing a patch that removes the translation so that
only bare names are displayed?


--
Dick Visser
System & Networking Engineer
TERENA Secretariat
Singel 468 D, 1017 AW Amsterdam
The Netherlands

[Peter Schober]

* Dick Visser <vis...@terena.org> [2013-05-17 11:34]:

> That table shows the attribute names as 'user friendly'/translated
> strings, see attached.
>
> This page is almost exclusively used for debugging purposes ('what
> attributes are you sending?'), and hence the desired behaviour is to
> list the 'raw' attribute names.
> Those can then be used to configure applications etc.
> Seeing only a localised friendly name is not of much use here.

While I don't particularly like the "friendly names" (as it hides what
actual attribute had been used, until you learn what those creative
translations are supposed to mean in each case) I do find that
preferable to always showing the formal names used on the wire for a
specific reason -- it's an indication of SSP's attribute mapping
working properly.
I.e., any attribute shown with the verbatim name used on the wire you
can be sure SSP has found no mapping for.
("It's a feture, not a bug", at least to me)

So I actually prefer the (to me non-sensical) friendly names, as they
signal that SSP has been able to munge then.
Anything SSP wasn't able to translate into gibberish ;) is there with
the formal name used on the wire, so gives you exactly the informaiton
you need (the actual name used) to map any unmapped attributes.

So surprisingly (to myself) I happen to like the behaviour of showing
non-technical names. Even (and especially) for debugging purposes.
-peter

[Thijs Kinkhorst]

Op vrijdag 17 mei 2013 12:57:47 schreef Peter Schober:

> So I actually prefer the (to me non-sensical) friendly names, as they
> signal that SSP has been able to munge then.
> Anything SSP wasn't able to translate into gibberish ;) is there with
> the formal name used on the wire, so gives you exactly the informaiton
> you need (the actual name used) to map any unmapped attributes.

A solution to satisfy everyone seems to be to add the "unfriendly" names in a
third colum, in grey font below the friendly name, or as a tooltip.


--
Thijs Kinkhorst <th...@uvt.nl> – LIS Unix

Universiteit van Tilburg – Library and IT Services • Postbus 90153, 5000 LE
Bezoekadres > Warandelaan 2 • Tel. 013 466 3035 • G 236 • http://www.uvt.nl

[Dick Visser]

On 17 May 2013 13:05, Thijs Kinkhorst <th...@uvt.nl> wrote:

>
> A solution to satisfy everyone seems to be to add the "unfriendly" names in a
> third colum, in grey font below the friendly name, or as a tooltip.

That sounds like a good compromise.

[Dick Visser]

On second thought, adding an extra column would make the page a bit
crowded. Tooltips are also not ideal because then copy/paste is
fiddly.
Attached patch adds the unfriendly name in parentheses after the
friendly name - but only if they are different.
So the information is there, without almost no extra clutter.

[Peter Schober]

* Dick Visser <vis...@terena.org> [2013-05-17 15:36]:

> On second thought, adding an extra column would make the page a bit
> crowded. Tooltips are also not ideal because then copy/paste is
> fiddly.
> Attached patch adds the unfriendly name in parentheses after the
> friendly name - but only if they are different.
> So the information is there, without almost no extra clutter.

Nice. Might not look as good with full qualified (i.e., URI
nameformat) attribute names, though. Don't know how easy it is to get
at the NameFormat attribute there but for those having the formal name
after a line break (and maybe in a monospaced font) would probably
work better. Just a though,
-peter