Feature request : hauth check

[dnsBlah]

Please add a conditional check and 2 variables in the configuration for hauth (a static prod, and a "test/scan" variable)
if set, on the access_tinfoil_shop() first check if http_hauth IS the value from configuration.
if not set, update the test/scan variable with the http_hauth that was given.

if hauth has been set in the config, but the check fails > just give a http 400 response

This way admins can lock their index from being downloaded without knowing the actual hauth key.

[a1ex4]

What's hauth and how is it configured / used with Tinfoil?

[dnsBlah]

What's hauth and how is it configured / used with Tinfoil?

hauth is a http header send by tinfoil on authentication/index refresh.
This is not configurable but a unique generated token by Tinfoil using "unknown" generation method.

This is unique per protocol+domain

Checking the HTTP_HAUTH on login/shop index, you can keep your links 'secret'

[a1ex4]

Thanks for the explanation, so that's why the index could not be downloaded from a non Tinfoil client even with the correct headers with the older public shops...

This definitely needs to be implemented then, the thing is that the shop can be reachable from multiple hosts (reverse proxy, lan...) so I'll test all of them to make it won't break.

[dnsBlah]

Thanks for the explanation, so that's why the index could not be downloaded from a non Tinfoil client even with the correct headers with the older public shops...

This definitely needs to be implemented then, the thing is that the shop can be reachable from multiple hosts (reverse proxy, lan...) so I'll test all of them to make it won't break.

Yeah that's exactly how its done.
I'm sorry, I can't really tell you what is exactly generating the hauth key (i do not know), thats why i proposed to have one field that populates by itself when clients connect, and a manual one which is used to force comparison

[a1ex4]

I gave it more thoughts and decided not to implement the hauth check. To me it is just a false security as:

1. Tinfoil requests can be intercepted and headers modified before issuing a request to the original host url
2. The hauth key is trivial for anyone to figure out

For these two reasons it is obvious that the hauth check can be easily bypassed, the request headers are not encrypted so there is no way of knowing if the request was tempered with.

Instead I implemented a new configuration in Ownfoil to set the Shop URL:

• if a request from Tinfoil is made securely (using the https protocol) then the request's host is compared to the shop URL; the request is rejected if it doesn't match.
• if there is a match then the referrer key is a added to the shop content, so the Tinfoil client can verify it. This way if the shop content is encrypted (coming later) then the Tinfoil client can securely check if the referrer given by Ownfoil is the same as in the Tinfoil configured endpoint, and we are 100% sure that the request was not hotlinked.
• This means that only one URL can be used to access the shop.
• if the shop URL is not configured, then remote access is disabled, all secure connections from Tinfoil will be rejected.
• if the shop is accessed in a unsecured way (with http, for example for local network access) then host verification is skipped.

I added explicit messages to be displayed in Tinfoil in case the URL is not configured or if the host verification fails, see the linked commit.

What do you think about this approach? Maybe the host verification can be optional if the URL is not configured and it is too harsh to disable remote access entirely.

[a1ex4]

Now I've made it so it only display a warning in Tinfoil if the Shop URL is not set, instead of disabling the remote access entirely.

[dnsBlah]

Actually, it's a common security measure for any shop to actually use the HAUTH verification.
"1. Tinfoil requests can be intercepted and headers modified before issuing a request to the original host url"
If you use HTTPS, this is not true ALL headers are encrypted. You can't install custom CA certificates to have a working MITM with HTTPS decryption. (at least not for the majority)
And sending custom headers is easy, and this is exactly the reason for using HAUTH verification.

"2. The hauth key is trivial for anyone to figure out"
I have not seen anyone yet figuring it out. The only one who knows how it's generated is the developers.
If this is a reason for not implementing security measures, you can as well ditch encryption and authentication in it's whole.
The actual user authentication is easier to break then HTTPS decryption

But, it's not my project :) I was just giving my 2 cents.
No hard feelings! I like your project (even if I don't use it myself)