Get IP Address Without Password

[ironhaven]

Currently in order to retrieve a IP address you need both the username and password. With the username and password you can also change the IP address. This would be unnecessary access if you just wanted to share a home IP with a friend (Who might accidentally do a curl post and clobber the IP).

I suggest that during a get request if a username is in a URL parameter (e.g https://d5.example.com/servername) then the server will return the IP address of "servername". POST and DELETE handlers will ignore the parameter and reject requests without the Authorization header.

One unintended benefit is that you could retrieve IP address with just a browser because you just need a URL without any extra headers. You could not use a browser before because you needed the Authorization header set when you send the request.

Do you think this would be a valuable feature?

Implementation

Instead of HashMap<UsernamePasswordHash, IPAddr> I would make it HashMap<Username, (Password, IPAddr)>. It would be require each endpoint to decode the base64 Basic Auth to get username and password. Thankfully the base64 crate is already included so no new dependencies will be added.

[codesections]

I like this idea, but have two concerns.

First: I think that d5 should allow users to chose whether they allow access to the IP address without a password. My concern is that some people may not have a secure enough username to protect the IP address, and IP addresses do encode a fair bit of info (location, if nothing else). I think we could solve that by making the hashmap a HashMap<Username, User> and having a User struct that is User {username: String, IpAddr: String, public: bool} (or public could be an enum for greater clarity at the cost of some additional length?)

Second, I'm wondering how this change would/should impact name collisions. Right now, if two users share the same username–password pair, the second to POST will silently overwrite the first, which isn't ideal. I had noticed that issue, but hadn't thought it worth addressing, since the odds of people having the same username and password are low (and would probably only come up for people with very week passwords). But if we make this change, we'll necessarily preclude multiple users from sharing a single username.

I'm not quite sure what the best way to handle that is. I'm slightly hesitant to adopt an approach that leaks whether an requested username exists., but I don't have a great way to avoid that off the top of my head.

Thoughts?