Itgencun016: Fout -20163: Connected as user ACME\JOHN, but should have been connected as ACME

Vragen
, ,
1

Sinds upgrade naar versie 20.2.125 krijgen we bij het repliceren van Loket de volgende foutmelding:

itgencun016: Fout -20163: Connected as user ACME\JOHN, but should have been connected as ACME

In de procedure staat:

--
-- Check whether the current connected user equal a specific
-- user and data container ID for a specific data container (when specified). 
-- When not, raise an error.
--
create or replace procedure xxhosting_check_user
( p_data_container_id varchar2
, p_log_on_code       varchar2
, p_alias             varchar2 -- default null
)
is
begin
  --
  -- Check correct user.
  --
  if sys_context('USERENV', 'CURRENT_USER', p_alias) != p_log_on_code
  then
    raise_application_error
    ( -20163 /* xxive001 */
    , 'Connected as user ' 
      || user
      || ', but should have been connected as '
      || p_log_on_code
      || '.'
    );
  end if;
  --
  -- Check correct data container ID.
  --
  if sys_context('USERENV', 'DATA_CONTAINER_ID', p_alias) != p_data_container_id
  then
    raise_application_error
    ( -20163 /* xxive002 */
    , 'Connected on data container ID ' 
      || sys_context('USERENV', 'DATA_CONTAINER_ID')
      || ', but should have been connected to '
      || p_data_container_id
  	   || ' on alias '
	     || p_alias
      || '.'
    );
  end if;
end;

En de aanroep vanuit SQL-script is:

local on error exit failure

local define AGREEMENT_CODE "L1234567"

local define REQUIRED_DATA_CONTAINER_ID "https://api.loket.nl/v2/developer.loket.nl/ACME/4"

local define REQUIRED_USER_ID "ACME"

local define CLOUD_WATCH_PREFIX "ACME"

local remark  END OF CONFIGURATION SECTION 

@@d:\jobs\hosting\sql\xxhosting.sql

@@d:\jobs\hosting\sql\xxdru.sql

begin
  xxhosting_initialize;
  xxhosting_check_user('${REQUIRED_DATA_CONTAINER_ID}', '${REQUIRED_USER_ID}', null);
  xxhosting_check_agreement('${AGREEMENT_CODE}');
end;

Hoe kunnen we deze foutmelding oplossen?

2

De stored procedure doet een aantal controles:

  • Is het programma verbonden met de juiste gebruiker?
  • Is het programma verbonden met de juiste datacontainer?

Dat helpt bij het voorkomen van een datalek doordat per abuis gegevens van een andere omgeving geladen worden in een database.

De volgende regel PSQL voert de controle uit:

xxhosting_check_user('${REQUIRED_DATA_CONTAINER_ID}', '${REQUIRED_USER_ID}', null);

De waarde in REQUIRED_USER_ID stemt dus niet overeen met de gevonden user.

Ik zou sowieso aanraden om de datacontaineralias ook door te geven i.p.v. null. Met null is het maar afwachten naar welke datacontainer gekeken wordt; vooral als er meerdere datacontainers geopend worden is het wel deterministisch maar afhankelijk van de inrichting van de database in welke volgorde.

De reden dat na upgrade een foutmelding optreedt is omdat de bepaling van gebruikersnamen en datacontainer ID’s van versie naar versie telkens verfijnd wordt. In dit geval wordt mogelijk door null op de users op Windows of Linux gecontroleerd, en niet op de Loket-gebruiker.

Eindadvies daarom om eerst de alias in te stellen en daarna nogmaals te draaien. Er zal een foutmelding uitkomen met de gevonden gebruikersnaam. Controleer of dat de verwachte naam is en zet die dan in ${REQUIRED_USER_ID}.

Zie ook:

3

Bij diepere controle blijkt dat een ongedocumenteerde Loket API die gebruikt wordt om de gebruikersnaam te achterhalen momenteel niet beschikbaar is. We hopen te horen of daar een alternatief voor is.

4

Een alternatieve oplossing is gevonden voor de vervallen Loket.nl API. Die is beschikbaar in alle 22.0 versies en Invantive Cloud.