Other then u2f and TOTP, I'll favour for email and sms (using external api
like twilio) based OTP as well. Keeping different pluggable backends will
be better in my opinion.
On Tue, 27 Oct 2015 at 07:01 Russell Keith-Magee
wrote:
>
> +1. Sounds like a great idea to me.
>
> Russ %-)
>
> On Tue, O
+1. Sounds like a great idea to me.
Russ %-)
On Tue, Oct 27, 2015 at 1:22 AM, Tim Graham wrote:
> On Trac [1], Alex says, "Django did a tremendous service to its users by
> making strong password hashing be the default. The world is pushing
> forward, and now 2fa is the next standard that many
Fwiw, 2fa is on my short list of things to implement into my current
project. It's a fairly important feature to me, as this is a financial
project. And that particular implementation is precisely what I was looking
to use. I would happily contribute money and/or time toward this
implementation, es
Having pluggable 2fa backends is a great idea.
Many sites that allow 2fa have it as an option per user. I would think
Django would allow the same. Allow admins to force 2fa, or allow Users to
choose if they'd like it enabled.
There'd have to be ORM/Model support (presumably) for user choices. A
Thanks for the feedback.
Ticket: https://code.djangoproject.com/ticket/25611
Pull request: https://github.com/django/django/pull/5482
On Monday, October 26, 2015 at 8:22:21 AM UTC-4, Marc Tamlyn wrote:
>
> Sounds good to me. There's not any (good) reason why anyone would be
> calling these with
The place you linked to is ignoring CommandError when parsing arguments.
I'm not sure under what conditions this happens (if at all) -- the Django
tests don't cover it.
As far as I know, BaseCommand already does sys.exit(1) when there's an
unhandled exception:
https://github.com/django/django/
I also agree. And to be clear, we're talking about UserCreationForm, right?
Or where specifically would we implement this? (What part of Django do you
use that doesn't check this?)
On Monday, October 26, 2015 at 2:04:24 PM UTC-4, bliy...@rentlytics.com
wrote:
>
> > -1 on changing the check of u
On 26 oct. 2015, at 18:22, Tim Graham wrote:
> What do you think?
I would very much like Django to have 2FA out of the box.
Let’s bring django.contrib.auth kicking and screaming into the 2010’s ;-)
I even considered crowdfunding it but that didn’t go much beyond idle thoughts.
--
Aymeric.
--
> -1 on changing the check of usernames at login to case-insensitive
> +1 with preventing the creation of new usernames
Ditto
On Thursday, October 22, 2015 at 9:33:02 AM UTC-7, mtnpaul wrote:
>
> Yeah, I was referring to the post by Daniel at the start of the thread,
> not Reid's comment.
>
> I
Is it ok if I do a PR on this? This seems like it would be really useful
for automation.
-Ben
On Thursday, October 22, 2015 at 2:20:18 AM UTC-7, Ben Liyanage wrote:
>
> Hey,
>
> What do you guys think about this feature request?
>
> > On CommandError, sys.exit(1)
>
> It would be pretty easy to
I agree with Alex, no idea about that particular implementation though. It
supports a lot of different implementations of two factor, though I suspect
Django wouldn’t need all of those things. I think it would be reasonable to
define something like auth_backends, but for 2fa and just ship u2f an
On Trac [1], Alex says, "Django did a tremendous service to its users by
making strong password hashing be the default. The world is pushing
forward, and now 2fa is the next standard that many sites fail to meet.
Django should include support for 2fa out of the box, ideally with support
for b
Thank you. Spot on answer. C.
On Monday, 26 October 2015 15:55:03 UTC+1, Tim Graham wrote:
>
> The release notes don't mention it because it's a private API until now.
> Feel free to do nothing as we're unlikely to remove the backwards
> compatibility alias for a while, at least until versions <
The release notes don't mention it because it's a private API until now.
Feel free to do nothing as we're unlikely to remove the backwards
compatibility alias for a while, at least until versions < 1.9 are
unsupported at which point you could update the import to the new location
without needin
Hi.
We've got a PR open on Crispy Forms to accommodate the changes to
BoundField's location in 1.9. It changed, broke the imports and was then
imported back for compatibility.
The release notes say very little here.
Could anyone who knows the plan say, whether BoundField should still be
imp
Hi,
Firstly I would like to say hi to everyone, since this is my first post in
this group :)
To the point; I was really glad to see behavior of `set_language` view
fixed in changelog of Django 1.9, however in my opinion it only solves half
of the problem with internationalized urls and browser
Sounds good to me. There's not any (good) reason why anyone would be
calling these with kwargs that I can think of so we're safe from a compat
perspective.
Marc
On 26 October 2015 at 03:25, Loïc Bistuer wrote:
> +1
>
> > On Oct 25, 2015, at 23:09, charettes wrote:
> >
> > Now that Curtis did a
Hi George,
The behaviour for {% url %} has since been changed when used with
a RequestContext. It will now default to the current namespace when
one is available. This change will be available in 1.9.
This change doesn't cover the thread-local storage for calls to reverse(),
or for {% url %}
Up to now you can change only one field in your make_query() method.
Flowing "think in sets" it would be nice to update N key-value pairs.
Am Freitag, 23. Oktober 2015 17:18:38 UTC+2 schrieb Collin Anderson:
>
> If it helps, I have a similar need in the template. My case requires
> adding, remov
Hi all,
We’re still investigating an ongoing incident that impacts the availability of
https://www.djangoproject.com and https://docs.djangoproject.com – both are
currently down.
Downloads from PyPI are not affected by that and should work as ever.
We’re in touch with our upstream provider and
20 matches
Mail list logo
