Re: Feature Idea: Allow setting session cookie name dynamically

[Carlton Gibson]

Hey Dan.

Thanks for following up here.

Just to recap, my reasoning on the ticket was that it's quite a niche
use-case. For me, just use the custom SessionMiddleware, or put that in a
third-party package for multi-tenancy folks to maintain together. (Or so
would be my opening thought... -- interested to see others' thoughts.)

Kind regards,
Carlton

Aside: Searching, there are lots of disparate resources for multi-tenant
deploys; slightly orthogonal to your exact suggestion here, I imagine
there's good work to be done corralling the interested parties and
patterns. Maybe one of the existing resources already does this... 🤔




On Thu, 2 Jun 2022 at 14:47, Dan Strokirk  wrote:

> Hi,
>
> Currently it's only possible to use a single session cookie, but it can be
> useful in a multi-tenant application to use multiple session cookies. To
> solve this we currently use our own, slightly modified SessionMiddleware
> class that we keep in sync with the official implementation and re-apply
> the patch during each Django upgrade.
>
>
> Proposal: Adding a new get_cookie_name or get_cookie_params method to
> the SessionMiddleware class might be one way to implement this, which means
> that you can then then use your own subclassed middleware to easily
> override it. It would take the request and response objects as arguments.
>
> If this seems like a reasonable feature to add I'd be glad to supply a
> patch.
>
> (I've previously submitted a WONTFIX ticket for this, perhaps a little
> over-eager :) https://code.djangoproject.com/ticket/33760)
>
> Best regards,
> Dan
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/879fbda1-c8f6-4995-a3d0-7b2cbe5bc282n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJwKpyROabEZPD2N%2BgQfJxGWh4TW%2BiZe1w5O0P8C4aKdS9nHwA%40mail.gmail.com.

Decision on a 2FA PR

[Yonas]

Hi,

In light of what happened to the ctx package, this is a good time to get a 
conclusion on the following topic.

I opened a PR  based on an 
accepted ticket  and a 
discussion . 
The PR implements 2fa but excludes WebAuthn, leaving it out as an 
alternative to Django password-based auth. But an idea on GitHub was 
forwarded that the PR won’t be accepted without at least supporting 
WebAuthn.

While 2fa is one use case of WebAuthn, the primary use case, in my opinion, 
is providing an alternative to or a replacement for password-based 
authentication. Regardless of its use case, the implementation of WebAuthn 
does not have a lot in common with the opened PR. 

Instead of taking the all-or-nothing approach, doesn’t it make more sense 
to work on the opened PR--making Django more secure--and support WebAuthn 
when someone in the future opens a PR for either or both of the use cases?

Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/be8111ae-91e5-45f0-b0b7-8ab737e40761n%40googlegroups.com.