Restrict `capabilities.publish` to account's own capabilities
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 25/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Ferma
- Ambito
- blockchain
Direzione di ricerca
Inizia con la discussione precedente in onflow/cadence#2768 e con il Draft PR #2782 collegato, quindi leggi FLIP PR #197 sulla restrizione proposta delle capabilities. Confronta il comportamento attuale con la proposta e determina se la pubblicazione debba essere limitata alle capabilities possedute dall’account. Il lavoro è completato quando la proposta è risolta e l’implementazione o la specifica associata è allineata.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Currently it is possible to republish someone else's capability via new capabilities API, I think it makes sense to keep old restriction.
There are a lot of scenarios ( voting, gating with existence of NFT ) usually checking if account owns some balance or resource, by checking a public path capability. Now it will be extra burden for developers and small foot gun with this change of behaviour.
FLIP suggests adding a restriction to the capability API, permitting only capabilities from the same account address to be published via capabilities.publish.
Previous Discussion: https://github.com/onflow/cadence/issues/2768
Draft PR: https://github.com/onflow/cadence/pull/2782
FLIP Discussion: https://github.com/onflow/flips/pull/197
- Lingua principale
- Nessun dato sulla lingua
- Stelle
- 26
- Fork
- 22
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di onflow/flips
-
FLIP 370: Execution effort calibration IIIForse di nuovo libera @janezpodhostnik l’ha presa 119 giorni fa e non c’è nessuna pull request aperta. Apertaflip: protocol
-
FLIP: Remove unresponsive Lilico verification node from approved listForse già presa @vishalchangrani l’ha presa 167 giorni fa. Apertaflip: governance
-
FLIP 359: Allow for-in loop over dictionary keysForse di nuovo libera @turbolent l’ha presa 232 giorni fa e non c’è nessuna pull request aperta. Apertaflip: cadence
-
FLIP 357: Add Comparison Functions to CadenceForse di nuovo libera @turbolent l’ha presa 248 giorni fa e non c’è nessuna pull request aperta. Apertaflip: cadence
-
FLIP 355: Cadence Guard StatementForse di nuovo libera @turbolent l’ha presa 251 giorni fa e non c’è nessuna pull request aperta. Apertaflip: cadence
Tutte le issue di onflow/flips
Issue simili
-
enhancement frontend good first issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
-
bug performance
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
bridgelet-org/bridgelet-sdk#874 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Residual: whitespace `InferenceUrl` overwrites a live oneForse già presa Una pull request collegata a questa issue è aperta o già unita. Apertaenhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
I maintainer di solito rispondono entro 1 giorno
-
documentation good first issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
Novatip/novatip-contracts#145 ·
-
[Contract] withdraw() uses plain subtraction for the recipient balance instead of checked arithmeticApertabug code-quality contract
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
OlaGreat/NovaSupport#1375 ·
I maintainer di solito rispondono entro 1 giorno