[abdullahkhalids]

I have used this to build an internal tool, and that was quite a nice experience.

My main complaint right now is that it's quite a bit of work to build authentication. I think there are some examples somewhere that show you how to do it. But given, how common it would be for people to use authentication, it should be built in as a first-class object.

[masenf]

Thanks for the feedback. I work on Reflex and in a recent release, the team added a template and CLI for creating third-party components and publishing them to PyPI.

Since then, I've built a few authentication libraries that might be of interest:

https://github.com/masenf/reflex-local-auth https://github.com/masenf/reflex-magic-link-auth https://github.com/martinxu9/reflex-google-auth (documentation WiP)

The problem with having auth built in is that it's been hard to find a solution that actually works for a majority of use cases. That said, as these auth libraries get more popular and refined, they might be moved into the reflex-dev organization as officially maintained components, or even integrated with the core framework.

[abdullahkhalids]

Thanks. This helps a lot.

However, I am concerned that the @reflex_local_auth.require_login decorator [1] merely redirects users to the login page.

> Although this seems to protect the content, it is still publicly accessible when viewing the source code for the page! This should be considered a mechanism to redirect users to the login page, NOT a way to protect data.

So, I have to put an if-else condition on the State data associated with each protected page, in addition to this decorator. The reasonable way to do it would be for the decorator to actually prevent any data load at all before redirecting. This will prevent a lot of mistakes, besides removing boiler plate.

[1] https://github.com/masenf/reflex-local-auth

[masenf]

That's a really good point. Definitely something we need to work out before integrating this into the core framework.

[jimmyechan]

Cofounder @ Dropbase (dropbase.io) here. If you just need to build internal tools with Python or want to build internal tools on top of your existing Python codebase, give us a try. We have granular permission built-in so you can share internal tools with others easily, down to who can use or edit each internal tool you build.

For context, we're a more niche cousin to Reflex that's specifically designed to build internal tools. Reflex seems to be a more general framework to build anything you want; quite powerful, and possibly an easier to use Django replacement.

It's awesome to see frameworks like Reflex. I think the Python ecosystem needs this.

[pbronez]

Dropbase looks neat. Couple questions based on my read of the site/github/docs:

- is the architecture exclusively hybrid SaaS? Looks like I host a worker node but a cloud connection is still required.

- how can I monitor the data flow between the local worker and hosted orchestrator? I assume it’s straightforward to turn on verbose logs on the worker’s requests out.

- is the IDE hosted locally or remotely?

- authentication to local services appears to be done primarily through credentials hardcoded in the ENV file. How can I use SSO and pass user authentication to the upstream data sources?