-
-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Library design going forward - high and low level API expected? #60
Comments
Hi @sergei-maertens, there are a few general changes we'd like to make to this library. One of them is adding support for django-rest-framework with serializers and views. As you can imagine, that would duplicate some of the logic that currently exists in forms and views. So, yeah, if we can find a way to extract "validate this token" into something that's reusable and could possibly be used by people outside of any of Kagi's high-level features (views/forms/serialiezrs), that'd be great. As for the MFA requirements that you are talking about, I see the following feature requests:
Does that list make sense to you, @sergei-maertens? Did I miss anything? Is there anything I misunderstood? |
Sounds on point! |
I've turned those feature requests into dedicated tickets. For those, the discussion can happen there. This ticket is only about an architectural re-design, e.g. to support django-rest-framework. |
First of all - thanks for this library, the demo project is really cool to test out the various features!
We're looking to integrate kagi in some serious projects, and one of the things I'm noticing with (most) MFA-related libraries is that they're either quite invasive or make it too easy to shoot yourself in the foot.
So, I'm hoping that kagi takes an approach where you have some drop-in "recipes"/functionality (which would be the current situation, like the kagi
LoginView
and then updating settings to point to the kagi login URL), which would serve the majority of package users probably, and then some lower-level tooling to wire things up yourself if need be.For example, we need a way to be able to enforce MFA only in the admin (middleware checking the MFA auth status if
request.path
startswithreverse("admin:index")
?) and redirect people to the setup/configuration page if that's not the case. BUT, since we also support OIDC login which has their own MFA setup, it should also be possible to disable this admin-mfa-enforcement.Doing these checks whether MFA is required or not, whether the user has that enabled or not (I see some request.session stuff happening in your LoginView) seem to me as viable candidates for public utilities used in your recipes and exposed/documented for people using low-level interfaces.
Is this something you would be open to? I'm fairly hopeful we could contribute this from Maykin Media.
The text was updated successfully, but these errors were encountered: