Create .conf file with RPC credentials if none exists. #6258
Conversation
|
@Alex-van-der-Peet: your contribution are very welcome! Thanks. This PR would make things more convenient, but, i have a strong feeling that the |
|
@gmaxwell and I had an interesting conversation about this once. The idea would be not to generate a This is similar to Tor's |
|
|
|
@paveljanik Eh? That is how it is implented though. No file -> create file, file -> do nothing. Also, I might be having a moment of stupidity, but a read-only config file? How would that work exactly? I checked the access rights of the created file in Ubuntu, I think they're correct. |
|
@Alex-van-der-Peet ups, sorry. I have reread again and yes, this is how it is implemented. |
|
Commit description also needs to be fixed to actually describe the change being made. |
Alex-van-der-Peet
changed the title
|
@laanwj I like that cookie idea! |
|
I'll have a stab at implementing the cookie authentication. |
|
See #6388 |
|
I prefer #6388's approach. |
When no `-rpcpassword` is specified, use a special 'cookie' file for authentication. This file is generated with random content when the daemon starts, and deleted when it exits. Read access to this file controls who can access through RPC. By default this file is stored in the data directory but it be overriden with `-rpccookiefile`. This is similar to Tor CookieAuthentication: see https://www.torproject.org/docs/tor-manual.html.en Alternative to bitcoin#6258. Like that pull, this allows running bitcoind without any manual configuration. However, daemons should ideally never write to their configuration files, so I prefer this solution.
|
Closing in favor of #6388 |
When no `-rpcpassword` is specified, use a special 'cookie' file for authentication. This file is generated with random content when the daemon starts, and deleted when it exits. Read access to this file controls who can access through RPC. By default this file is stored in the data directory but it be overriden with `-rpccookiefile`. This is similar to Tor CookieAuthentication: see https://www.torproject.org/docs/tor-manual.html.en Alternative to bitcoin#6258. Like that pull, this allows running bitcoind without any manual configuration. However, daemons should ideally never write to their configuration files, so I prefer this solution.
When no `-rpcpassword` is specified, use a special 'cookie' file for authentication. This file is generated with random content when the daemon starts, and deleted when it exits. Read access to this file controls who can access through RPC. By default this file is stored in the data directory but it be overriden with `-rpccookiefile`. This is similar to Tor CookieAuthentication: see https://www.torproject.org/docs/tor-manual.html.en Alternative to bitcoin#6258. Like that pull, this allows running bitcoind without any manual configuration. However, daemons should ideally never write to their configuration files, so I prefer this solution.
6 participants
I've attempted to implement issue #3902 as described in its discussion. Description:
If no username and password are provided through the conf file or command line and no conf file exists, one will be created and preconfigured with the username and password recommended in the original console message. The generated username and password will be set in memory too, so the RPC server is immediately accessible with these details.
If a conf file does exists but does not contain a username and password, the old error will show, as I felt it too forward to start modifying a user's existing conf file without their consent.
First attempt to contribute, please don't bite my head off.