JSONin lukeminen: erota syntaksi, sopimus ja luottamus

Tiivistelmä

Jäsennin muuntaa JSON-tekstin arvoiksi. Se ei osoita liiketoimintakelpoisuutta, lähettäjän luotettavuutta tai käyttölupaa.

Maailmanlaajuinen verkkokartta tyhjässä tilannehuoneessa
Tässä artikkelissa

Kelvolliset syötteet voivat tarkoittaa eri asioita

JSON voi olla objekti, taulukko tai yksinkertainen arvo. null on kelvollinen, vaikka sopimus vaatisi objektin. Jotkin luvut ylittävät JavaScriptin kokonaislukutarkkuuden; toistuvia ominaisuusnimiä ei tulkita kaikkialla samoin.

EsimerkkisyöteSyntaksin tulkintaJäljellä oleva tarkistus
{"ok":true}Kelvollinen.Täyttääkö arvo sopimuksen?
{"ok":true,}Virheellinen: lopun pilkku.Käsittele virhe nimenomaisesti.
nullKelvollinen.Salliiko sopimus nullin?
{"id":9007199254740993}Kelvollinen luku, tarkkuusriski JavaScriptissä.Käytä tälle tunnisteelle merkkijonoa.
{"a":1,"a":2}Toistuvat nimet: tulkinta ei ole siirrettävä.Määritä ja toteuta hylkäyskäytäntö.

Tarkista vastaanoton jokainen vaihe

  • Käytä ylläpidettyä JSON-jäsennintä, älä evalia. Tarkista HTTP-tila, sisältötyyppi, kokorajat ja puuttuvan tai virheellisen rungon käsittely.
  • Validoi sitten sopimus: juurityyppi, pakolliset kentät, sallitut arvot sekä puuttuvan, nullin ja nollan ero. Säilytä pitkät tunnisteet merkkijonoina sopimuksen niin määrätessä.
  • Aseta syvyys- ja resurssirajat, toistuvien nimien käytäntö ja virheenkäsittely. Älä sijoita vastaanotettuja merkkijonoja HTML:ään tai kyselyihin ilman sopivaa suojausta.

Pidä virheet hyödyllisinä paljastamatta tietoja

Testaa osittaiset vastaukset, versiovaihdot ja Unicode. Lokita vain tarpeellinen konteksti salaisuuksien tai kokonaisten runkojen sijaan. Jäsennysvirhe ei saa muuttua onnistuneeksi tyhjäksi tulokseksi eikä pysäyttää koko ketjua huomaamatta.

Alkuperäiset lähteet

Kirjaa JSON API -virheet ilman vuotavia hyötykuormia.

JSON-runko voi sisältää tunnisteita, salaisuuksia tai henkilötietoja. Diagnoosiin tarvitaan usein tapahtumatyyppi, reitti, tulos, korrelaatiotunniste ja ei-arkaluonteinen vikatieto koko hyötykuoren sijaan.

  • Luokittele kentät ja peitä ne, joita ei tarvita diagnoosissa.
  • Testaa jäsennys- ja skeemavirheitä synteettisillä arvoilla.
  • Tarkista, että virhelokit ja viennit eivät kopioi koko hyötykuormaa.

Ensisijainen lähde: ACSC and partners — Event logging and threat detection. Aiheeseen liittyvä menetelmä: lue käytännön opas.

Personoidut JSON- ja välimuistiavaimet

Lisätarkistuskohta: personoidut JSON- ja välimuistiavaimet. Esitystason käytäntö ja testit, jotka etsivät tilien välisiä vuotoja ja vanhentunutta sisältöä muutosten jälkeen.

  • Valitse säilytys: RFC 9111 erottaa direktiivit: välimuistin estäminen vaatii validoinnin ennen uudelleenkäyttöä, tallennuskielto estää asiaankuuluvan HTTP-tallennuksen ja määrittelemätön yksityinen sulkee pois jaetun tallennustilan. Mikään yksinään ei takaa järjestelmän luottamuksellisuutta.
  • Avainten tarkastus: Tarkista menetelmä, URI ja ulottuvuudet, jotka muuttavat esitystä. Vaihtelee pyyntökenttien osalta; se ei ole valtuutusta. Etsi pois jätettyä kieltä, muotoneuvottelua ja tilin kontekstia sovelluskerroksissa.

Ensisijainen lähde: IETF — RFC 9111, HTTP Caching. Aiheeseen liittyvä menetelmä: lue käytännön opas.

API-sivutus ja johdonmukainen vienti

Muuttuva aineisto voi aiheuttaa puutteita tai toistoja viennissä.

  • Kirjaa suodattimet, järjestys ja tasatilanteen ratkaiseva avain. Selvitä, tarjoaako API tilannekuvan vai muuttuvan kokoelman. Testaa luominen ja poistaminen lukemisen aikana; kursorin olemassaolo ei takaa jäädytettyä aineistoa.
  • AIP-158:ssa tyhjä next_page_token päättää lukemisen, ei lyhyt tai tyhjä tulossivu. Kuvitteellisissa sivuissa [A,B] ja [B,C] on neljä riviä mutta kolme yksilöllistä tunnistetta. Havaitse myös sama kursori ilman etenemistä ja noudata käytetyn API:n sopimusta.
  • Tallenna erä pysyvästi ennen jatkotilan vahvistamista. Toista keskeytynyt erä vakailla tunnisteilla ja tarkista käyttöoikeus jokaisella pyynnöllä; kursori ei ole lupa tietoihin. Jos tilannekuva vanhenee, aloita uudelleen tai täsmäytä määritellyllä tavalla; älä yhdistä eri tiloja hiljaisesti.

Toistettava hyväksyntätapaus

Kuvitteellinen esimerkki: tiedot eivät kuvaa asiakasta tai havaittua tulosta.

Näytä tapauksen tiedot
{
    "page_1_ids": [
        "A",
        "B"
    ],
    "page_2_ids": [
        "B",
        "C"
    ],
    "next_cursor": "c2",
    "empty_page_has_next_cursor": true
}

Odotettu päätös

B toistuu. Tarkista tunnisteet ja seuraa kursoria myös tyhjän sivun jälkeen.

Tarkistusmenettely

  1. Määritä suodattimet, vakaa järjestys ja tunnisteet.
  2. Testaa toisto ja tyhjä sivu jatkokursorilla.
  3. Säilytä tunnisteet ja todellinen loppuehto. Vertaa vastaanotettuja objekteja ja yksilöllisiä tunnisteita; merkitse toistuva kursori tulkitsematta jatkolinkin sisältävää tyhjää sivua keruun lopuksi.

Google AIP-158 — Pagination

Todistaako odotettu rivimäärä viennin täydellisyyden?

Ei. Puuttuva ja toistuva tunniste voivat kumota toisensa määrässä. Vertaa tunnisteita, rajausta ja katkaisuaikaa sekä kirjaa ratkaisemattomat erot.

Ensisijainen lähde: Google AIP-158 — Pagination. Aiheeseen liittyvä menetelmä: lue käytännön opas.