Many of these auth systems are client/server, not going to be the simplest
thing to configure the entire stack for simple projects/tutorials/testing
environments and so on. I can definitely see having.a pluggable alternative to
the contrib.auth package that implements all the client-side stuff,
Auth0 looks like a need solution! And yes, I am a bit YubiKey fan myself. Use
it for 2FA and PGP, worth every penny.
--
On 25. Apr 2019, 17:38 +0200, Александр Овчинников ,
wrote:
>
> > IMHO Django should provide a secure and simple (for developers) out of the
> > box solution.
>
> I can't but
> IMHO Django should provide a secure and simple (for developers) out of the
> box solution.
>
I can't but agree with you. Today long (at least >15 characters [Chrome
password manager], but > 20 is much better) passwords created and stored in
password managers (some modern browsers include
On Saturday, April 13, 2019 at 1:07:39 PM UTC+2, Florian Apolloner wrote:
>
> You could have reused https://github.com/aaugustin/django-sesame for the
> signing stuff :)
>
Ok django-sesame goes into a different direction but might still be worth
to look at it.
--
You received this message b
Hi,
On Friday, April 12, 2019 at 8:06:21 PM UTC+2, Johannes Hoppe wrote:
>
> I went with the hardest possible way, NO password, NO username. Just one
> time passwords send via email or SMS. Similar to Django’s password reset
> function.
>
I do not think that is the hardest possible way and as y
So I spend a little time fiddling around Django to understand what is possible
and where there might be room for API improvements.
I went with the hardest possible way, NO password, NO username. Just one time
passwords send via email or SMS. Similar to Django’s password reset function.
I publis
Hi
> Also related: UserCreationForm by default allows usernames that differ
> only by case
> https://code.djangoproject.com/ticket/25617
I would like to mention CITextField / CIEmailField here. It solves this
problem nicely, in my experience.
However, it is only available on Postgres, and it req
Hi Joe,
On Thursday, April 11, 2019 at 4:56:05 PM UTC+2, Johannes Hoppe wrote:
>
> @Florian, since I had so many PRs pending review, I had to find other ways
> to cause chaos ;)
>
Hehe probably, the autocomplete stuff is on my todo for the sprints (and
selenium is mainly waiting for a merge).
Focus is the biggest thing - with so many other packages such as
python-social-auth and django-cas-ng and django-warrant providing some sort
of Federated Login, I don't think it makes sense to try to incorporate
social login. However, it would be nice if out of the box could do a
register, verify
Hi there,
@Florian, since I had so many PRs pending review, I had to find other ways
to cause chaos ;)
Besides that I agree, this isn't an easy undertaking and a lot of time will
need to be spend on the whiteboard to get this going. Maybe it is worth
actually collecting a little bit of money f
Hello, this my first message... hi for everybodyI think it could be a micro-service... you would not touch what is there, which is a huge advantage regarding compatibility. We could start to monolith django and I think with this Auth history it would be a good opportunity. Abstraction for django-
Email and password is pretty well supported out of the box using the
configuration options provided on the AbstractUser (USERNAME_FIELD). Slightly
more complex cases like username and email both being valid login parameters
require very thin wrappers. The greater discussion is about technologi
Email + password auth is definitely a wanted feature out-of the box, and
probably a good first step would be to create a separate AbstractEmailUser
or something like that. Seems to me AbstractUser shouldn't be changed for
backwards compatibility reasons, but maybe something like a
BaseAbstractUser
Hi Joe,
uff you are bringing up a hard topic :) Yes I absolutely would like Django
to have better support for WebAuth (u2f-like tokens at least), and probably
another one or two (I'd keep the scope for support in Django small though
once we know that the API works).
Getting this actually imple
If we go to the most common use case, email + password is the current
"default" of the web, rather than username + password. It would make sense
for Django to use email + password by default.
It also feels like first_name and last_name have no place in AbstractUser
and should me moved to NamedA
15 matches
Mail list logo
