j"1LAnZuoQdcKCkpDBKQMCgziGMoPC4VQUckMh<div class="post">After further research... I think the Transmission approach, combined with the existing "only allow connections from 127.0.0.1" is a good short/medium-term solution.<br/><br/>Putting the username:password in a settings.json file in the Bitcoin directory aught to work nicely (since Bitcoin can already parse JSON). And keeping the authentication stuff off the command line and in the HTTP headers instead of the JSON request params is nice and clean.<br/><br/>Long term, the "right" way to do authenticated, secure JSON-RPC is with client-side certificates and https. But that looks like it would be a lot of work to implement and a <a href="http://it.toolbox.com/blogs/securitymonkey/howto-securing-a-website-with-client-ssl-certificates-11500">big learning curve</a> for users to figure out how to generate client-side certificates and how to get both sides of the JSON-RPC connection using them. And I'm not even certain a full-blown client certificate solution would solve the problem of malicious Javascript making JSON-RPC requests via XMLHttpRequests to localhost; if the user installed the client certificate in the browser (because maybe there was a nifty JSON-RPC-powered web front-end to controlling Bitcoin), would the browser automatically send the client certificate if a malicious website made requests?<br/></div> text/html
https://whatsonchain.com/tx/e3cc897c5e26d962db5c3fcb1ca53917028a8a2e30795d3dc01360ee65ce747f