refactor(state): CoreAccessor restricts writes on fraud
#1258
Conversation
…in middleware instead of IsStopped
renaynay
added
area:state
renaynay
requested review from
Wondertan,
vgonkivs and
distractedm1nd
as code owners
renaynay
changed the title
CoreAccessor restricts writes on fraud
| // ReadOnly checks if the Module has disabled write access | ||
| ReadOnly() bool |
There was a problem hiding this comment.
Our module interfaces are soon to be used by the RPC. This means that all the methods are exposed over RPC. This type of hack is not aligned with that. Also, note that this ReadOnly is only used by the middleware, but not in the case we use the module interface directly as a lib, which we defined as the main use case.
I recommend closing this PR and revisiting this issue later once the RPC work is done(edit: preventing users from sending PFDs during a fraud is not a biggest security concern and thus is not the biggest priority)
Also note that current "RPC/API" endpoints will become a gateway soon, which means all the endpoints should become read-only by default, and sending tx transactions from the node's key through the key must be forbidden. (We should thought allow sending already signed transactions later through gateway)
|
New solution is needed for new RPC design. |
This PR refactors
CoreAccessorsuch that it contains a field that determines whetherCoreAccessoris read-only:RestrictWrites()method on core accessor (and state module) that gets called from fraud lifecycle in the case of fraud instead of calling stopReadOnly()on state module to check if state is read-only, and if so, restricts POST endpointsCoreAccessorStopmethod now returns an error if stop is called twice (as it is now no longer expected).Resolves #1235
Tagging as a bug-fix as this is technically fixing a bug in specified behaviour.