[geonetwork4] broken access to admin.console

[landryb]

since the large merge from gn4/@groldan's contributions, i can no longer access GN4 admin ui, visiting srv/fre/admin.console now redirects to srv/fre/catalog.search as a testadmin - that's using the war provided by the debian package 99.master.20211126164656~a74f564 built from georchestra/geonetwork@a74f564

i've manually applied all the apparently needed changes to geonetwork.properties and updated the LDAP DIT (cf https://gist.github.com/pmauduit/c743ac13cc4b08dd4cda150d6279ef16) to have the georchestraObjectIdentifier attribute - doesnt help.

[landryb]

the previously working war i had was from around end of august.

[landryb]

i have no idea if this has something to do with GN4 database schema, if it has to be updated to take into account the authz thing (eg new tables ? new fields in existing tables ?)

putting some debug here and there, the org.georchestra bits does query the console internal API at http://localhost:8280/console/internal/users, and the testadmin users has the right roles:

      "roles" : [
         "ADMINISTRATOR",
         "SUPERUSER",
         "GN_ADMIN",
         "USER",
         "MAPSTORE_ADMIN",
         "CAD_CNIL2"
      ],

guess some header things are still missing here and there ?

[landryb]

probably related to georchestra/datadir#221 being docker only and not applied to master. depressing.

[landryb]

still broken after manually backporting those bits, even if it seems a 'Principal' (whatever that is) correctly identifies testadmin as having GN_ADMIN role:

2021-11-29 13:49:21,832 DEBUG [org.georchestra.config.security] - Found header sec-user={base64}eyJ1c2VybmFtZSI6InRlc3RhZG1pbiIsInJvbGVzIjpbIkFETUlOSVNUUkFUT1IiLCJTVVBFUlVTRVIiLCJHTl9BRE1JTiIsIlVTRVIiLCJNQVBTVE9SRV9BRE1JTiIsIkNBRF9DTklMMiJdLCJvcmdhbml6YXRpb24iOiJwc2MiLCJpZC
I6IjU0MWIzNjMyLTA1Y2QtNGUzYy1hOGJlLTdlNWRhN2Q2MGU3OCIsImxhc3RVcGRhdGVkIjoiNGNlMGFiNzIwOWM3NmY0MjdmNzRjMGMxOGI5OGJiNTJiZTBkOTdjZTlkNjc1ZTQzYTViOGNjYjQ5MGRhMWVmZiIsImZpcnN0TmFtZSI6IlRlc3QiLCJsYXN0TmFtZSI6IkFETUlOIiwiZW1haWwiOiJhZG1pbkBjcmFpZy5mciIsInBvc3RhbEFkZHJlc3MiOiJCbGFo
IiwidGVsZXBob25lTnVtYmVyIjoidGVsIiwidGl0bGUiOiJ0aXRsZSIsIm5vdGVzIjoiSW50ZXJuYWwgQ1JNIG5vdGVzIG9uIHRlc3RhZG1pbiJ9 ({"username":"testadmin","roles":["ADMINISTRATOR","SUPERUSER","GN_ADMIN","USER","MAPSTORE_ADMIN","CAD_CNIL2"],"organization":"psc","id":"541b3632-05cd-4e3c-a8be-
7e5da7d60e78","lastUpdated":"4ce0ab7209c76f427f74c0c18b98bb52be0d97ce9d675e43a5b8ccb490da1eff","firstName":"Test","lastName":"ADMIN","email":"admin@craig.fr","postalAddress":"Blah","telephoneNumber":"tel","title":"title","notes":"Internal CRM notes on testadmin"})
2021-11-29 13:49:21,835 INFO  [org.georchestra.config.security] - Decoding user from sec-user header
2021-11-29 13:49:21,835 DEBUG [org.georchestra.config.security] - Decoding org from sec-org* individual headers
2021-11-29 13:49:21,835 DEBUG [org.georchestra.config.security] - Found header sec-org=psc
2021-11-29 13:49:21,835 DEBUG [org.georchestra.config.security] - Found header sec-orgname=Project Steering Committee
2021-11-29 13:49:21,835 DEBUG [org.georchestra.config.security] - principal: GeorchestraUserDetails(user=GeorchestraUser(username=testadmin, roles=[ADMINISTRATOR, SUPERUSER, GN_ADMIN, USER, MAPSTORE_ADMIN, CAD_CNIL2], organization=psc, id=541b3632-05cd-4e3c-a8be-7e5da7d60e7
8, lastUpdated=4ce0ab7209c76f427f74c0c18b98bb52be0d97ce9d675e43a5b8ccb490da1eff, firstName=Test, lastName=ADMIN, email=admin@craig.fr, postalAddress=Blah, telephoneNumber=tel, title=title, notes=Internal CRM notes on testadmin), organization=Optional[Organization(id=null, s
hortName=psc, name=Project Steering Committee, linkage=null, postalAddress=null, category=null, description=null, notes=null, lastUpdated=null, members=[])], anonymous=false, password=null, accountNonExpired=true, accountNonLocked=true, credentialsNonExpired=true, enabled=t
rue)

[landryb]

thanks to @pmauduit who found out what the issue is - in my instance, in the gn4 database users have authtype=LDAP (well, because they're previously coming from LDAP) and apparently this conflict with @groldan 's user sync.

if i set the field to NULL for testadmin, i can access GN4 admin console again.

[localhost:5432] geonetwork@georchestra=> update users set authtype=NULL where authtype='LDAP';
UPDATE 2

either this should be documented somewhere (#3547 ?), or the code in GN4 checking the authtype should be amended, or something... this will break all platforms upgrading from previous releases.

And ofc this wasnt caught because nobody does tests outside localhost installs from scratch within docker, instead of doing tests on real environments with datasets/user database from the real world :)

[pmauduit]

And ofc this wasnt caught because nobody does tests outside localhost installs from scratch within docker, instead of doing tests on real environments with datasets/user database from the real world :)

Not totally true: in fact I stumbled upon it when migrating the dev environment from geo2france, which is actually a docker/rancher-based setup ; I just totally forgot about it. But right, the recent developments lacked testing onto regular setups.

[fvanderbiest]

this should be documented somewhere (#3547 ?)

Migration notes, indeed.