Hi everyone,
https://docs.djangoproject.com/en/4.2/ref/django-admin/ claims that
manage.py, django-admin and python -m django are practically
interchangable. However, I noticed that they behave differently when it
comes to the python path (the path you can import modules from). I used
`CMD
+1 from me.
On 14/04/2022 11.03, Ville Säävuori wrote:
And to be clear, I understand we already have middleware APIs and
various settings to handle this but my point is that I think handling
this in Django core (even as an optional setting or middleware) would be
most useful and right way to
Hi,
On 09/04/2022 20.50, Dan Davis wrote:
MFA is typically built with some form of federated login
I am not sure that this is "typical", but I agree that many
organizations want to manage keys in a single place. The trouble with
WebAuthn is that is a challenge-response protocol, so you cannot
Hi,
On 09/04/2022 11.35, Carlton Gibson wrote:
But — question — would documenting the existing options be viable?
We don't normally point to (many) third-party apps in the docs. It's too
variable, too difficult to maintain (etc).
The exception is third-party databases backends, which we do
Hi Jacob,
I actually do like that idea! I don't think it is a good default for
django in general, but I would be interested in a reusable app that
implements this. Is this already available somehwere?
thanks,
tobias
On 05/04/2022 16.04, Jacob Rief wrote:
How about this proposal?
Someone
Hi Yonas,
the best place to start is probably to look at thrid party packages, e.g.:
https://github.com/django-otp/django-otp
https://github.com/jazzband/django-two-factor-auth
https://github.com/mkalioby/django-mfa2
https://gitlab.com/stavros/django-webauthin
https://github.com/xi/django-mfa3
Hi,
AFAIU, SafeExceptionReporterFilter takes care of removing any sensitive
data from logs. However, I today realized that this does not cover
session cookies.
In a ticket about this issue[1] it was treated not as a security issue
but more as a request for customization. That puzzled me a
> Back then there were various issues with localisation when **not**
using type=text.
As https://code.djangoproject.com/ticket/16630#comment:11 states: the
inputs only accept a special format. To make it work I had to explicitly
set the format: `DateInput(format='%Y-%m-%d', attrs={'type':
Hi Thibaud,
thanks for the follow up. +1 on basically everything you wrote!
On 15/06/2021 02.59, Thibaud Colas wrote:
This distinction between "sites built with Django" and the "Django
admin" highlights an important point, which is that for lots of sites
the Django admin would be what
to Django.
https://github.com/schinckel/django-shared-property
Matt.
On Sunday, March 14, 2021 at 11:46:15 PM UTC+10:30 Tobias Bengfort wrote:
Hi,
a while back there has been a discussion about calculated model fields:
https://groups.google.com/g/django-developers/c/ADS
Hi,
a while back there has been a discussion about calculated model fields:
https://groups.google.com/g/django-developers/c/ADSuUUuZp3Q/m/5o02Lp_jCwAJ
The main benefit would be that these would be available in cases where
annotations are currently not available, e.g. related queries or admin
On 09/03/2021 18.03, Carlton Gibson wrote:
Do you want to open a PR with suggested changes as a focus for discussion?
I would open a PR that improves the docs, but I still don't understand
the difference, so I wouldn't know what to write.
The other alternative would be remove one of them,
commit to
staff_member_required was 2015. It was documented shortly after that.
So it seems like the documentation is up to date with the code.
On 09/03/2021 14.50, Carlton Gibson wrote:
Hi.
On 9 Mar 2021, at 14:33, Tobias Bengfort <mailto:tobias.bengf...@posteo.de>> wrote:
Accord
Hi,
On Tue, 9 Mar 2021 at 11:04, Carlton Gibson wrote:
> I’ve always taken it that @staff_member_required is for decorating
> views that aren’t part of the admin, and so not accessed via
> AdminSite.get_urls().
On 09/03/2021 13.21, Adam Johnson wrote:
admin_view does extra stuff like calling
Hi,
while reading the documentation on django's admin site I noticed there
are two mechanisms to check for authentication: AdminSite.admin_view[0]
and staff_member_required[1]. I am not sure when I should use which of them.
So what is the difference between the two? I expect that
Hi Diptesh,
I think it is great that you want to work on this. I also think asking
for feedback now is the right way to go.
That said, I personall have not had the best experience with pytest. I
have mostly worked on smaller projects though, so my perspective might
be very limited.
My
Nice writeup! I found it easy to read (I did not catch myself skipping
paragraphs which is always a good sign). Contentwise, I would have no
issue if this was accepted as is. Maybe I am forgetting about some
important details though.
I had just some ideas that might be good additions:
- mention
Hi,
felixxm proposed in https://code.djangoproject.com/ticket/31617 to add a
DEP for this. The more I think about it, the less I agree.
There is no DEP for security, usability, developer ergonomics or
anything like that, so why should there be one for accessibility?
Like with any of the other
Hi Mehmet,
On 19/03/2020 09.49, Mehmet Ince wrote:
> To be honest, I’m kind a confused about how to proceed. Should I
> continue with settings to control it or subclass of Auth middleware ?
Remember that many people on this mailing list (me included) are people
just like you, so we can only
On 14/03/2020 09.43, Tobias Bengfort wrote:
> Another option could be to add system checks for this: Instead of
> silently "fixing" missing code it would inform developers about missing
> decorators/mixins. (If I have time I might try to come up with a
> prototype of this.)
Hi Mehmet,
On 13/03/2020 21.47, Mehmet Ince wrote:
> - We must forcefully enable session validation for every endpoint.
> - Developers must do something to make the unauthenticated endpoint
> instead of making it authentication protected!
I agree with you that this would be a better situation
I also have experience with the limitations of the default permission
system. But I don't think it is necessarily a problem. There are two
options to deal with it:
- Django could add small bits of flexibility, e.g. make the group model
swappable. This adds complexity that needs to be accounted
See https://github.com/django/django/pull/11037
User.is_active is checked in contrib.auth.ModelBackend on all of these
methods:
- `get_user_permissions()`
- `get_group_permissions()`
- `get_all_permissions()`
- `has_perm()`
- `has_module_perms()`
I think the last three are redundant and should
On 08/11/2018 12:00, Carlton Gibson wrote:
> Perhaps you could put docs changes you'd make in a third PR (or
> ticket if you like, to discuss the outline)? (Maybe one PR with three
> commits makes it easier to review as a whole.)
I created a pull request with some changes, mostly related to
I feel like the interface for authentication backends is unnecessarily
complex: Basically, you only need authenticate() and has_perm(), but
currently the interface also includes get_group_permissions(),
get_all_permissions(), and has_module_perms().
The architecture is like this: User inherits
On 08/11/2018 11:43, Carlton Gibson wrote:
> My only concern thus far is bringing out the change well enough in the
> release notes and docs.
> (Split between the two PRs I'm not sure it quite does that.)
My impression is that authentication backends and object permissions
have already been
Hi,
as far as I understand the documentation[1], django's architecture
supports object permissions, but external apps like django-rules or
django-guardian are supposed to provide actual implementations.
I think this approach is great. However, I believe that there are some
key points where
27 matches
Mail list logo
