Client-side HTTP basic authentication support about gno HOT 4 OPEN

@thehowl I will create a PR to address this issue and look forward to your guidance to complete this

from gno.

@linhpn99 No I'm not. That's an example of how basic auth can be implemented at the server level, using caddy (which requires the password to be stored as safe hashes); it's provided as a reference for testing.

This is not a server change, only a client change. It can be as simple as calling this with the values provided in the remote URL.

from gno.

Thanks!

from gno.

it seems you're recommending to use bcrypt to encrypt the password, where can we store the salt for both server and client ?

HTTP basic authentication is a simple authentication mechanism, implemented directly in the protocol. Because it is integrated at a protocol level, web services can be protected by edge web servers like nginx and caddy, without requiring changes in the application itself.

For instance, I could have a simple caddy set up of a gno.land node, password-protecting its RPC, as follows:

rpc.gno.land {
	reverse_proxy gnoland:26657
	basic_auth {
		# Username "bob", password "hiccup"
		bob $2a$14$Zkx19XLiW6VYouLHR5NmfOFU0z2GTNmpkT/5qqR7hx4IjWJPDhjvG
	}
}

However, this is not supported client-side, for instance in gnokey. The URL-spec compliant syntax for providing basic authentication is prefixing the domain with user:password@, as follows:

https://bob:[email protected]:443

It would be nice if our clients, like gnokey and gnoclient, supported basic authentication and automatically added the Authorization header in HTTP requests when provided.

from gno.