Basic Auth with DID relation?

[chrisdma]

Hi,

Thanks for the Tinfoil shop solution! Since public shops are all down, I am looking to start a shop that won't be super huge or anything, but I would like to implement simple authentication options. I can implement my own basic auth no problem, and that way user and passwords can be set within tinfoil on the client side to access the shop, however is there a way you can implement passthrough of basic auth credentials into the tinfoil server so that it can be verified with a Device ID?

I'd essentially like to make sure a basic auth credential wouldn't be able to be shared among multiple devices, so that I can associate one or two device IDs to a basic auth credential.

Maybe something like below:

username, password, ok := r.BasicAuth()
so that they can be inserted into a mongo/redis/sql database along with the uid, and a simple check of if all 3 don't match then deny access?

[DblK]

Thanks for the suggestion. Handling user password and switch id is planned to be able to ensure everything is good for access.
I am currently thinking of a better implementation of the statistics which I do not like.
The storage part of sqlite might reach it and so user/password should be easy to implement.

I like your idea of passthrough though... Let me think about something nice and quick to implement.

Again thank for the suggestion, do not hesitate to star the repo to show your support!

[DblK]

Even if you can no do some PRs, please starts some discussions with the feature you wish to have!
I would love to see how users want to use this software and how we can make it better 🎉.

I might add a frontend soon, so maybe you will be able to participate there ;)

[chrisdma]

@DblK Just to confirm we would just set up basic authentication in our web server we are using (nginx, traefik, caddy, etc) only on the URL we set for the forwardAuth yml line correct?

[DblK]

Actually you have two choices:

1. You use whatever reverse proxy you want (caddy, etc..) and use its built-in directive to forwardAuth to another piece of software that will do the check of the user/password and possibly the Uid header if forwarded.
   Then you use TinShop without any special config.
   If the server handle the forwardAuth it will also handle the error so it will never reach TinShop in this case.
2. You do not have a reverse proxy (caddy, etc..) and you use the forwardAuth of TinShop.
   This will allow another piece of software that will check... (see Readme for the header and excepted response by TinShop).

In case 1):

on success it will be :

Switch -> Reverse Proxy -> Auth Server -> TinShop -> Switch

on error:

Switch -> Reverse Proxy -> Auth Server -> Switch

In case 2):

Switch -> TinShop -> Auth Server -> TinShop -> Switch
TinShop will handle either fail of success from Auth Server to respond accordingly to Switch

You can mix the cases, but I highlighted the main diff.

Conclusion

Once again, since there is not (yet!) user management within TinShop you have to user forwardAuth on reverse proxy or TinShop to handle basic auth (in combination with another piece of software that will really check the user/pass/uid that is out of scope of TinShop).

I hope I am clear on how to use it.

[chrisdma]

So if I understand correctly, lets say tinshop.example.com is the url used for the shop in the config. If you set the forwardAuth parameter to tinshop.example.com/login, then in whatever reveerse proxy used, you set basic auth on ~ /login for the tinshop.example.com domain so that the proxy handles it. I assume from there if /login returns 200 then tinshop receives that status code and lets the user load the shop, else if its like a 403 unauthorized status code tinshop doesnt load the shop?

Please let me know if I understood that correctly, and thank you again for adding this feature!

[DblK]

That is exactly right. You only need to make a script or something to handle the basic auth and reply 200 in case you let it pass through or anything else if you don't.
TinShop will handle the rest for you.

If you set-up a reverse-proxy on top of TinShop (for now), you can use forward_auth to handle it without using any config on TinShop.

Once a proper backend will be there, everything will be handled by Tinshop including rules, etc.. (spoil: I am currently working on a POC)