Thank you for your reply.
> Implementation might get complicated in multi table
> inheritance, where the unqiue field may not reside on the target table
> itself (would need a similar tables+rows lookup expansion as done for pk).
How can it be complicated ? I thought it's just something like
ge
Hi,
Thanks for getting back to me.
How difficult is it to introduce new 2fa options without deprecating the
existing ones if the right design is in place? I do not expect it to be
challenging. But one downside, among others, would be the maintenance
burden.
Correct me if I am wrong, but for a
Hi, Carlton!
Thanks for getting back to me.
How difficult is it to introduce new 2fa options without deprecating the
existing ones if the right design is in place? I do not expect it to be
challenging. But one downside, among others, would be the maintenance
burden.
Correct me if I am wrong,
Ah, thank you for explaining. I missed the point and the existing setting,
sorry.
Cheers,
Maciej
wt., 7 cze 2022 o 11:26 Florian Apolloner
napisał(a):
> Hi Maciej,
>
> You can already customize the cookie name via a setting. What this request
> is asking is customization based on the request ob
Hi Chris,
On Tuesday, June 7, 2022 at 11:30:46 AM UTC+2 christopher@gmail.com
wrote:
> The question is how to add support cleanly so that both names are
> supported in 4.1? Is there a preference? Particularly how can it be be
> done to reuse code without (temporary) duplication?
>
Good
> I agree with Florian, I'd prefer adding support for *python-oracledb* in
Django 4.1 and immediately deprecate using *cx_Oracle *(will be removed in
Django 5.0).
That sounds fair. The cx_Oracle namespace won't have any substantive
changes; maybe some new wheels for Python 3.11, and any critic
Hi Maciej,
You can already customize the cookie name via a setting. What this request
is asking is customization based on the request object which is not that
common. Did you check that you configured your applications correctly to
use different cookie names
(https://docs.djangoproject.com/en/
Hi Yonas.
Thanks for your input here.
Two points:
- I *think* one reason Django doesn't already have 2fa itself is that
available methods have (up to now) each been problematic in their own way.
The trouble with adding a sub-optimal approach into Django is that we're
essential
