Make clear which RPC methods are safe/unsafe

[bkchr]

It would be nice to have some sort of list that says which RPC methods are safe or unsafe to make it easier for the user.

Maybe this could be exposed using the RPC that lists all available RPC calls?

CC @Xanewok

[AurevoirXavier]

Really need this. Thanks.

[stale]

Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions.

[mario-sangar]

This would be awesome to track what methods are unsafe. Right now is kind of hidden in the code which methods are unsafe... Do you know when this could go in?

[tomaka]

Maybe this could be exposed using the RPC that lists all available RPC calls?

The rpc_methods RPC call returns the list of all RPC calls that are supported.
But instead of modifying rpc_methods to add, say, a new field, I would suggest instead to make rpc_methods only return safe methods if the node is configured to allow only safe methods, and safe+unsafe methods if the node is configured allow both.

[tomaka]

The proper solution IMO, however, is to document this list on a website, rather than use Substrate's source code as the reference point

[ToufeeqP]

Any progress on this?

[kianenigma]

@the-right-joyce addding this to SDK node, please remove if off topic.

[jamesbayly]

Throwing some more weight into this, we'd like to start allowing access to certain unsafe methods for our customers, but without being able to easily determine which methods are unsafe, we can't build an allowlist (without exposing everything).

In addition, we can autogenerate documentation using this RPC that lists all available RPC calls as nodes run in safe mode show all safe and unsafe RPC calls. This API isn't really telling the truth for a node run in safe mode.

A simple boolean property would suffice

[kianenigma]

I am not in the weeds but it sounds to me like a fairly simple fix. I am surprised we don't have this already.

[jamesbayly]

@kianenigma would you be able to give any indication if this can be added, and if so, any idea on the timeline?

[sourabhniyogi]

For indexing, it would be very useful to have the rpc_methods return which methods are "safe" vs "unsafe" and similarly for ws [for our own indexing we check for subscribeStorage availability on public endpoints, and use "unsafe" state_traceBlock a lot] -- We have found many public ws endpoints differ slightly on subscribeStorage for mysterious reasons and this would help.

Even more importantly, we request support for some form of permissioning beyond the overly permissive options of "allow ALL unsafe calls on rpc/ws port" vs overly restrictive "deny ALL unsafe calls on rpc/ws port".

Specifically, full archive nodes should be able to expose their "unsafe" RPC/WS calls to permissioned entities in the "allowlist" model that @jamesbayly suggests -- could be by IP, putting unsafe calls on another port, a HTTP header, some whitelisted apikeys. Out of these options, there may be better options for node operators that need to meter and rate limit here. Not having this form of permissioning required one node type which is "allow ALL unsafe" and another node which is "deny ALL unsafe", which doesn't make sense.

[dcolley]

Could we at least decorate methods so the https://polkadot.js.org/docs/ site has this?

[jamesbayly]

Would be very useful just to have some decoration here