Chore: Keep relevant API calls like profile and authentication: a list of relevant API calls should be made

[Torgeir333]

A relevant list of API calls from React App to BFF

Background

The new authentication frontend React app is communicating with the BFF (backend-for-frontend) Dotnet app by way of a series of API calls.

It might be a good idea to make an exact list of all API calls that originate in the React app, with the exact shape of the fetched and posted objects. The key word in the title is "relevant", which appeared in issue #1 . Relevant is context dependent, a context that should be made clear.

A list of API calls (also see Swagger in dotnet app, the plan is to expand the list over time):

1) RefreshToken: /authfront/api/v1/authentication/refresh

Also called refreshJwtToken, also using window.location.href = getEnvironmentLoginUrl()
as fallback in case of error (se Note below):

2) fetchUserInfo: /authfront/api/v1/profile/user <simplified, orgName added>

This API call and the next are situated in userInfoSlice.ts of the Redux system,
and are exported for use by e.g. UserInfoBar in the component PageContainer.

Update 04.10.23: A problem has been encountered: the mock userInfo returned from BFF had a different
shape than expected by the Redux code (see note below).

3) (deprecated) fetchReportee: /authfront/api/v1/lookup/reportee/${altinnPartyId}

Here altinnPartyId = getCookie('AltinnPartyId');

In conclusion the two API calls fetchReportee and fetchUserInfo has been merged into one API call:

Returned is now a small object containing only what is used by frontend, that is userName and organizationName.

{
  "userName": "Testur Testursson",
  "organizationName": "TestParty"
}

Update 25.10.23 Rune L, Espen K, Torgeir H and Simen R had a Refinement meeting where it was decided that
the SystemUser Descriptor delivered to the Backend from the Frontend to create a new SystemUser now has the following structure:

{
  "userName": "Testur Testursson",
  "organizationName": "TestParty",
  "selectedSystemType": "visma_skatt_system"
}

4) Post JWK file: /authfront/api/v1/systemuser/uploaddisk

The (test) certificate uploaded from the Maskinporten page, is
a standard axios post of a form object, containing a single key:value pair,
which is filename: file, where "file" is the test.jwk file (1672 bytes, from Rune).
This endpoint is working. The resulting file appears in the /wwwroot/ folder in BFF.
Update 18.10.23: We will also try to send a Form-object with two addition key:value pairs,
in addition to the first key:value pair, which is the filename: file pair, thus:

{
  "filename": "the actual JWK-file",
"maskIntNavn": "navn-på-maskinporten-integrasjon",
  "maskinIntBeskrivelse": "beskrivelse-på-maskinporten-integrasjon"
}

Updated 23.10.23: Actually the call now goes to /uploadjwk endpoint.

5) GET SystemUserObjects for Overviewpage : /authfront/api/v1/systemuser/{partyId}

altinn-authentication Issue no 232 (see Repo Wiki for link),
specified an object. However, in update of 25.10.23: Rune L, Espen K, Torgeir H and Simen R
had a Refinement meeting where it was decided that
the SystemUser DTO delivered to the Frontend from the backend now has the following structure:

{
"id" : "37ce1792-3b35-4d50-a07d-636017aa7dbd",
"integrationTitle": "Nytt regnskapsystem",
"description": "Systemet som vi har kjøpt hos Visma. Kai og Guri vet alt om dette systemet.",
"productName": "visma_skatt_system",
"supplierName": "Visma As",
"supplierOrgno": "123456789MVA",
"ownedByPartyId": "orgno:91235123"
"created": "2023-01-01"
}

6) GET SystemRegister for CreationPage: /authfront/api/v1/systemregister/

returns a List (array) of RegisteredSystemDTO
altinn-authentication Issue no #67

Update 15.11.23: First object in List [array] should be empty (empty strings is ok, as agreed with Simen): this to ensure that the PullDownMenu
first choice is "empty" (there might be an option in the DesignSystem, but it is not
in the documentation the last time it was checked).

{
"systemTypeId" : "fancy_system_name",
"systemVendor" : "Fancy System Vendor",
"description" : "Vårt nye system som kan brukes til Alt."
}

7) GET Default Rights for new RightsIncludedPage : /authfront/api/v1/systemregister/product/{productId}

This new (mock per 10.01.24) endpoint returns a List (array) of DefaultRightsDTO objects (see file SystemRegisterController.cs):

{ 
"Right" : "Mva Registrering", 
"ServiceProvider" : "Skatteetaten", 
}

Array returned by Swagger :

[
  {
    "right": "Mva Registrering",
    "serviceProvider": "Skatteetaten"
  },
  {
    "right": "Lønns Rapportering",
    "serviceProvider": "Skatteetaten"
  },
  {
    "right": "Lakselus Rapportering",
    "serviceProvider": "Mattilsynet"
  }
]

8) GET Current Rights for new OverviewPage : /authfront/api/v1/systemuser/{systemUserGuid}

The partyId is implicit in the http.context, and is not needed in the url.
This new (mock per 15.01.24) endpoint returns a List (array) of CurrentRightsDTO objects :

{ 
"Right" : "Mva Registrering", 
"ServiceProvider" : "Skatteetaten", 
"read": true,
"write": false,
"sign": false,
"read_archive": true
}

Array returned by Swagger <ikke klar ennå> :

[
  {
    "right": "Mva Registrering",
    "serviceProvider": "Skatteetaten",
      "read": true,
      "write": false,
      "sign": false,
      "read_archive": true
  },
  {
    "right": "Lønns Rapportering",
    "serviceProvider": "Skatteetaten",
      "read": true,
      "write": false,
      "sign": false,
      "read_archive": true

  },
  {
    "right": "Lakselus Rapportering",
    "serviceProvider": "Mattilsynet"
     "read": true,
      "write": false,
     "sign": false,
     "read_archive": true
  }
]

9) POST New SystemUser from CreationPage: POST /authfront/api/v1/systemuser/, systemUserInfo-object

Update 08.01.23: The information posted from CreationPage has been simplified to
export interface CreationRequest {
integrationTitle: string,
selectedSystemType: string,
}

New PostObjekt =

{
      "integrationTitle" : "integrationName",
      "selectedSystemType" : "selectedSystemType",
}

Old PostObjekt =

{
      "integrationTitle" : "integrationName",
      "description" : "descriptionEntered",
      "selectedSystemType" : "selectedSystemType",
      "clientId" : "notImplemented",
      "ownedByPartyId" : "notImplemented"
}

Update 15.11.23:
returns 200 OK (or error)
but per 15.11.23 it also returns id --> assume p.t. that it is this simple JSON object:

{
"id" : "37ce1792-3b35-4d50-a07d-636017aa7dbd",
}

Note on getEnvironmentLoginUrl():

The getEnvironmentLoginUrl() method contains 4 different pseudo-paths of the shape "https://${domainSplitted[2]}.${domainSplitted[3]}.${domainSplitted[4]}/ui/Profile,
); // Return user to Profile after login" and will be ignored until documentation can be produced.

[Torgeir333]

04.10.23: Update on Problem of fetchUserInfo: /authfront/api/v1/profile/user
This API call and the next are situated in userInfoSlice.ts of the Redux system,
and are exported for use by e.g. UserInfoBar in the component PageContainer.

A problem has been encountered: the mock userInfo returned from BFF had a different
shape than expected by the Redux code. The Swagger informed of the following shape, which is also the shape seen by Chrome Redux DevTools and Web Inspector:

{
  "userId": 20004938,
  "userName": "JarleErKul",
  "phoneNumber": "90001337",
  "email": "[email protected]",
  "partyId": 50019992,
  "party": {
    "userType": 1,
    "profileSettingPreference": {
      "language": "nb"
    }
  }
}

But the UserInfoSlice.ts expected dataArray.party.name.

We need to establish the exact shape of the userInfo object received from the login/Profile process.

[Torgeir333]

We have now made two iterations on this issue. The full userProfile object is large, and nested.
Thus the BFF is now tasked with returning just what is actually used in Frontend: userName and organizationName (also called by various other, outlandish names, e.g. reportee, party etc).

{
  "userId": 20004938,
  "userName": "Testur Testursson",
  "externalIdentity": "",
  "phoneNumber": "90001337",
  "email": "[email protected]",
  "partyId": 50019992,
  "party": {
    "partyId": 0,
    "partyTypeName": 0,
    "orgNumber": null,
    "ssn": null,
    "unitType": null,
    "name": "TestParty",
    "isDeleted": false,
    "onlyHierarchyElementWithNoAccess": false,
    "person": null,
    "organization": null,
    "childParties": null
  },
  "userType": 1,
  "profileSettingPreference": {
    "language": "nb",
    "preSelectedPartyId": 0,
    "doNotPromptForParty": false
  }
}

The simplified structure returned by userAPI call is:

{
  "userName": "Testur Testursson",
  "organizationName": "TestParty"
}

[simen-rekkedal]

There will probably be a need to have a "Friendly name" for the product name. ( maybe reuse the deprecated Beskrivelse field ?)

[simen-rekkedal]

Changed the url for some api calls, there is no need to have the partyId as a part of the URL, since I can read that from the cookie in the http.context