Feature suggestion: GUI authentication

[paulpierre]

Currently it is not viable to work with Trueblocks in an external setting with a team and where the application sits on a machine with a public address.

• As a user I would like the option to use at minimum Basic Authentication as as security configuration to view the GUI
• As a user I would like to have a security mechanism whereby I must provide an API key via headers, ideally via JWT

[tjayrush]

Thanks for your issue. I agree completely with your issue. You are exactly correct. There's a reason for this. TrueBlocks is not designed for use in a server environment. It's local-first. We take advantage of that in very many ways in the code. A lack of a need to "log in" is one of them. (Think about it, you don't log in when you use Visual Studio Code -- there's no need to.)

This was an engineering choice -- for two reasons: (1) I don't know how to do it, and (2) it needlessly complicates the code.

My larger concern is that many of those other things we've done because we're local first -- such as write directly to flat binary files -- are way more difficult to do than requiring login, so I'd be concerned that even if we were to add logging in as a feature, it would be way more complicated than that.

Having said all that -- we're open to PRs.

[dszlachta]

Hi @paulpierre, as @tjayrush pointed out this was a design choice. But, as improving the overall experience of Explorer is on our todo list, there may be other issues that we can fix. It would be very helpful to us if you could share your use cases and how your team uses TrueBlocks.

[uwe]

If you run TrueBlocks via Docker you can add a reverse proxy in between that does the auth (and https), e. g. caddy https://caddyserver.com/

[tjayrush]

I'm very interested in this, and I'd love to see how it all works, but I just want to warn you both that there are deep internal things that I fear won't work well in a server environment all related to the many users/single user paradigm shift. By that I mean, we purposefully don't protect against the many user case, which may (probably will) lead to corrupted data. We did this for reasons of speed and ease of coding.

Having said all that, I'd really like to learn how it all works. Please report back here.

[uwe]

Agreed, but to me it sounded the OP wants to use it for a small user base ("team").

[paulpierre]

Yes, correct. The idea would be multi-user auth for the Explorer UI itself. @uwe makes a good point that this auth could likely be handled at the load balancer / reverse proxy level w/ something like Ngnix, Traefik or Kong that provides auth options out the box.

Opening the aperture on our use case, we're interested in opportunistic ETL for specific addresses and contracts, similar to the Graph -- but unlike Dune which indexes all the things.

The Trueblocks indexing implementation is ideal for our use case but unfortunately isn't built for outside of personal use-cases. Happy to contribute a PR / fork that addresses scale use cases when the time comes. Thanks for being responsive. 👍

[tjayrush]

Thanks for the offer.

I've been thinking about this, and you'll forgive me for forgetting something about our own code. Whenever someone suggests a server-based idea as I perceive this to be, I respond identically: "that's going to be harder than it seems...blah, blah, blah..."

But I just remembered something.

We recently added a great new feature that addresses the "E" part of ETL perfectly. We call it monitoring, and it will be released in a beta version in the next release--coming very soon--next week.

Monitoring allow you to specify two files: (1) a file containing addresses, and (2) a file containing commands to run. In one test case, we've specified 2,300 addresses in the one file and six "commands" in the other and, at each block, it reads the block, checks to see if any of the addresses appear in the block and then "extracts" those six commands.

Currently, that code writes the data to a file (identically to the chifra export command -- in fact, the commands are chifra export commands.

We have designs for future version to allow for writing to database endpoints instead of a file, so this might allow you to use TrueBlocks for the "E" part (extract) and regular, every day web 2.0 website tech for scaling.

Let's keep the conversation going. Maybe we can leave this here and talk in the channel so others get the idea.