Guida alla versione preliminare · 0.1.0
Autorità su sorgenti e client
Comprendi le decisioni separate che permettono al client di richiedere lavoro e allo scanner di leggere sorgenti.
Il riferimento API è in inglese.
Connessione editor, radice autorizzata e repository protetto approvato rispondono a domande diverse. CodeSecurity verifica ciascuna al confine pertinente. Nome di progetto o percorso inviati dal client non autorizzano accesso da soli.
Separa le decisioni del proprietario
Autorità del client
- Sessione browser
Sessione HttpOnly associata; le modifiche richiedono anche Origin e valore CSRF esatti.
- Capacità IDE
L’approvazione lega profilo e generazione di autorità previsti.
Ammissione delle richieste
- Controlli di route e proprietà
Il client deve soddisfare scope della route e controlli specifici.
- Autorizzazione dei sorgenti
Un’azione esplicita del proprietario espone solo radici ristrette verificate o snapshot supportati.
Protezione del repository
- Approvazione come membro
La generazione editor prevista riceve il permesso per il repository esatto.
- Applicazione sull’host
Apply esplicito cambia il clone locale; richiedere uno stato non lo installa.
Connessioni
Sessione browser a Controlli di route e proprietà
L’appartenenza browser non aggira i controlli di proprietà delle operazioni.
Capacità IDE a Controlli di route e proprietà
È ammesso solo l’elenco esatto delle capacità consentite.
Controlli di route e proprietà a Autorizzazione dei sorgenti
Selezionare o registrare non concede da solo accesso ai sorgenti host.
Controlli di route e proprietà a Approvazione come membro
L’appartenenza IDE ordinaria non concede il permesso di membro del repository.
Approvazione come membro a Applicazione sull’host
L’impostazione approvata richiede ancora applicazione esplicita al clone previsto.
| Decisione | Cosa permette | Cosa resta separato |
|---|---|---|
| Autenticazione browser | Usare il controllo locale entro il confine della sessione | Le richieste non sicure richiedono origine permessa e protezione CSRF. |
| Appartenenza IDE | Usare le route degli scope e della generazione attiva della capacità | Workspace Trust, accesso ai sorgenti e approvazione della protezione. |
| Workspace Trust | Consentire azioni editor supportate nel workspace | Un mount più ampio o l’approvazione di un nuovo proprietario. |
| Autorizzazione della radice | Montare una radice esistente e ristretta in sola lettura | Registrazione del progetto e ambito di ogni scansione. |
| Ammissione snapshot | Conservare una generazione limitata con identità verificata | Accesso arbitrario all’host o esecuzione del codice caricato. |
| Approvazione protezione Git | Permettere alla generazione approvata esatta di gestire il repository scelto | Prova dell’hook applicato, evidenza attuale del push o applicazione lato server. |
Autorità browser ed editor possono essere revocate separatamente. Le richieste IDE sono verificate contro scope esatti e generazione attiva. L’API non è un servizio generico di chiavi API. La guida all’autenticazione spiega il flusso supportato.
Il confine valida anche Host e Origin e rifiuta credenziali negli URL. Autenticare non sostituisce controlli di proprietà specifici. Consulta middleware di sicurezza e autorizzazione IDE.
I sorgenti montati sono un confine esplicito dell’host
Nei flussi POSIX e Remote WSL supportati, il proprietario sceglie radici esistenti ristrette. L’helper canonicalizza e rifiuta radici ampie, forme insicure e valori non serializzabili letteralmente nell’ambiente Compose. Ammette al massimo 32 radici distinte. Compose non crea un’origine bind mancante per soddisfare la richiesta.
L’API non monta sorgenti dei progetti. L’anteprima verifica se il percorso rientra nell’autorità configurata e decide senza creare progetto o job. La creazione registra quell’identità. All’esecuzione lo scanner verifica indipendentemente il percorso reale e usa letture vincolate; non considera il controllo lessicale API prova di accesso sicuro.
Scansioni di file e directory restano nel repository autorizzato. Lo scanner valida il target e acquisisce la vista per gli strumenti. Una richiesta non trasforma la selezione di una directory in permesso fuori dalla radice.
I punti d’ingresso sono validazione delle radici, anteprima e creazione progetto e letture relative a descrittori.
Gli snapshot trasportano sorgenti, non mount più ampi
I flussi Windows nativi supportati e gli alberi Git immutabili usano lo store dedicato. L’API valida percorsi, conteggi, dimensioni e identità prima di pubblicare una generazione sigillata. La scansione deve indicare il digest atteso esatto; un progetto con sorgenti montati non può sostituirlo silenziosamente con uno snapshot caricato.
| Limite | Implementazione fissata |
|---|---|
| Payload snapshot | Fino a 5.000 file, 8 MiB per file e 64 MiB di sorgenti. |
| Generazioni conservate o interrotte | Fino a 256. |
| Inventario dello store | Fino a 65.536 voci e 64 livelli di directory. |
| Storage aggregato | Fino a 2 GiB, contando allocazione filesystem e metadati. |
| Spazio libero per l’ammissione | Nuova allocazione più una riserva aggiuntiva di 2 GiB. |
Pubblicazione ed eliminazione esplicita condividono un lock privato che non segue link. Un writer concorrente riceve snapshot_storage_busy; storage insicuro o illeggibile snapshot_storage_unavailable; capacità esaurita snapshot_storage_full. Non viene accodato un tentativo nascosto né eliminata automaticamente evidenza vecchia.
Una generazione sigillata identica viene validata e riusata senza altra copia, anche quando nuove scritture non sono ammesse. Una pubblicazione interrotta consuma ancora il budget. Sono eliminabili soltanto generazioni corrispondenti esaminate esplicitamente. Altri processi consumano disco, quindi i limiti locali non garantiscono che non si riempia mai.
Consulta ammissione snapshot e contratto di storage. Acquisizione e limite minore di analisi del testo idoneo sono distinti, come spiega il capitolo scansioni.
Lega la navigazione all’evidenza corrente
Il percorso di un rilievo è evidenza, non un ordine di aprire file arbitrari. I comandi d’apertura legano generazione IDE scelta, revisione del rilievo e revisione della raccolta. Destinatari obsoleti o ambigui richiedono riconciliazione.
I rilievi di alberi committati hanno un limite più stretto: l’API rifiuta di aprire un file corrente presumendolo equivalente. Il working tree può differire dallo storico che produsse il rilievo. Esamina il dettaglio acquisito. Il rifiuto è esplicito nei comandi sorgente IDE.
Conserva il confine nelle integrazioni
Usa sessioni browser o autorità IDE supportate e verifica anche la proprietà della risorsa. Non ampliare radici per risolvere una capacità obsoleta, scambiare anteprima per scansione completata o dedurre qualifica nativa di piattaforma dall’esistenza degli snapshot. Il comportamento reale richiede evidenza di sorgenti, immagine e client esatti usati.