Konfigurálási lehetőségek

1. Alkalmazásszintű konfiguráció

A Semi product több dolgot is kivezet az application.yml fájlba, hogy a projektek tetszőlegesen tudjanak adott működéseket választani.

A következő dolgokban lehet jelenleg dönteni, de itt csak az üzletileg is értelmezhető paramétereket szedjük össze. Szóval az adatbázis, SMTP, stb. paramétereket itt nem részletezzük, mert azok egyértelműek, hogy konfigurálásra szorulnak, és csak technikai paraméterek valójában.

1.1 Aktivációs paraméterek

project:
  activation-properties:
    ${application-type}:
      token-expiration: 3d

Az ${application-type} placeholder helyén értelemszerűen az alkalmazás neve szerepel az application.yml-ben (admin, client, stb.)

1.2 Password policy

A password policy konfigurálható alkalmazás típusonként:

project:
  auth:
    password:
      ${application-type}:
        min-length: 10
        max-length: 20
        lowercase-count: 1
        uppercase-count: 2
        number-count: 2
        special-characters-count: 0
        special-characters: "!\" #$%&'()*+,-./:;<=>?@[\\]^_`{|}~"
        reset-password-token-expiration: 3d

Az ${application-type} placeholder helyén értelemszerűen az alkalmazás neve szerepel az application.yml-ben (admin, client, stb.)

Speciális karakter megadása kétféleképpen történhet. Vagy kitöröljük a special-characters sort, ilyenkor minden karakter speciálisnak fog számítani, ami nem szám vagy betű. Ugyanakkor megadhatjuk kézzel is, hogy mit szeretnénk speciálisként kezelni, ebben az esetben ugyanezt a sort kell igény szerint módosítani. Fontos, hogy néhány karakter a fájlban is jelöl már valamit, például az escape karakter \, vagy a ", ami lezárná a stringet, így ezek elé tenni kell egy karaktert.

1.3 Password history

Az alkalmazás képes visszamenőleg tárolni a jelszavakat. Felhasználónként annyi jelszót tárolunk, amilyen max-size értéket megadunk az alábbi konfigurációban. Amennyiben a felhasználó jelszóváltoztatásnal egy a historyban megtalálható korábbi jelszót akar beállítani, a jelszóváltoztatás hibaüzenetet dob.

Ha projekten nem akarjuk a password history funkciót, akkor a max-size értékét állítsuk 1-re.

project:
  auth:
    password-history:
      history-sizes:
        ${application-type}:
          max-size: 3

Az ${application-type} placeholder helyén értelemszerűen az alkalmazás neve szerepel az application.yml-ben (admin, client, stb.)

1.4 Login paraméterek

project:
  login:
    max-attempts: 5
    reset-attempts-time: 1440m
    password-expiration: 3650d

1.5 Session hosszának konfigurálása

project:
  auth:
    session:
      session-length:
        browser:
          client: 30m
          admin: 30m
          partner: 30m
        mobile:
          client: 10m

1.6 Párhuzamos sessionök száma

project:
  auth:
    session:
      concurrent-session:
        browser:
          admin:
            max-concurrent-session: 100
          client:
            max-concurrent-session: 100
        mobile:
          admin:
            max-concurrent-session: 100
          client:
            max-concurrent-session: 100

1.7 Notification

1.7.1 Konfigurációs lehetőségek

Projekt indulása során dönthetünk róla, hogy az értesítések automatikusan mentésre kerüljenek adatbázisba vagy sem.

Alapértelmezett módon mentésre fognak kerülni.

project:
  notification:
    email:
      save-to-db: true
    push:
      save-to-db: true
    sms:
      save-to-db: true

Továbbá, hogy az email milyen címről menjen ki, amit lát a felhasználó

project:
  notification:
    email:
      email-from-address: valami@valami.valami

Megadhatjuk a megjelenítendő nevet is, ami az email cím előtt fog látszódni

project:
  notification:
    email:
      email-from-display-name: Alkalmazás

Huawei specifikus push notification konfiguráció:

Az AppGallery Connect-ben regisztrált alkalmazásunk client ID-ját és client secret-jét állítsuk be a megfelelő client-id és client-secret mezők értékének.

project:
  notification:
    push:
      huawei:
        client-id: ${client-id}
        client-secret: ${client-secret}

Firebase specifikus push notification konfiguráció:

A Firebase-hez nem szükséges extra konfiguráció, mert a projektspecifikus firebase.json fájlunk fogja tartalmazni a szükséges paramétereket.

A Firebase konfiguráláshoz szükséges információk pedig megtalálhatóak az DEV/Teszt és a UAT/PROD telepítési útmutatókban.

1.7.2 Email template-ek

A SEMI product email értesítéseihez tartozó template-ek a noti_templates táblában találhatóak.

Fontos, hogy habár ezek az emailek technikaileg teljesen használhatóak és működőképesek, de formailag és tartalmilag nem biztos, hogy megfelelnek a projekt igényeinek. Épp ezért, a projekt indulásakor ezeket ellenőrizzük és a becslések, design tervek elkészítésekor ez alapján kalkuláljunk velük.

1.8 Feltölthető fájlok maximum mérete globálisan

Két helyen kell konfigurálni, mert egyrészt a tomcat globális részénél:

spring:
  servlet:
    multipart:
      max-file-size: 25MB
      max-request-size: 25MB

Másrészt funkciónként is konfigurálható, itt viszont fontos, hogy a fenti globál confignak legalább akkorának kell lenni, mint a legnagyobb méretű featurenél.

project:
  file-upload: #in this application.yml, the spring.servlet.multipart.max-file-size and max-request-size value has to be at least the same as the highest value in this list
    max-file-sizes:
      test_feature: '25MB'

1.9 Mobil alkalmazások store url-jei

Az egyes alkalmazás store-ok elérhetősége platformonként konfigurálható az alábbi paraméterekkel:

project:
  latest-version-details:
    platform-latest-version-details:
      android:
        store-url: https://valami-url.com
      ios:
        store-url: https://valami-url.com
      huawei:
        store-url: https://valami-url.com

Értelemszerűen azt az url-t kell itt megadni, amelyen keresztül az adott platformhoz tartozó legfrissebb mobil alkalmazás letölthető.

1.10 Keycloak authentikáció konfigurálása Admin felhasználók számára

Keycloak authentikáció esetén bizonyos funkciók megfelelő működéséhez szükséges egyedi felhasználói azonosítók használata. Ezt az azonosítót a JWT-ből veszi ki az alkalmazás egy konfigurálható claimből. Ez a claim alapértelmezetten a preferred_username, de tetszőlegesen módosítható az project.keycloak.identifier-claim módosításával.

Szintén konfigurálható az admin felület jobb felső sarkában megjelenített felhasználónév forrása, amely alapértelmezetten szintúgy a preferred_username claimből kerül kiolvasásra. Ennek módosításához írjuk át a project.keycloak.username-claim beállítást.

project:
  keycloak:
    identifier-claim: preferred_username
    username-claim: preferred_username

Ugyanezen a ponton konfigurálható a szerepkörök megfeleltetése, azaz hogy mely Keycloak szerepkör mely alkalmazásbeli szerepkörnek feleljen meg. A kulcs az alkalmazásbeli szerepkör, míg az érték a Keycloak szerepkör, előbbi esetén RoleEnum megadása szükséges.

project:
  keycloak:
    role-mapping:
      ADMIN: ADMIN
      SUPER_ADMIN: SUPER_ADMIN

1.11 Internal authentikáció bekapcsolása Admin felhasználók számára

Az authentikáció típusát az admin alkalmazásnál írjuk át INTERNAL-ra az application.yml fájlban:

project:
  auth:
    authentication-type:
      application-type-authentication-types:
        admin: INTERNAL

Ugyanezt meg kell tennünk frontenden is. A frontend repositoryban található projects/admin/src/environments/environment.ts és projects/admin/src/environments/environment.prod.ts fájlokban írjuk át az auth értékét Auth.INTERNAL-ra.

1.12 LDAP authentikáció bekapcsolása Admin felhasználók számára

Amennyiben a projekt azt kívánja meg, hogy az Admin típusú felhasználókat LDAP-ból authentikáljuk, az alábbi konfigurációs paramétereket kell módosítani:

1.12.1 Liquibase context-ek módosítása

A Liquibase context-ek között semmiképp ne szerepeljen a no-ldap, és amennyiben semmilyen egyéb context nincs megadva, adjuk meg az ldap context-et.

spring:
  liquibase:
    contexts: ldap

1.12.2 Az authentikáció típusának módosítása

Az authentikáció típusát az admin alkalmazásnál írjuk át LDAP-ra:

project:
  auth:
    authentication-type:
      application-type-authentication-types:
        admin: LDAP

1.12.3 Captcha konfiguráció

A Semi Productban bekapcsolható a reCaptcha v2 és a reCaptcha v3 az alábbi konfigurácóval:

project:
  techcore:
    captcha:
      enabled: true

Ha az enabled mezőt false-ra állítjuk, akkor nem fog megjelenni az oldalon a captcha, és nem történik validáció sem.

Ha szeretnénk, hogy megjelenjen az oldalon a captcha, de tényleges validáció ne történjen, akkor a project.captcha.validation-on mezőt kell false-ra állítani.

A project.captcha.verification-url a google captcha verifikációs linkjére mutat, ezt csak abban az esetben kell módosítani, ha az esetleg változna.

A v2 alatt kell megadni a Google-től kapott site key-t és secret key-t. Ezt a két property-t a reCAPTCHA hivatalos oldalán tudjuk generáltatni a Google-el. A v3-as captcha esetében ugyanezt kell megtenni.

Minden captcha esetében külön site és secret key generálás szükséges.

project:
  captcha:
    valiadtion-on: true
    verification-url: https://www.google.com/recaptcha/api/siteverify
    v2:
      site-key: ${PROJECT_V2_SITE_KEY}
      secret-key: ${PROJECT_V2_SECRET_KEY}
    v3:
      site-key: ${PROJECT_V3_SITE_KEY}
      secret-key: ${PROJECT_V3_SECRET_KEY}  

Frontenden is meg kell adni a site key-t, ezt a docker compose fájlban tehetjük meg.

Captcha ellenőrzés az alkalmazásokban

Jelenleg, ha bekapcsoljuk a captcha-t az application.yml-ben, akkor az csak az Ügyfél alkalmazás, regisztráció képernyőjén fog megjelenni. Amennyiben további oldalakon is szeretnénk megjeleníteni, az fejlesztést igényel a projekten.

1.13 Google Analytics konfigurációk

Ha szeretnénk bevezetni a Google Analytics-et a rendszerbe, a következő dolgokat kell megcsinálnunk:

1. Létre kell hozni egy Google Analytics fiókot, vagy bejelentkezni egy meglévő Google fiókkal. Ezután készíteni kell egy új property-t, ezt egyből fel fogja ajánlani. A property-n belül létre kell hozni egy új WEB típusú data stream-et, ami az adatforgalmat fogja vizsgálni. Az URL nem fontos hogy valid legyen, később több domain-t is megadhatunk. Ha ezekkel végeztünk, kapunk egy measurement id-t, erre szükség lesz.

2. Az eventek kezeléséhez Google Tag Manager-t használunk, így ehhez is kell egy account. Itt is válasszuk ki, hogy WEB típusú legyen. Ha végig megyünk a folyamaton, elkészül a container-ünk, és kapunk hozzá egy container id-t.

3. Ezután létre kell hozni egy új tag-et Google Tag Manager-ben: Tags -> new. A Tag Configuration-t állítsuk be Google Analytics: GA4 Configuration-re, és adjuk meg a measurement-id. Ezzel össze lesz kötve a Google Analytics és a Tag Manager. Triggering eventnek hozzunk létre egy új triggert, válasszuk ki az All Pages opciót. Mentsük el, majd felül Submitoljuk a változtatásokat: Submit -> Publish.

4. A docker compose fájlban hozzá kell adni két környezeti változót: a funkció bekapcsolása, és a Google Tag Manager Container ID-t: $PROJECT_GOOGLE_ANALYTICS_ENABLED, $PROJECT_GTM_CONTAINER_ID

5. Ezek után a mérés már működik is, Reports -> Realtime menüpont alatt láthatjuk a közel valós idejű aktivitásokat.

Tip

A Google Analytics ajánlott beállításairól, custom eventekről, és lokális tesztelésről itt található bővebb infó.

1.14 Többnyelvűség

Az alkalmazásban igény szerint lehet megadni nyelveket, amelyeket támogathat weboldalunk.

Ehhez szükségünk lesz egy alapértelmezett nyelvre, valamint a további támogatott nyelvek listájára, amelyek az application.yml fájlban konfigurálhatók:

project:
  locale:
    defaultLocale: hu_HU
    supported:
      hu: hu_HU
      en: en_US

1.14.1 Nyelv hozzáadása

Amennyiben új nyelvet szeretnénk hozzáadni:

1. Létre kell hozni hozzá egy messages_újnyelv.properties fájlt (backend/backend-service/src/main/resources/messages/messages_ujnyelv.properties).

2. Valamint létre kell hozni egy ujnyelv.json fájlt (frontend/shared/assets/i18n/ujnyelv.json).

   (például német nyelv esetén a fenti két fájl: messages_de.properties, de.json)

3. Értelemszerűen a fenti fájlokban kell elhelyezni a nyelvnek megfelelő fordításokat.

4. Az api projektben a common-schemas.yml fájlban a LocaleEnum definicíójához is adjuk hozzá az új nyelvet. (backend/backend-service/src/main/resources/api/common/schema/common-schemas.yml).

   Pl.: német nyelv esetén így kell kinéznie a LocalEnum definíciójának:

   LocaleEnum:
     type: string
     enum:
       - HU
       - EN
       - DE
   

5. Továbbá annak érdekében, hogy a fordítások ne legyenek cachelve a böngészőben, a frontend projektben található docker mappában, az nginx.conf fájlban is adjuk hozzá az új nyelvhez tartozó .json fájl nevét a megfelelő location configba:

   Pl.: német nyelv esetén így kell kinéznie a cachelést érintő location confignak az nginx.conf fájlban:

     location ~* (^.+\.(html)$|hu.json$|en.json$|de.json$) {
       expires -1;
       add_header Pragma "no-cache";
       add_header Cache-Control "no-cache, no-store, must-revalidate";
       add_header Last-Modified "";
       add_header Content-Security-Policy "${PROJECT_CSP}" always;
     }
   

1.14.2 Nyelvek eltávolítása

Semi producton alapértelmezetten támogatva van a magyar nyelv mellett az angol is. Amennyiben valamelyik nyelvet szeretnénk kikapcsolni az itt található lépéseket szükséges végrehajtani.

1.15 Determinisztikus sorbarendezés és lapozás

Az adatok lapozással történő betöltésekor duplikált értékekkel találkozhatunk, amennyiben nem történik sorbarendezés egyedi érték alapján. Emiatt született egy megoldás, amely ki tudja egészíteni a felhasználó által kért sorbarendezést egy egyedi érték sorbarendezésével is.

Ez a funkció kikapcsolható vagy az egyedi értékkel rendelkező mező neve (alapértelmezetten id) felülírható az application.yml fájlban:

project:
  techcore:
    default-sort:
      enabled: true
      default-property: id

Van lehetőség végpont szintű szabályozásra is, erről valamint további részletekről itt olvashatsz.

1.16 SameSite cookie attribútum

Az alkalmazásban használt cookie-k esetén, a SameSite attribútum értéke alapértelmezetten Strict. Ez az attribútum extra védelmet nyújt a CSRF támadások ellen. Pl.: Blokkolja a cookie-k automatikus küldését, third party context-ből indított POST hívások esetén.

Fontos, hogy ez az attribútum nem helyettesíti az alkalmazás alapértelmezett CSRF mechanizmusát, csupán extra védelmi rétegként funkcionál.

A SameSite attribútumról itt olvashatsz részletesebben.

Szükség esetén az alábbi property-t módosítva lehet konfigurálni a SameSite attribútum értékét:

project:
  cookie:
    same-site: STRICT

Lehetséges értékek:

• STRICT
• LAX
• NONE

1.17 One Time Password paraméterek

Amikor megerősítés kell mielőtt tovább enged a rendszer, abban az esetben tudjuk használni az One Time Password mechanizmust, amit az alábbi paraméterekkel konfigurálhatunk:

project:
  techcore:
    one-time-password:
      token-expiration: 20s
      token-length: 6

Az token-expiration mezőben állítjuk be, hogy milyen hosszú legyen egy One Time Password token érvényessége.

Az token-length mezőben állítjuk be, hogy hány darab karakterből (számból) álljon egy One Time Password token karakterlánc.

1.18 Cache kikapcsolása a projekten

Amennyiben szeretnénk kikapcsolni a beépített cachelést a projekten, azt az alábbi konfigurációval tehetjük meg:

1. A project.techcore.cache.enabled paramétert állítsuk false-ra:

   project:
     techcore:
       cache:
         enabled: false
   

2. A backend/backend-service mappában található pom.xml-ben a project.dependencies szekcióból töröljük ki az alábbi sorokat:

           <!--    Redis    -->
           <dependency>
               <groupId>org.springframework.boot</groupId>
               <artifactId>spring-boot-starter-data-redis</artifactId>
               <scope>provided</scope>
           </dependency>
   
           <dependency>
               <groupId>org.springframework.session</groupId>
               <artifactId>spring-session-data-redis</artifactId>
               <scope>provided</scope>
           </dependency>
   

3. A backend/backend-service/src/main/java/io/gbsolutions/project/techcore/cache/config mappából töröljük ki a RedisCacheConfig.java fájlt.

4. A backend/backend-service/src/main/java/io/gbsolutions/project/techcore/cache/properties mappából töröljük ki a RedisCacheProperties.java fájlt.
5. Ezután a projekt újrabuildelését követően a cache-elés ki lesz kapcsolva.

1.19 HTTP request/response logolás

1.19.1 Logolás be-/kikapcsolása

Amennyiben a projekten igény, hogy a logokba bekerüljön az alkalmazásba érkező HTTP kérések/válaszok tartalma, akkor ez az alábbi konfigurációs paraméterrel kapcsolható be:

project:
  techcore:
    log:
      http-payload:
        enabled: true

1.19.2 Mezők maszkolása

Amennyiben vannak szenzitív kérés/válasz argumentumok amiket szeretnénk maszkolni a logban, akkor az alábbi konfigurációs paraméternél kell felsorolni ezen argumentumok nevét:

project:
  log:
    http-payload:
      fields-to-mask:
        - password

A fenti konfiguráció esetén, a password névvel rendelkező kérés/válasz argumentumok értéke teljes egészében maszkolva kerül a logba. Pl.:

body = [{"password":[*****],"username":"client_1@gbs.demo"}]

Ha szeretnénk, hogy az authentikációs tokenek (CSRF header, Session cookie) értékei is maszkolva kerüljenek a logba, akkor azt az alábbi paraméterrel lehet bekapcsolni:

project:
  log:
    http-payload:
      mask-auth-tokens: true

1.19.3 Kérés/válasz argumentumok hossz limitációja

Konfigurálható továbbá az a maximális érték, amelynél több karakterből álló kérés/válasz argumentumok esetén a tényleges argumentum érték helyett egy placeholder szöveg kerüljön a logba. Ez a limit az alábbi konfigurációs paraméterrel állítható be:

project:
  log:
    http-payload:
      max-text-value-length: 1300

Az alapértelmezett érték 1300 karakter. Az ennél több karakterből álló kérés/válasz argumentumok maszkolásra kerülnek a logban.

1.19.4 Paraméterek és/vagy body logolásának ki-/bekapcsolása

Az alábbi paraméterekkel konfigurálható, hogy a kérés/válasz logolásban megjelenjen-e a paraméter és a body.

project:
  log:
    http-payload:
      log-request-params: false
      log-request-body: false
      log-response-params: false
      log-response-body: false

1.19.5 Logokból végpontok ignorálása

Az alábbi paraméterekkel konfigurálható, hogy melyik végpontra ne történjen logolás. Alapértelmezetten csak az /actuator/health végpont van megadva, így az erre a végpontra érkező kéréseket nem logoljuk.

project:
  log:
    http-payload:
      endpoints-to-ignore:
        - '/actuator/health'

2. Adatbázisban tárolt konfigurációk

Egyes konfigurációs lehetőségek nincsenek application.yml-be kivezetve, de lehetőség van azok módosítására SQL scriptek segítségével.

2.1 Admin felhasználó jogosultságok

A projekt indulásakor fontos lefektetni, hogy az egyes admin szerepkörökhöz milyen jogosultságok tartozzanak.

Alapértelmezetten az alábbi admin szerepkörök léteznek a SEMI-ben:

• admin (ADMIN)
• szuper admin (SUPER_ADMIN)

A szerepkörökhöz rendelt alapértelmezett jogosultságokat az auth_privilege és az auth_role_privilege táblákból tudjuk kiolvasni.

3. Alkalmazások és funkciók be/kikapcsolása

Wizard Kódtörlő CLI alkalmazás

Amennyiben a funkciókat/alkalmazásokat/csatornákat a Kódtörlő CLI alkalmazással töröljük, az alábbi lépéseket nem szükséges végrehajtani.

Így minden esetben a Kódtörlő CLI alkalmazást használjuk a törléséhez, és csak azon funkciók/alkalmazások/csatornák esetén alkalmazzuk a lenti lépéseket, amelyek a Kódtörlő CLI alkalmazással nem törölhetők.

3.1 Alkalmazások be/kikapcsolása

Adott projekten előfordulhat, hogy nincs szükség az admin, partner stb. alkalmazásokra.

Ilyen esetben az alábbi lépéseket követve tudjuk kikapcsolni a megfelelő alkalmazásokat.

3.1.1 Alkalmazáshoz tartozó összes funkció kikapcsolása

Az alkalmazáshoz tartozó összes funkciót lehetőség van 1 db konfigurációs paraméterrel kikapcsolni.

A kikapcsolás eredményeképp:

• az adott alkalmazáshoz tartozó összes funkció elérhetetlen lesz a kliensek számára,
• a funkciókhoz tartozó konfigurációs fájlok nem lesznek szükségesek az alkalmazás elindításához,
• a funkciókhoz tartozó tesztek nem fognak lefutni.

A fenti pontok mindaddig teljesülnek, amíg az alkalmazást vissza nem kapcsoljuk.

Amennyiben valamely alkalmazást ki szeretnénk kapcsolni, a hozzátartozó enabled paramétert állítsuk false-ra.

project:
  applications:
    admin:
      enabled: true
    client:
      enabled: true
    partner:
      enabled: true

Alkalmazásokhoz tartozó funkciók

A fentiekből következően, ha egy alkalmazást kikapcsolunk, azzal az összes hozzátartozó funkció kikapcsolt állapotba kerül.

3.1.2 Alkalmazáshoz tartozó CI jobok kikapcsolása

Amennyiben kikapcsolunk egy alkalmazást, akkor kapcsoljuk ki az alkalmazáshoz tartozó CI jobokat is.

Ehhez a frontend és backend projekt ci mappájában található fájlokban rakjunk egy . karaktert az alkalmazáshoz tartozó jobok nevének elejére. Ha commitoljuk ezt a módosítást, akkor az ily módon prefixelt jobok nem fognak lefutni.

Továbbá, nézzük végig, hogy más jobok hivatkoznak-e a kikapcsolt jobokra a needs szekciójukban. Amennyiben igen, vagy kapcsoljuk ki a hivatkozó job-ot is, vagy ha úgy ítéljük meg, hogy a hivatkozott job nem szükséges a hivatkozó job futásához, akkor vegyük ki a hivatkozó job needs szekciójából.

Figyeljünk rá, hogy az alábbi fájlok mindegyikében prefixeljük az alkalmazáshoz tartozó jobokat:

• frontend projekt

  • .gitlab-ci-build.yml
  • .gitlab-ci-push-docker-images.yml
  • .gitlab-ci-release-docker-images.yml

• backend projekt

  • .gitlab-ci-release-flow.yml

CI job kikapcsolás példa

Ha a kikapcsolandó alkalmazás a partner alkalmazás, akkor a ci mappában található .gitlab-ci-build.yml fájlban keressük meg a frontend-partner jobot, és írjunk egy . karaktert a job nevének elejére:

.frontend-partner:
  stage: build
  image: docker:latest
  ...
  before_script:
  ...
  script:
  ...
  interruptible: true

3.1.3 Alkalmazáshoz tartozó parancsok törlése a package.json-ból

Amennyiben kikapcsolunk egy alkalmazást, akkor töröljük ki a package.json-ból a hozzátartozó parancsokat is.

Ehhez a frontend projektben található package.json fájlban keressük meg az alkalmazáshoz tartozó parancsokat és töröljük őket.

Figyeljünk rá, hogy vannak parancsok amik minden alkalmazást érintenek, ezeknél NE az egész parancsot, csak a kikapcsolandó alkalmazásra vonatkozó részt törüljük.

Példa

Ha a kikapcsolni kívánt alkalmazás a partner alkalmazás, akkor a build parancsnak a törlés után az alábbi módon kell kinéznie:

{
  ...
  "script": {
    ...
    "build": "npm run build:admin && npm run build:client",
    ...
  },
  ...
}

3.1.4 Alkalmazás eltávolítása a telepítési/üzemeltetési útmutatókból és konfigurációs fájlokból.

Amennyiben kikapcsolunk egy alkalmazást, akkor töröljük a hozzá tartozó telepítési és konfigurációs lépéseket a megfelelő útmutatókból, dokumentációkból és konfigurációs fájlokból.

Az alábbi fájlokat, útmutatókat biztosan frissíteni kell:

• Docker Compose fájlok (docker-compose-services.yml),
• HAProxy konfiguráció (haproxy.cfg),
• DEV/Teszt környezethez tartozó dokumentációk (Tanúsítvány kiállítás, Tesztkörnyezet létrehozás stb.),
• UAT/PROD környezethez tartozó útmutatók (Teljes/Verziónkénti telepítési útmutató stb.),
• Infrastruktúra leírás és diagramok,
• Lokál környezet beállítása dokumentációk.

3.1.5 Alkalmazáshoz tartozó funkció jogosultságok törlése

Amennyiben kikapcsolunk egy alkalmazást, akkor az alkalmazáshoz tartozó összes funkció jogosultságot is töröljük az adatbázisból.

A törlés alatt természetesen azt értjük, hogy egy új changeSet-et hozzunk létre, és abban töröljük a megfelelő privilege-eket az auth_privilege és auth_role_privilege táblákból.

3.2 Funkciók be/kikapcsolása

3.2.1 Funkció kikapcsolása

Feature flag-ek implementálása projekten

Habár a Semi Product alapértelmezetten kikapcsolhatóvá teszi a funkciókat, ez a projektektől nem elvárt a fejlesztés során. Azaz, a projekteknek nem kell azzal foglalkozniuk, hogy az általuk fejlesztett funkciók a lent leírt módon kapcsolhatóak legyenek.

A funkciókat lehetőség van be-, illetve kikapcsolni a projekten.

A kikapcsolás eredményeképp:

• az adott funkció nem lesz elérhető a kliensek számára,
• a funkcióhoz tartozó konfigurációs fájlok nem lesznek szükségesek az alkalmazás elindításához,
• a funkcióhoz tartozó tesztek nem fognak lefutni.

A fenti pontok mindaddig teljesülnek, amíg a funkciót vissza nem kapcsoljuk.

Alkalmazás vs. funkció kikapcsolás

Fontos, hogy ha egy alkalmazást kikapcsoltunk, akkor hiába szerepel az adott alkalmazáshoz tartozó funkciónál az enabled: true érték, a funkció mindaddig ki lesz kapcsolva, amíg az adott alkalmazás nincs bekapcsolva.

Egy funkció csak akkor van bekapcsolt állapotban, ha mind a funkció konfigurációjánál, mind a hozzá tartozó alkalmazás konfigurációjánál enabled: true érték szerepel.

A funkciókat az application.yml fájl project.feature, illetve project.techcore szekciójában lehet be-, illetve kikapcsolni.

Egy funkció kikapcsolásához a megfelelő funkcióhoz tartozó enabled paramétert írjuk át false-ra.

Cron jobok kikapcsolása

A fenti konfigurációból látszik, hogy mind üzleti funkciókat (feature szekció), mind technikai funkciókat (techcore szekció) lehetőség van kikapcsolni.

Ebből következően lehetőség van a projekten nem szükséges ütemezett feladatokat (cron jobokat) is kikapcsolni. Ehhez a project.techcore.cron szekcióban, a megfelelő jobhoz tartozó enabled paraméter értékét írjuk át false-ra.

3.2.2 Funkcióhoz tartozó jogosultságok törlése és megfelelő jogosultságok beszúrása

Amennyiben kikapcsolunk egy funkciót, akkor a funkcióhoz tartozó összes jogosultságot is töröljük az adatbázisból.

Ehhez ad segítséget az src/main/resources/db/changelog/1.0.0/script mappában található insert_auth_roles_and_privileges.sql fájl.

Ebből a file-ból töröljük a nem szükséges role / privilige scripteket.
Szükség esetén hozzá is tudunk inserteket, követve a file-ban található struktúrát.