> For the complete documentation index, see [llms.txt](https://docs.ecommerce.seb.ee/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ecommerce.seb.ee/seb-docs-draft/seb-docs-public-lv/integracija/api-klienta-sdk/celvezi/drosibas-mehanismi.md). # Drošības mehānismi Nodrošiniet SDK integrāciju drošību ar OAuth, JWE šifrēšanu, webhook aizsardzības mehānismiem un reģistrēšanas vadību. > Melnraksts · SDK alfa versija. Attiecas uz visām četrām valodām; atšķirības ir norādītas pie katras valodas. Ar atzīmi **\[TBC]** joprojām vēl jāiesniedz pirms publicēšanas. Šajā lapā aprakstīti trīs drošībai jutīgie mehānismi, ko SDK paveic jūsu vietā — OAuth 2.0 autentifikācija, JWE kartes datu šifrēšana un webhook paziņojumi — un tas, kas jums **ne** jāpielāgo ap tiem. ## Autentifikācija SDK autentificējas ar **OAuth 2.0 klienta akreditācijas datiem**. Jūs, veidojot klientu, norādāt klienta ID un klienta slepeno atslēgu; viss pārējais ir automātiski: * Piekļuves tokens tiek iegūts **pēc vajadzības** pirmajā API izsaukumā un **kešots atmiņā**. * Tokens tiek proaktīvi atjaunots aptuveni 30 sekundes pirms tā `expires_in` derīguma termiņa beigām. Atsvaidzināšanas tokeni netiek izmantoti. * Jūs nekad pats neapstrādājat tokenu, un SDK nekad neraksta akreditācijas datus vai tokenus savā žurnālā. Kas jums jādara: * Glabājiet klienta slepeno atslēgu vides mainīgajā vai slepeno datu krātuvē. **Nekad to necommitojiet, nekad nereģistrējiet to žurnālā.** * Atkārtoti izmantojiet vienu klienta instanci; katra jauna instance iegūst savu tokenu. Ko SDK nedara: tas nemēģina atkārtot pieprasījumu, kas darba gaitā izgāžas ar HTTP 401. Tokena derīguma beigas tiek sekotas lokāli, tāpēc tas notiek tikai tad, ja akreditācijas dati tiek atsaukti vai ja pulkstenis nobīdās; izsaukums parāda kļūdu, un nākamais izsaukums pēc lokālā derīguma beigām iegūst jaunu tokenu. ## Kartes datu šifrēšana (JWE) Kad izveidojat **kartes checkout sesiju**, kartes dati (`cardNumber`, `csc`, `expiry`, `cardholderName`) nekad netiek nosūtīti kā atklāts teksts. SDK tos šifrē JWE **kompaktajā serializācijā** (RSA-OAEP-256 atslēgas šifrēšana, A256GCM satura šifrēšana), izmantojot **publisku RSA atslēgu JWK formātā** kas tiek automātiski izgūta no EGW atslēgu galapunkta. No jūsu puses nekas nav jāinstalē vai jāmaina — bet šifrēšana ir **jūsu skaidri veicamais solis** veidojot pieprasījumu: **Java** (būvētāja palīgs serializē un šifrē vienā solī): ```java var request = CreateCardCheckoutSessionRequest.builder() .encryptedCard(client, data -> data.card(c -> c .cardNumber("4111111111111111") .csc("123") .expiry(e -> e.month("12").year("30")) .cardholderName("JOHN DOE"))) .build(); var session = client.cardSessions().createCardCheckoutSession(paymentId, request); ``` **C# / PHP / Node.js:** izveidojiet nešifrētu datu objektu, šifrējiet ar `client.EncryptToJweCompact(...)` / `$client->encryptToJweCompact(...)` / `await client.encryptToJweCompact(...)`, un iestatiet rezultātu kā pieprasījuma `encryptedCard` lauku. Noteikumi: * **Nekad** nelieciet nešifrētos kartes laukus nekur citur pieprasījumā, savos žurnālos vai krātuvē. JWE virkne ir vienīgais kartes datu artefakts, kas iziet no jūsu procesa. * Nekrājiet šifrēšanas atslēgu vai JWE izvadi starp maksājumiem; šifrējiet katrai sesijai. * Tikai C#: konfigurējiet JWK galapunktu (`EncryptingWith(...)`) izveides laikā — bez tā šifrēšanas izsaukumi nekavējoties izgāžas, nevis nosūta nešifrētus datus. Node.js: `jwkUri` ir obligāts konfigurācijas lauks. ### Atslēgu izvēles un rotācijas politika Šī ir **normatīvā politika** visiem API Client SDK. Šifrējot SDK izvēlas izmantojamo atslēgu, 1. ņemot tikai atslēgas ar `use=enc` un `kty=RSA`; 2. izslēdzot atsauktās atslēgas; 3. izvēloties to, kurai ir jaunākais `iat`; 4. **atkārtoti izvērtējot to katrā šifrēšanā** — izvēlētā atslēga nekad netiek kešota starp operācijām. Atkārtota izvērtēšana katru reizi ir apzināta: tas nozīmē, ka servera puses atslēgas rotācija stājas spēkā nekavējoties, bez restartēšanas un bez novecojušas atslēgas kļūdām. > ⚠️ **PHP, C# un Node.js vidē periodiski izveidojiet klientu no jauna — pretējā gadījumā servera puses atslēgas rotācija pārtrauks ilgdzīvojošus procesus.** Šie trīs SDK šobrīd kešo pirmo atslēgu, ko tie izgūst, visā klienta darbības laikā, nevis pārvērtē to katrai šifrēšanai, un C# papildus ņem `keys[0]` bez filtrēšanas pēc `use` vai `kty` un stingri nosaka RSA-OAEP-256. Java pilnībā ievieš šo politiku; pārējās trīs tiks saskaņotas ar to pirms izlaišanas. ## Webhook paziņojumi EGW var sūtīt maksājuma statusa paziņojumus uz HTTPS galapunktu, ko jūs publicējat. SDK palīdz tos saņemt un apstrādāt: * **Java / PHP / C#** — iebūvēts klausītājs: konfigurējiet `listeningAt(...)` / `ListeningOn(...)` fabrikā, pēc tam reģistrējiet apstrādātāju: ```java client.notifications().receiveNotifications(notification -> { // notification.getType(), notification.getPaymentId(), notification.getPaymentStatus() }); ``` Klausītājs atbild ar **HTTP 200** kad jūsu apstrādātājs pabeidz darbu, un ar **HTTP 500** ja tas met izņēmumu (tad EGW var atkārtoti piegādāt). Turiet apstrādātājus ātrus un idempotentus. * **Node.js** — nav iebūvēta klausītāja: publicējiet galapunktu savā HTTP serverī un deserializējiet pamattekstu ar `client.notifications().parseWebhook(payload)`. ### Paziņojumu autentiskums > ⚠️ **Pirms rīkojaties pēc paziņojuma, vienmēr apstipriniet stāvokli, izmantojot API — nekad nesūtiet preces, neveiciet norēķinu un neatjauniniet pasūtījumu, balstoties tikai uz webhook pamattekstu.** Saņemot maksājuma paziņojumu, izsauciet `getPaymentInformation(paymentId)` (autentificētu) un rīkojieties pēc šīs atbildes. Iemesls: platforma neparaksta paziņojumu datu paketes un nepiedāvā galapunkta autentifikāciju (nav mTLS, nav pamata autentifikācijas, nav koplietota slepenā koda), tāpēc SDK nav ko pārbaudīt, un ikviens, kas var sasniegt jūsu galapunktu, var nosūtīt pareizi noformētu paziņojumu. Uztveriet katru paziņojumu kā neuzticamu norādi, nekad kā faktu — API apstiprinājums ir vienīgā kontrole starp viltotu POST un izpildītu pasūtījumu. Palaidiet klausītāju aiz reversa starpniekservera, kas noslēdz HTTPS. Iebūvētie klausītāji (Java/PHP/C#) izmanto parastu HTTP — Java klausītāja noklusējums ir ports 80. Nepakļaujiet klausītāja portu tieši internetam; novietojiet priekšā starpniekserveri, lai tas noslēgtu TLS un pārsūtītu uz klausītāju iekšējā tīklā. Tālāk piemērojiet savas organizācijas standarta drošības kontroles publiski pieejamam galapunktam. Paziņojumu notikumu tipu katalogs: **\[TBC — link]** ## Žurnālošana Noklusējuma žurnālierakstītājs visās valodās ir kluss no-op — drošs pēc noklusējuma. Ja pievienojat īstu žurnālierakstītāju: * SDK nekad neieraksta žurnālos akreditācijas datus, tokenus vai kartes datus. * Apstrādājiet SDK ERROR žurnālus tā, it kā tie saturētu maksājumu metadatus, un nepārsūtiet tos uz sistēmām, kurām no tiem jāpaliek brīvām. Pie HTTP 4xx/5xx atbildēm SDK reģistrē neapstrādāto kļūdas atbildes pamattekstu ERROR līmenī, bez maskēšanas, un kļūdu pamatteksti var saturēt pasūtījuma norādes, summas un klientam redzamus ziņojumus. Šis ir zināms alfa ierobežojums, nevis paredzēta darbība — maskēšana ir plānota, bet vēl nav ieviesta. * Izņēmumu ziņojumi no neveiksmīgiem tokenu pieprasījumiem ietver autentifikācijas servera atbildes pamattekstu. Apstrādājiet un reģistrējiet izņēmumus ar tādu pašu piesardzību. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.ecommerce.seb.ee/seb-docs-draft/seb-docs-public-lv/integracija/api-klienta-sdk/celvezi/drosibas-mehanismi.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.