Yes, likely.
My point was (merely) that we **don't** want to add
additional extension points to PasswordResetTokenGenerator.
On Tue, 23 Aug 2022 at 12:58, Roger Gammans
wrote:
> Hi
>
> If it's intended as a reference implementation, then I would expect
> PasswordResetTokenGenerator to use
Hey Pete.
Yes... this is a good one.
It's difficult to see how we can even have an ASGI runserver in core,
simply because there's no SimpleServer equivalent as there is for WSGI, and
it's not clear one is on the card. (HTTP is getting **more** complex, and I
can't see Python bringing such into
Thanks for the additional background Carlton! I like the idea of
having some sort of protocol that folks can follow to make
ready-to-use Django server packages (django-webserver [1] is in the
same vein), but I'd strive for more. pip install + INSTALLED_APPS is
great, but getting to production with
Hi all! I'd like to re-open the discussion around
https://code.djangoproject.com/ticket/21978
As a "batteries included" framework, Django kind of leaves people to
fend for themselves when it comes to deployment. This makes it harder
than necessary for a developer to go from works-on-my-laptop to
Hi Alexander.
I think the point from ticket #30423 is that we don't want to complicate
PasswordResetTokenGenerator in order to make it into a more general
purpose token generator.
Much better is for you to take inspiration from it to implement what you
need in your project. (It's the underlying
Dear group,
ticket https://code.djangoproject.com/ticket/33904 was closed with
https://code.djangoproject.com/changeset/0756c61f2ada56e4ae625589099c0141a77737eb/
However, it seems that that commit has a fix for #33893, not for #33904 ?
Best regards,
Carsten
--
You received this message
Hi Carsten,
Mariusz marked that as a duplicate
The fix was applied to stable/4.1.x here:
https://github.com/django/django/commit/82e9e19ebe6bc920f1cfffc42d86648644fd4a78
It'll be part of the next release.
https://docs.djangoproject.com/en/4.1/releases/4.1.1/
Can you give stable/4.1.x a try and
Hi Carlton,
thanks for your reply!
I tried as you suggested with the stable/4.1.x branch, but the issue reported
in #33904 persists.
My JavaScript skills are limited, but I also cannot see any relationship
between the changes in
Hi Carlton!
I can understand what you're saying, and I don't think the TimestampSigner
solution is bad
But again, it's a little unclear why in the end, in line 132 of
https://github.com/django/django/blob/7e6b537f5b92be152779fc492bb908d27fe7c52a/django/contrib/auth/tokens.py#L132
we assign
Hi Max!
Thanks for your answer
But honestly, I don't really understand how You can check if super returns
false not from the last 'if'.
Now the function has 5 places where it can return False, and yes, we don't
like the last case specifically. But to be honest I don't see a way to
check the
Hi
If it's intended as a reference implementation, then I would expect
PasswordResetTokenGenerator to use Signer or
TimestampSigner internally , but I was surprised to discover that it
didn't use either.
Isn't those entry points the better API to advise for use rather than
the direct use of
Hey Pete.
Yes, there can be a lot of steps... (and trouble is every one has a
different opinion once you get to specifics :)
django-webserver looks good — in a similar ballpark to what I had in mind,
yes, but I'd probably not want to bundle the options for each server
myself, as that seems a lot
Improving the docs sounds good.
I think it would also be worth renaming engines to backends, and
EngineHandler to BackendHandler, or similar. Yes it would require a
deprecation cycle, but I also imagine 99% of projects would be unaffected.
On Tue, Aug 23, 2022 at 8:39 PM Peter Thomassen wrote:
I hadn't seen django-simple-deploy. At first glance, it looks interesting,
but more platform-specific than what I was thinking.
I'll play around with creating a third-party app that encapsulates some of
these thoughts and see where I end up.
Thanks for your time and feedback!
On Tuesday,
Hi Carlton,
On Mon, Aug 22, 2022 at 6:21 AM Carlton Gibson wrote:
The current get_default() behaviour was only added to allow folks manually creating `Template("My String")` instances to continue to operate with multiple Django backends defined (#27359) — the initial assumption there was that
15 matches
Mail list logo
