.conf RPC Authorization
.conf RPC Authorization
When installing Namecoin Core and e.g. NMControl for the first time NMControl fails silently because by default there is no namecoin.conf file. It will also fail if there are no RPC credentials in the conf file.
How can we deal with this in a secure yet comfortable manner? Should NMControl ask the user if it is allowed to create/extend the .conf file?
How can we deal with this in a secure yet comfortable manner? Should NMControl ask the user if it is allowed to create/extend the .conf file?
Re: .conf RPC Authorization
We should refer the user to Namecoin Core documentation about namecoin.conf.phelix wrote:When installing Namecoin Core and e.g. NMControl for the first time NMControl fails silently because by default there is no namecoin.conf file. It will also fail if there are no RPC credentials in the conf file.
How can we deal with this in a secure yet comfortable manner? Should NMControl ask the user if it is allowed to create/extend the .conf file?
If the file is missing (and not in a custom location, like in my case), then the user should be reminded to create one or tell NMControl where the file is (if the ability to specify -conf-file=location is provided in NMControl).
NMControl should treat namecoin.conf as external dependency and not try to create or find it in other locations except the default location.
Re: .conf RPC Authorization
That would be cleaner but also less comfortable. Maybe someone who waits two hours to download the blockchain can also create a .conf file but I see it somewhat in the way of a one click installer.somename wrote:We should refer the user to Namecoin Core documentation about namecoin.conf.phelix wrote:When installing Namecoin Core and e.g. NMControl for the first time NMControl fails silently because by default there is no namecoin.conf file. It will also fail if there are no RPC credentials in the conf file.
How can we deal with this in a secure yet comfortable manner? Should NMControl ask the user if it is allowed to create/extend the .conf file?
If the file is missing (and not in a custom location, like in my case), then the user should be reminded to create one or tell NMControl where the file is (if the ability to specify -conf-file=location is provided in NMControl).
NMControl should treat namecoin.conf as external dependency and not try to create or find it in other locations except the default location.
-
- Posts: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
Re: .conf RPC Authorization
This is not in practice a problem. For reading names, you can use Namecoin Core's REST API, which doesn't need a password. For things that need RPC, Namecoin Core 0.12 and higher have cookie authentication (very similar to how Tor handles authentication). The only time you need a manual RPC password is when the thing you want to do isn't available via REST (i.e. wallet methods) and the calling program doesn't have access to Namecoin Core's auth cookie file. I can imagine cases where this is true (maybe a wallet script and Namecoin Core are in separate VM's), but it definitely isn't the case for the default Windows installation of a hypothetical bundle of Namecoin Core and NMControl/ncdns.
For reference: to enable the REST API, pass "-rest" to Namecoin Core. To enable RPC for Namecoin-Qt, make sure that namecoin.conf has "server=1" in it. RPC is enabled by default in namecoind.
For reference: to enable the REST API, pass "-rest" to Namecoin Core. To enable RPC for Namecoin-Qt, make sure that namecoin.conf has "server=1" in it. RPC is enabled by default in namecoind.
Re: .conf RPC Authorization
Fully agree with REST here. This is definitely a useful thing for read-only access. I'm using it for Namestamp particularly for this reason.biolizard89 wrote:This is not in practice a problem. For reading names, you can use Namecoin Core's REST API, which doesn't need a password. For things that need RPC, Namecoin Core 0.12 and higher have cookie authentication (very similar to how Tor handles authentication). The only time you need a manual RPC password is when the thing you want to do isn't available via REST (i.e. wallet methods) and the calling program doesn't have access to Namecoin Core's auth cookie file. I can imagine cases where this is true (maybe a wallet script and Namecoin Core are in separate VM's), but it definitely isn't the case for the default Windows installation of a hypothetical bundle of Namecoin Core and NMControl/ncdns.
For reference: to enable the REST API, pass "-rest" to Namecoin Core. To enable RPC for Namecoin-Qt, make sure that namecoin.conf has "server=1" in it. RPC is enabled by default in namecoind.
Regarding cookie authentication, I have to admit that I never really looked into the details (except that I saw the upstream commit while merging). Doesn't this basically result in the same problem as localising the namecoin.conf file in the first place? I. e., you have to access the data directory and need to know where it is if not in the default place? The only improvement I can see is if the user has a standard data directory (e. g., ~/.namecoin) but a non-standard config file. Is that really common?
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/
Re: .conf RPC Authorization
REST is better but users will still have to pass a command line arguments or create and alter the conf file. would it be acceptable to query the user to add "rest=1" to the conf file? It seems way safer than opening the rpc server.
Re: .conf RPC Authorization
On Windows, I always store config files in non-default locations because it's easier to find them (e.g. e:\nmc) rather than type %APPDATA%...domob wrote: Is that really common?
Then when I need to change, script, backup or do anything related, I always know where to go.
Maybe "regular" users who don't mess around with the s/w don't do that, but the s/w (including Bitcoin Core, etc.) is still mostly used by geeks and I would say non-default locations and config file names are not that rare.
Re: .conf RPC Authorization
Note that on Windows it is possible to read the data directory location from the registry it was changed from default during client installation. I have already tested reading this out but still need to add it to namerpc.py
Users that hold their .conf files in non default / non installer created folders are nothing we need to worry about - they won't mind to configure NMControl to work even if it involves a little effort.
What I am worrying about here is single click installers. I was hoping we could at least create something that would work out of the box while the API server version is not yet secure enough.
Users that hold their .conf files in non default / non installer created folders are nothing we need to worry about - they won't mind to configure NMControl to work even if it involves a little effort.
What I am worrying about here is single click installers. I was hoping we could at least create something that would work out of the box while the API server version is not yet secure enough.
-
- Posts: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
Re: .conf RPC Authorization
The idea behind cookie authentication is that it's automatically set up (which improves usability and discourages people from using low-entropy passwords) and the password changes on every boot of namecoind. I'm sure either the Tor or Bitcoin devs could explain in more detail why it's a good idea.domob wrote:Fully agree with REST here. This is definitely a useful thing for read-only access. I'm using it for Namestamp particularly for this reason.biolizard89 wrote:This is not in practice a problem. For reading names, you can use Namecoin Core's REST API, which doesn't need a password. For things that need RPC, Namecoin Core 0.12 and higher have cookie authentication (very similar to how Tor handles authentication). The only time you need a manual RPC password is when the thing you want to do isn't available via REST (i.e. wallet methods) and the calling program doesn't have access to Namecoin Core's auth cookie file. I can imagine cases where this is true (maybe a wallet script and Namecoin Core are in separate VM's), but it definitely isn't the case for the default Windows installation of a hypothetical bundle of Namecoin Core and NMControl/ncdns.
For reference: to enable the REST API, pass "-rest" to Namecoin Core. To enable RPC for Namecoin-Qt, make sure that namecoin.conf has "server=1" in it. RPC is enabled by default in namecoind.
Regarding cookie authentication, I have to admit that I never really looked into the details (except that I saw the upstream commit while merging). Doesn't this basically result in the same problem as localising the namecoin.conf file in the first place? I. e., you have to access the data directory and need to know where it is if not in the default place? The only improvement I can see is if the user has a standard data directory (e. g., ~/.namecoin) but a non-standard config file. Is that really common?
-
- Posts: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
Re: .conf RPC Authorization
Shouldn't be hard to just edit the Start menu shortcuts so that they include "-rest". I don't know if this is easier or harder than adding "rest=1" to namecoin.conf.phelix wrote:REST is better but users will still have to pass a command line arguments or create and alter the conf file. would it be acceptable to query the user to add "rest=1" to the conf file? It seems way safer than opening the rpc server.