You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
RPCs are frequently displayed in the clear and can be abused with unauthorized usage. This is especially an issue where the RPC is a communal resource.
Adding the ability to optionally specify an Authorization token in a file would be useful. The kinode user could specify a filename such as my_token.json which could contain the text [{"rpc":"my-rpc.ws-prox-fra1.staging.kinode.net","headers":[{"header":"Authorization","value":"my_secret_token"}]}]. Then launching a kinode with --rpc my-rpc.ws-prox-fra1.staging.kinode.net --rpc-header-file my_token.json would pass the header Authorization: my_secret_token when initiating the web socket connection (this json format would allow the specification of multiple headers for multiple RPCs, but perhaps it would be simpler to assume support only for the RPC specified by --rpc, and then the values would be preserved in .eth_providers for future use). By only referencing file names, the secure information would not be visible in process lists or lists of RPC URLs.
The text was updated successfully, but these errors were encountered:
RPCs are frequently displayed in the clear and can be abused with unauthorized usage. This is especially an issue where the RPC is a communal resource.
Adding the ability to optionally specify an Authorization token in a file would be useful. The kinode user could specify a filename such as my_token.json which could contain the text [{"rpc":"my-rpc.ws-prox-fra1.staging.kinode.net","headers":[{"header":"Authorization","value":"my_secret_token"}]}]. Then launching a kinode with --rpc my-rpc.ws-prox-fra1.staging.kinode.net --rpc-header-file my_token.json would pass the header Authorization: my_secret_token when initiating the web socket connection (this json format would allow the specification of multiple headers for multiple RPCs, but perhaps it would be simpler to assume support only for the RPC specified by --rpc, and then the values would be preserved in .eth_providers for future use). By only referencing file names, the secure information would not be visible in process lists or lists of RPC URLs.
The text was updated successfully, but these errors were encountered: