Hi Ahmad,
> On 23 Mar 2020, at 13:23, Ahmad A. Hussein wrote:
>
> I completely agree with what has already been said by everyone here;
> moreover, this is a battery missing from Django in my opinion. It would make
> Django more "batteries-included" if this was part of core rather than third
>
I completely agree with what has already been said by everyone here;
moreover, this is a battery missing from Django in my opinion. It would
make Django more "batteries-included" if this was part of core rather than
third party-libraries. If you need help with documentation, I can
definitely th
I personally am in favour of including this in Django at this point.
It seems like a desirable feature, it has circulated the community since
2008 (!), and there are at least two community packages implementing the
pattern. No one on this thread is explicitly against it ever happening.
I'm in fav
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 give
The oldest code at https://djangosnippets.org that fixes this is from
2008 so I guess something like this have been considered trivial to
build yourself ever since then, and hence why it's never been added.
Here are some alternatives:
https://djangosnippets.org/search/?q=login+required
I've been
> I'm surprised nobody has mentioned django-stronghold in this discussion
which does exactly what you're looking for.
Same here. django-stronghold has been working well in my projects for me
for years.
https://github.com/mgrouchy/django-stronghold
Em quinta-feira, 19 de março de 2020 07:
Hi all,
I'm surprised nobody has mentioned django-stronghold in this discussion
which does exactly what you're looking for.
It's implemented as a middleware, with two settings for exclusions -- A
list of named url's or a list of regex's to match url's against.
This works well, and managing the e
Hi Alasdair,
> On 16 Mar 2020, at 12:59, Alasdair Nicol wrote:
>
> Hi,
>
> Creating Django settings is often discouraged, so perhaps it would be better
> to create a subclass of AuthenticationMiddleware instead of adding a setting.
> Then users would update MIDDLEWARE to enable the new functi
Hi,
Creating Django settings is often discouraged, so perhaps it would be
better to create a subclass of AuthenticationMiddleware instead of adding a
setting. Then users would update MIDDLEWARE to enable the new functionality.
Cheers,
Alasdair
On Sunday, 15 March 2020 17:46:48 UTC, Mehmet Ince
Hi Adam,
Thanks for your comments. I was thinking to implemented this as a separated
middleware but, as you said, AuthenticationMiddleware is much better place to
do it.
I already started to implementing this in AuthenticationMiddleware. I would
like to send a PR if it’s okay to everyone ?
I’
Hi Mehmet,
I like your move to fail-closed here. I've certainly seen missing auth
decorators as a recurring issue in my career, and I do think as an OWASP
top ten we should try tackle it better in the framework.
Your implementation is very few lines of code. It could be made more
robust, using th
Hi Tobias,
Dne sobota 14. března 2020 9:44:16 UTC+1 Tobias Bengfort napsal(a):
>
>
> 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
> p
Hi Tobias,
Thanks for your comments
> On 14 Mar 2020, at 11:43, Tobias Bengfort wrote:
>
> 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
>> inst
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.)
https://github.com/xi/d
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 fr
Hi,
Actually, middlewares can access to the mapped view function/class with
process_view() method. Within the function we need to decide that view is
function or class. Easiest way to do it check existence of view_class attribute
of view_func variable. While __global__ exist on every object,
C
Hello,
If I'm not mistaken, middlewares are not aware of decorators, mixins
applied on the request handlers. Therefore, if the middleware is turned on,
there wouldn't be a way to selectively not enforce it. At least not with
decorators/mixins.
The rest framework uses a global setting that applies
Hi everyone,
I've been working as a security researcher for a long time. Common mistake that
I've seen is forgotten decorator and/or Mixin usage on controllers, which leads
to OWASP A5 Broken_Access_Control[1]. I believe one of the most important, as
well as most used, decorator and/or Mixing i
18 matches
Mail list logo
