Autentiserte revisjoner

Gjenbruk en beskyttet testøkt

En testøkt er en navngitt autentiseringslegitimasjon som er lagret for ett bekreftet domene. Fullstendige og tilpassede sikkerhetsrevisjoner kan gjenbruke den, slik at du ikke trenger å gjenopprette eller lime inn hemmeligheten for hver kjøring. lette sikkerhetsrevisjoner forblir alltid offentlige.

VICE krypterer lagrede hemmeligheter. Bare verifiserings- og revisjonsprosesser bruker dem. Passordet ditt er aldri nødvendig.

Lagrede økter forblir med det bekreftede domenet og kan søkes, redigeres, roteres eller tilbakekalles.

• Opprett opptil fem økter per bekreftet domene.
• Velg en utløpstid fra én time til tretti dager.
• Påloggingsopplysninger forblir på det verifiserte nettstedet eller i det nøyaktige Supabase-prosjektet som er konfigurert for økten.

Velg autentiseringsmetoden

Bruk samme metode som en vellykket påloggingsforespørsel allerede bruker. Åpne applikasjonen din med en dedikert testkonto, og inspiser deretter en beskyttet forespørsel i nettleserutviklerverktøy før du oppretter økten.

Inspiser en vellykket forespørsel med samme opprinnelse og kopier bare autentiseringsverdien som kreves av den valgte metoden.

• Supabase-autentisering
• Bearer token: forespørselen inneholder en Authorization header hvis verdi starter med Bearer.
• Cookie header: nettleseren autentiserer forespørselen med en eller flere førsteparts informasjonskapsler.
• Tilpasset overskrift: applikasjonen bruker en annen overskrift som x-api-key eller x-auth-token.

Skaff deg et Bearer-token

Et Bearer-token er et hemmelig tilgangstoken: ethvert system som har et gyldig token kan presentere det for serveren. Det er ofte et JWT, men ikke alle Bearer-tokener bruker JWT-formatet. Behandle hele verdien som en passord-ekvivalent hemmelighet.

Logg på med den dedikerte testkontoen, åpne Developer Tools > Nettverk, last inn en beskyttet side på nytt og velg en forespørsel med samme opprinnelse som bare lykkes mens du er pålogget. Under Overskrifter > Request Headers, se etter Authorization: Bearer etterfulgt av token.

• VICE godtar brukertokenet med eller uten Bearer-prefiks.
• Hvis ingen Authorization-overskrift vises, autentiserer programmet sannsynligvis med informasjonskapsler eller en egendefinert overskrift i stedet.

1Observed request
2Authorization: Bearer eyJhbGciOi...
3 
4Paste into VICE
5eyJhbGciOi...

Supabase-autentisering

Hvis applikasjonen bruker Supabase-pålogging, velger du Supabase Auth. Et Bearer-token alene gjenoppretter kanskje ikke nettleserøkten.

Logg inn med en testkonto. Åpne Application > Local Storage eller Session Storage i nettleserens utviklerverktøy. Kopier JSON-verdien for sb-<project-ref>-auth-token under nettstedet ditt til det valgfrie feltet for øktimport.

Bruk en offentlig eller eldre anon-nøkkel. Secret- og service-role-nøkler avvises.

• Tilgangstokenet identifiserer kontoen; fornyelsestokenet fornyer økten. Kopier begge fra samme pålogging, aldri bare feltnavnene.
• VICE fyller inn begge tokenene og finner prosjektets URL. Legg til den offentlige nøkkelen fra Supabase-innstillingene. Bruk Skriv inn tokener manuelt bare hvis du ikke kan importere økten.
• Bruk en privat side på nettstedet ditt, ikke Supabase-API-et. Utlogging eller tilbakekalt tilgang kan ugyldiggjøre økten før utløpet i VICE.

Skaff en Cookie header

En økt-informasjonskapsel er et navn-verdi-par som nettleseren sender til applikasjonen etter pålogging. En forespørsel kan bruke flere informasjonskapsler, men revisjonen skal kun motta førsteparts sesjonskapsler som er nødvendige for autentisering, ikke analyse- eller reklameinformasjonskapsler.

I Developer Tools, inspiser en vellykket beskyttet forespørsel under Nettverk > Overskrifter > Request Headers og kopier Cookie-verdien. Du kan også inspisere Application > Storage > Cookies for å identifisere den relevante førsteparts sesjonsinformasjonskapselen, inkludert en HttpOnly informasjonskapsel som applikasjonen JavaScript ikke kan lese.

• Lim inn bare navn=verdipar atskilt med semikolon.
• Ikke ta med Cookie: overskriftsnavnet.
• Ha domenet og banens omfang i tankene; en informasjonskapsel som tilhører en annen vert kan ikke autentisere den bekreftede opprinnelsen.

1Observed request
2Cookie: session=abc123; refresh=def456
3 
4Paste into VICE
5session=abc123; refresh=def456

Skaff en egendefinert autentiseringsoverskrift

Noen applikasjoner autentiserer API-forespørsler med en produktspesifikk overskrift i stedet for Authorization eller Cookie. Inspiser en vellykket beskyttet forespørsel i Nettverk > Overskrifter > Request Headers og identifiser den stabile overskriften som har legitimasjonen.

• Skriv inn overskriftsnavnet separat, for eksempel x-api-key eller x-auth-token.
• Lim inn bare den rå overskriftsverdien i det hemmelige feltet, uten overskriftsnavn eller kolon.
• Ikke bruk ruting- eller transporthoder som Host, Origin, Referer, Connection, Content-Length, Transfer-Encoding eller Proxy-Authorization.

1Observed request
2x-auth-token: test_abc123
3 
4Header name in VICE
5x-auth-token
6 
7Secret in VICE
8test_abc123

Side etter innlogging

Du kan la dette feltet stå tomt. VICE ser automatisk etter en privat side ved å følge koblinger og omdirigeringer på nettstedet ditt, og sjekker det deretter med og uten testøkten. En side som ble funnet, huskes, men tilgangen kontrolleres på nytt før hver revisjon.

Hvis VICE ikke finner en side som beviser privat tilgang, velger du Velg en side manuelt i sjekkresultatet, eller åpner Avanserte innstillinger og fyller ut Side tilgjengelig etter pålogging. Eksisterende lagrede sideadresser beholdes; tøm feltet for å bytte til automatisk registrering.

Dette er en eksisterende side i appen din som krever pålogging, for eksempel kontoområdet eller dashbordet. VICE åpner den samme siden med og uten testøkten din for å sjekke at den virkelig gir tilgang til det private området.

Logg på applikasjonen din med testkontoen, åpne en privat side som denne kontoen har tilgang til, og kopier den endelige adressen fra nettleserens adresselinje. Lim inn den adressen på siden tilgjengelig etter pålogging. For eksempel https://app.example.com/dashboard eller bare /dashboard. Erstatt dette eksemplet med den faktiske sideadressen din og behold de samme store og små bokstavene.

Åpne den samme adressen i et privat nettleservindu uten å logge på. Det bør be deg om å logge på eller nekte tilgang til det private området. Hvis den viser det samme private innholdet, velger du en annen side. Hold det opprinnelige testkontovinduet pålogget: avlogging kan ugyldiggjøre økten du kopierte.

La siden stå tom for automatisk gjenkjenning, eller skriv inn en privat side under Avanserte innstillinger.

• Bruk det nøyaktige nettstedet som er lagret som domene i VICE. For et testmiljø, bruk adressen, ikke produksjonsnettstedet. Med Supabase Auth, bruk søknadssiden din, ikke Supabase dashbordet eller API URL.
• Ikke bruk påloggingssiden, en offentlig hjemmeside, en pålogging callback eller en engangspåloggingslenke. Ikke ta med et symbol eller annen hemmelighet i adressen.
• Velg en side som er trygg å åpne: Å se den må ikke opprette, slette, kjøpe eller sende noe.
• Du trenger ikke å opprette en spesiell side eller endre koden. Denne siden er tilgangskontrollen og et inngangspunkt for oppdagelse, ikke den eneste siden revisjonen kan inspisere.
• Bekreftelsestekst under Avanserte innstillinger er valgfri. Om nødvendig, skriv inn en stabil etikett som allerede er synlig etter pålogging, for eksempel kontoinnstillinger. Ikke legg til ny tekst i applikasjonen din eller bruk navn, e-postadresse eller endringsverdi. For å fjerne tidligere lagret bekreftelsestekst, merk av for fjerning; ved å la feltet stå tomt beholdes det.
• Et gyldig Supabase-token garanterer ikke tilgang til applikasjonen din: testkontoen kan fortsatt mangle en rolle eller tilgang til et arbeidsområde. En mislykket sidesjekk betyr ikke nødvendigvis at tokenet har utløpt.

Lagre og kontroller tilgang

Lagre og kontroller tilgang lagrer økten og sammenligner siden med og uten den. Denne gratis kontrollen kan vente på en ledig prosess. Ved feil forblir økten lagret og redigerbar.

Verifisert tilgang bekrefter en forskjell på denne siden, ikke full dekning av applikasjonen. Resultatet forklarer feilen: tilbake til pålogging, manglende bekreftelsestekst, offentlig side eller utilgjengelig tilkobling.

Kontrollen bruker ingen revisjonskreditter.

Velg økten for en revisjon

Fra domeneoversikten eller revisjonssiden velger du Start revisjon. Velg Full eller Egendefinert, bytt programtilgang til testøkt, og velg en aktiv navngitt økt fra rullegardinmenyen.

Velg en lagret økt kun for full eller tilpasset dekning som trenger beskyttede ruter.

• lette sikkerhetsrevisjoner bruker ikke en testøkt.
• Revisjonen lagrer den valgte øktreferansen i stedet for å kopiere hemmeligheten inn i revisjonshistorikken.
• Hver revisjon kontrollerer tilgangen på nytt. Hvis den ikke verifiseres, stopper sikkerhetskontrollene og reservert kvote eller kreditt tilbakeføres. Velg Offentlig overflate for å revidere uten økt.

Roter eller tilbakekall økten

Bruk blyantikonet under Domeneinnstillinger > Testøkter for å gi nytt navn til økten, justere dens beskyttede bane eller markør, rotere legitimasjonen eller tilbakekalle den.

• La Ny sesjonshemmelighet være tom for å beholde den krypterte legitimasjonen og gjeldende utløp.
• Oppgi en ny hemmelighet for å rotere legitimasjonen og bruke en ny utløpsdato.
• Fjern økt åpner en bekreftelsesdialog og tilbakekaller økten umiddelbart.