The mailing list for users of the eduroam Configuration Assistant Tool (CAT)

[Zenon Mousmoulas <zmousm AT noc.grnet.gr>]

Hi Stefan,

CAT UI POSTs parameters geo_long, geo_lat. Unless this part of the code 
is different on cat.eduroam.org, these are apparently serialized as 
strings in postProcessCoordinates():

https://github.com/GEANT/CAT/blob/master/web/admin/inc/option_parse.inc.php#L87

valid_coordinate() sanity-checks if these values are "a number or a 
numeric string".

The API on the other hand accepts: a PHP-style serialised array of two 
*numbers* "lat" and "lon".

I did a check using the one (user) API method that exposes such data:

-> curl -s 
'https://cat.eduroam.org/user/API.php?action=listAllIdentityProviders&lang=el' 
| \
 jq '[.[] | .geo[]? | map(type) | .[] ] | group_by((.)) | .[] | {type: 
.[0], count: length}'
{
  "type": "number",
  "count": 62
}
{
  "type": "string",
  "count": 4164
}

Guess which 31 institutions these pairs of lat, lon numbers correspond 
to :)

I think the issue is string vs. number and not the decimal separator (I 
am rather certain we never sent comma anyway). As you note here[1] CAT 
should avoid locale-aware number formatting, where necessary. In the 
case of generating an XML profile, I believe it should suffice to use 
sprintf('%.7F', <unserialized_number>).

[1] https://github.com/GEANT/CAT/issues/17

As for the particular 31 institutions, I could work-around the issue by 
re-provisioning to CAT while reformatting general:geo_coordinates for 
serializing strings rather than numbers. Or you could likewise update 
the database directly.
Thinking about it, the work-around involves more clicks (cumulatively) 
than using the CAT UI to achieve the same result, so I guess that is 
also an option.
If the database update as a short term work-around is an option, I 
suppose we'd much rather prefer that.

Thanks,
Z.

On 2016-09-23 10:49, Stefan Winter wrote:
> Hello,
>
> (for context: the number "five and a half" is not always 5.5 - in some
> languages, it gets printed as 5,5 and that confuses the XML device
> output - Android)
>
> Indeed, CAT UI never lets anyone actually input coordinates (i.e.
> numbers); this is done via a Google Maps pointer display, resulting
> deterministically in decimal *points* not commata. We internally store
> the data as an array which keeps decimal points as they are (but would
> also store commata as they are).
>
> The sanity check is calling is_numeric() which would let commata pass 
> if
> they were present, given a matching locale is set.
>
> Now if you used the admin-API to actually *send* us localised numbers
> with commata instead of decimal points, these would pass sanity checks
> and merrily live on.
>
> Within PHP, this is entirely correct as the locale settings now how to
> handle localised numbers. It only stops at the moment when these 
> numbers
> go into XML, which expects a decimal point.
>
> I believe there should be a twofold immediate response to get back
> timely to a working config:
>
> * a documentation update to admin-API spelling out that we expect
> decimal points, not commata
> * an update to the sanity checks to refuse coordinates with a decimal
> separator other than a decimal point.
>
> This would be part of 1.1.3 (less urgency because it only affects
> admin-API users with a commata-separating locale). And since the only
> admin who matches this group definition is aware of the issue, damage 
> is
> narrowly contained :-)
>
> > Users of 31 institutions are affected by this and can not use
> > CAT-Android without special instructions to switch their locale to
> > English; resetting the location via the admin UI might also remediate
> > the problem.
>
> Re-setting the location with the Google Maps widget in the CAT admin UI
> should indeed fix the issue immediately.
>
> We can also manually update the database to re-write commata to decimal
> points, but this needs some preparation and cannot be done before
> Monday. Shall we investigate this possibility, or do you think you can
> pursuade your insts to do this update in admin UI themselves?
>
> Greetings,
>
> Stefan Winter
>
> --
> Stefan WINTER
> Ingenieur de Recherche
> Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
> de la Recherche
> 2, avenue de l'Université
> L-4365 Esch-sur-Alzette
>
> Tel: +352 424409 1
> Fax: +352 422473
>
> PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
> recipient's key is known to me
>
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66