avoid providing internal notes to /whoami endpoint (fixes #170)

[pmauduit]

See mentioned issue #170 and related one (georchestra/georchestra#4280). This PR aims to avoid having the /whoami endpoint revealing the "internal notes" field from the LDAP, as it is an internal note on the user and is not meant to be available from the endpoint.

Tests: 2 tests added, also making sure that the /whoami endpoint will work when not connected (user is null).

[pmauduit]

(Auto-reviewing myself): I am not very fond of null testing user, as using an Optional some lines above should be about avoiding it, but is there another way ?

[Gaetanbrl]

but is there another way ?

I don't think so.

[pmauduit]

Also I am wondering if we should handle sensitive fields one by one (hashed passwords from the LDAP, internal CRM notes, ...), or if there are no other means for doing so ?

[Gaetanbrl]

Perhaps it would be interesting to be able to configure these fields ?

[pmauduit]

Perhaps it would be interesting to be able to configure these fields ?

why not, but we can't really predict what would be needed on the GeorchestraUser object in the coming months / years / ... and what should be stripped from the whoami endpoint, in my opinion.

Also making it configureable would leave the opportunity to the administrators to have flawed configurations revealing undesired fields, so I am a bit puzzled.

[groldan]

LGTM.
On a separate note, I think the whole point of the /whoami endpoint is being a debugging aid and should be disabled in any production deployment.
Or maybe, the default should be to only return the username and roles, but all the rest only when explicitly enabled either with a spring profile or a config property?

[f-necas]

should be disabled in any production deployment.

It's used for the header to set it up on each page. But maybe we should have a dedicated route in the console.

[pmauduit]

It's used for the header to set it up on each page. But maybe we should have a dedicated route in the console.

My concern is that having the same endpoint on the console would break the "modular" approach of geOrchestra. In some cases, the console is not even deployed (e.g. DT was not even using the geOrchestra LDAP in their "external" geOrchestra instance, so there were no console either), at least we can consider that the SP or the gateway would always be deployed. So for me having this endpoint on the GW / the SP makes sense.

[pmauduit]

Or maybe, the default should be to only return the username and roles, but all the rest only when explicitly enabled either with a spring profile or a config property?

Yes, sounds good