OBG API clean up (#1270)

* OBG API clean up

* fixed wiremock tests resources according to cleaned OBG API

* returned field "remittanceInformationUnstructured",
rephrased endpoint

* changed header name (from 'Redirect-Code' to X-XREF-TOKEN),
query parameter (from redirectCode to xXrefToken) in ConsentAPI

* fixes in IntelliJ Http scripts

* fix in Wiremock test

* fixed mock date in ConsentUI test

consent-ui/src/app/ais/entry-page/initiation/accounts/accounts-consent-review/accounts-consent-review.component.ts

@@ -79,7 +79,7 @@ export class AccountsConsentReviewComponent implements OnInit {
         'response'
       )
       .subscribe((res) => {
-        this.sessionService.setRedirectCode(this.authorizationId, res.headers.get(ApiHeaders.REDIRECT_CODE));
+        this.sessionService.setRedirectCode(this.authorizationId, res.headers.get(ApiHeaders.X_XSRF_TOKEN));
         window.location.href = res.headers.get(ApiHeaders.LOCATION);
       });
   }

consent-ui/src/app/ais/entry-page/initiation/common/dedicated-access/dedicated-access.component.spec.ts

@@ -64,7 +64,7 @@ describe('DedicatedAccessComponent', () => {
         },
         frequencyPerDay: 24,
         recurringIndicator: true,
-        validUntil: '2021-06-24'
+        validUntil: '2022-06-24'
       }
     };
     consentUtilSpy = spyOn(ConsentUtil, 'getOrDefault').and.returnValue(mockData);

consent-ui/src/app/ais/entry-page/initiation/consent-initiate/consent-initiate.component.ts

@@ -55,7 +55,7 @@ export class ConsentInitiateComponent implements OnInit {
         this.sessionService.setBankName(authorizationId, (res.body as ConsentAuth).bankName);
         this.sessionService.setFintechName(authorizationId, (res.body as ConsentAuth).fintechName);
 
-        this.sessionService.setRedirectCode(authorizationId, res.headers.get(ApiHeaders.REDIRECT_CODE));
+        this.sessionService.setRedirectCode(authorizationId, res.headers.get(ApiHeaders.X_XSRF_TOKEN));
         this.navigate(authorizationId, res.body);
       });
   }

consent-ui/src/app/ais/entry-page/initiation/consent-sharing/consent-sharing.component.ts

@@ -45,7 +45,7 @@ export class ConsentSharingComponent implements OnInit {
     this.authStateConsentAuthorizationService
       .authUsingGET(this.authorizationId, redirectCode, 'response')
       .subscribe((res) => {
-        this.sessionService.setRedirectCode(this.authorizationId, res.headers.get(ApiHeaders.REDIRECT_CODE));
+        this.sessionService.setRedirectCode(this.authorizationId, res.headers.get(ApiHeaders.X_XSRF_TOKEN));
       });
     this.loadRedirectUri(this.authorizationId, redirectCode);
   }

consent-ui/src/app/ais/entry-page/initiation/transactions/transactions-consent-review/transactions-consent-review.component.ts

@@ -78,7 +78,7 @@ export class TransactionsConsentReviewComponent implements OnInit {
         'response'
       )
       .subscribe((res) => {
-        this.sessionService.setRedirectCode(this.authorizationId, res.headers.get(ApiHeaders.REDIRECT_CODE));
+        this.sessionService.setRedirectCode(this.authorizationId, res.headers.get(ApiHeaders.X_XSRF_TOKEN));
         window.location.href = res.headers.get(ApiHeaders.LOCATION);
       });
   }

consent-ui/src/app/ais/result-page/result-page.component.ts

@@ -65,7 +65,7 @@ export class ResultPageComponent implements OnInit {
   private loadRedirectUri(authId: string, redirectCode: string) {
     this.authStateConsentAuthorizationService.authUsingGET(authId, redirectCode, 'response').subscribe((res) => {
       console.log(res);
-      this.sessionService.setRedirectCode(authId, res.headers.get(ApiHeaders.REDIRECT_CODE));
+      this.sessionService.setRedirectCode(authId, res.headers.get(ApiHeaders.X_XSRF_TOKEN));
       this.redirectTo = res.headers.get(ApiHeaders.LOCATION);
     });
   }

consent-ui/src/app/ais/to-aspsp-page/to-aspsp-redirection.component.ts

@@ -57,7 +57,7 @@ export class ToAspspRedirectionComponent implements OnInit {
     this.authStateConsentAuthorizationService
       .authUsingGET(this.authorizationId, this.sessionService.getRedirectCode(this.authorizationId), 'response')
       .subscribe((res) => {
-        this.sessionService.setRedirectCode(this.authorizationId, res.headers.get(ApiHeaders.REDIRECT_CODE));
+        this.sessionService.setRedirectCode(this.authorizationId, res.headers.get(ApiHeaders.X_XSRF_TOKEN));
         this.redirectTo = res.headers.get(ApiHeaders.LOCATION);
       });
   }

consent-ui/src/app/api/api.headers.ts

@@ -1,5 +1,6 @@
 export enum ApiHeaders {
   REDIRECT_CODE = 'Redirect-Code',
+  X_XSRF_TOKEN = 'X-XSRF-TOKEN',
   LOCATION = 'Location',
   COOKIE_TTL = 'Cookie-TTL'
 }

consent-ui/src/app/api/api/authStateConsentAuthorization.service.ts

@@ -1,9 +1,9 @@
 /**
  * Open Banking Gateway - Consent Authorization API.
- * Interface used by the PsuUserAgent to present consent authorization services to the PSU. The consent authorization process is triggered by redirecting the PSU from the [TppBankingApi](https://adorsys.github.io/open-banking-gateway/doc/latest/architecture/dictionary#TppBankingApi) (2<sub>a</sub>) over the [FinTechApi](https://adorsys.github.io/open-banking-gateway/doc/latest/architecture/dictionary#FinTechApi) (2<sub>b</sub>) to the /consent/{auth-id} entry point of this [ConsentAuthorisationApi](https://adorsys.github.io/open-banking-gateway/doc/latest/architecture/dictionary#ConsentAuthorisationApi) (2<sub>c</sub>). The decision on whether the authorization process is embedded or redirected is taken by this ConsentAuthorisationApi.  The following picture displays the overall architecture of this open banking consent authorisation api:   ![High level architecture](/img/open-banking-consent-authorisation-api.png)   #### User Agent This Api assumes that the PsuUserAgent is a modern browsers that : * automatically detects the \"302 Found\" response code and proceeds with the associated location url, * stores httpOnly cookies sent with the redirect under the given domain and path as defined by [RFC 6265](https://tools.ietf.org/html/rfc6265).  This Api also assumes any other PsuUserAgent like a native mobile or a desktop application can simulate this same behavior of amodern browser with respect to 30X and Cookies.    #### Redirecting to the ConsentAuthorisationApi (2<sub>a</sub>) Any service request of the FinTechUI to the FinTechApi (1<sub>a</sub>) will be forwarded to the TppBankingApi (1<sub>b</sub>). This forward might contain a [PsuConsentSession](https://adorsys.github.io/open-banking-gateway/doc/latest/architecture/dictionary#PsuConsentSession) that is used to identify the PSU in the world of the TPP.  The TppBankingApi uses the provided PsuConsentSession to retrieve an eventualy suitable consent that will be used to forward the corresponding service request to the OpenBankingApi (1<sub>c</sub>) of the ASPSP. If there is no suitable consent, the TPP might still send a consent initiation request to the OpenBankingApi (1<sub>c</sub>). Whether this request is sent or not depends on the design of the target OpenBankingApi. Finally, the TppBankingApi will if necessary instruct the FinTechApi (2<sub>a</sub>) to redirect the PsuUgerAgent (2<sub>b</sub>) to the /consent/{auth-id} entry point of  the ConsentAuthorisationApi (2<sub>c</sub>).      #### Issolation Authorisation Request Processing The auth-id parameter is used to make sure paralell authorization requests are not mixup.      #### SessionCookies and XSRF Each authorisation session started will be associated with a proper SessionCookie and a corresponding XSRF-TOKEN. * The request that sets a session cookie (E<sub>1</sub>) also add the X-XSRF-TOKEN to the response header. * The cookie path is always extended with the corresponding auth-id, so two Authorization processes can not share state.  * Each authenticated request sent to the ConsentAuthorisationApi will provide the X-XSRF-TOKEN matching the sent SessionCookie.  #### RedirectCookie and XSRF (R<sub>1</sub>) In a redirect approach (Redirecting PSU to the ASPSP), the The retruned AuthorizeResponse object contains information needed to present a suitable redirect info page to the PSU. Redirection can either be actively performed by the UIApplication or performed as a result of a 30x redirect response to the PsuUserAgent. In both cases, a RedirectCookie will be associated with the  PsuUserAgent and a corresponding XSRF-TOKEN named redirectState will be addedto the back redirect url.      #### Final Result of the Authorization Process The final result of the authorization process is a PsuCosentSession that is returned by the token endpoint of the TppBankingAPi to the FinTechApi (4<sub>c</sub>). This handle will (PsuCosentSession) will be stored by the FinTechApi and added a PSU identifying information to each service request associated with this PSU. 
+ * Interface used by the PsuUserAgent to present consent authorization services to the PSU. The consent authorization process is triggered by redirecting the PSU from the [TppBankingApi](https://adorsys.github.io/open-banking-gateway/doc/latest/architecture/dictionary#TppBankingApi) (2<sub>a</sub>) over the [FinTechApi](https://adorsys.github.io/open-banking-gateway/doc/latest/architecture/dictionary#FinTechApi) (2<sub>b</sub>) to the /consent/{auth-id} entry point of this [ConsentAuthorisationApi](https://adorsys.github.io/open-banking-gateway/doc/latest/architecture/dictionary#ConsentAuthorisationApi) (2<sub>c</sub>). The decision on whether the authorization process is embedded or redirected is taken by this ConsentAuthorisationApi.  The following picture displays the overall architecture of this open banking consent authorisation api:   ![High level architecture](/img/open-banking-consent-authorisation-api.png)   #### User Agent This Api assumes that the PsuUserAgent is a modern browsers that : * automatically detects the \"302 Found\" response code and proceeds with the associated location url, * stores httpOnly cookies sent with the redirect under the given domain and path as defined by [RFC 6265](https://tools.ietf.org/html/rfc6265).  This Api also assumes any other PsuUserAgent like a native mobile or a desktop application can simulate this same behavior of amodern browser with respect to 30X and Cookies.    #### Redirecting to the ConsentAuthorisationApi (2<sub>a</sub>) Any service request of the FinTechUI to the FinTechApi (1<sub>a</sub>) will be forwarded to the TppBankingApi (1<sub>b</sub>). This forward might contain a [PsuConsentSession](https://adorsys.github.io/open-banking-gateway/doc/latest/architecture/dictionary#PsuConsentSession) that is used to identify the PSU in the world of the TPP.  The TppBankingApi uses the provided PsuConsentSession to retrieve an eventualy suitable consent that will be used to forward the corresponding service request to the OpenBankingApi (1<sub>c</sub>) of the ASPSP. If there is no suitable consent, the TPP might still send a consent initiation request to the OpenBankingApi (1<sub>c</sub>). Whether this request is sent or not depends on the design of the target OpenBankingApi. Finally, the TppBankingApi will if necessary instruct the FinTechApi (2<sub>a</sub>) to redirect the PsuUgerAgent (2<sub>b</sub>) to the /consent/{auth-id} entry point of  the ConsentAuthorisationApi (2<sub>c</sub>).      #### Issolation Authorisation Request Processing The auth-id parameter is used to make sure paralell authorization requests are not mixup.      #### SessionCookies and XSRF Each authorisation session started will be associated with a proper SessionCookie and a corresponding XSRF-TOKEN. * The request that sets a session cookie (E<sub>1</sub>) also add the X-XSRF-TOKEN to the response header. * The cookie path is always extended with the corresponding auth-id, so two Authorization processes can not share state.  * Each authenticated request sent to the ConsentAuthorisationApi will provide the X-XSRF-TOKEN matching the sent SessionCookie.  #### RedirectCookie and XSRF (R<sub>1</sub>) In a redirect approach (Redirecting PSU to the ASPSP), the The retruned AuthorizeResponse object contains information needed to present a suitable redirect info page to the PSU. Redirection can either be actively performed by the UIApplication or performed as a result of a 30x redirect response to the PsuUserAgent. In both cases, a RedirectCookie will be associated with the  PsuUserAgent and a corresponding XSRF-TOKEN named redirectState will be addedto the back redirect url.      #### Final Result of the Authorization Process The final result of the authorization process is a PsuCosentSession that is returned by the token endpoint of the TppBankingAPi to the FinTechApi (4<sub>c</sub>). This handle will (PsuCosentSession) will be stored by the FinTechApi and added a PSU identifying information to each service request associated with this PSU.
  *
  * The version of the OpenAPI document: 1.0
- * 
+ *
  *
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
  * https://openapi-generator.tech
@@ -87,9 +87,9 @@ export class AuthStateConsentAuthorizationService {
     }
 
     /**
-     * Redirect entry point for initiating a consent authorization process. 
-     * This is the &lt;b&gt;entry point&lt;/b&gt; for processing a consent redirected by the TppBankingApi to this ConsentAuthorisationApi.  At this entry point, the ConsentAuthorisationApi will use the redirectCode to retrieve the RedirectSession from the TppServer. An analysis of the RedirectSession will help decide if the ConsentAuthorisationApi will proceed with an embedded approach (E&lt;sub&gt;1&lt;/sub&gt;) or a redirect approach (R&lt;sub&gt;1&lt;/sub&gt;). 
-     * @param authId Used to distinguish between different consent authorization processes started by the same PSU. Also included in the corresponding cookie path to limit visibility of the consent cookie to the corresponding consent process. 
+     * Redirect entry point for initiating a consent authorization process.
+     * This is the &lt;b&gt;entry point&lt;/b&gt; for processing a consent redirected by the TppBankingApi to this ConsentAuthorisationApi.  At this entry point, the ConsentAuthorisationApi will use the redirectCode to retrieve the RedirectSession from the TppServer. An analysis of the RedirectSession will help decide if the ConsentAuthorisationApi will proceed with an embedded approach (E&lt;sub&gt;1&lt;/sub&gt;) or a redirect approach (R&lt;sub&gt;1&lt;/sub&gt;).
+     * @param authId Used to distinguish between different consent authorization processes started by the same PSU. Also included in the corresponding cookie path to limit visibility of the consent cookie to the corresponding consent process.
      * @param redirectCode Code used to retrieve a redirect session. This is generaly transported as a query parameter
      * @param observe set whether or not to return the data Observable as the body, response or events. defaults to returning the body.
      * @param reportProgress flag to report request and response progress.
@@ -105,7 +105,7 @@ export class AuthStateConsentAuthorizationService {
         let queryParameters = new HttpParams({encoder: this.encoder});
         if (redirectCode !== undefined && redirectCode !== null) {
           queryParameters = this.addToHttpParams(queryParameters,
-            <any>redirectCode, 'redirectCode');
+            <any>redirectCode, 'xXsrfToken');
         }
 
         let headers = this.defaultHeaders;