from:"Stratos Moros"

Re: Drop CSRF middleware from the settings template

2023-04-18 Thread Stratos Moros

In my experience, even SameSite None is not sufficient to use cookies
in cross-site iframes. Safari doesn't allow those cookies to be sent
unless you visit the site directly first. I've heard movements for
Firefox and/or Chrome having similar behavior, but I haven't been
working with iframes recently enough to know the current state of
that.

You are correct about this and I've been bitten by this in the past.
(Un)fortunately, I am currently involved with enterprise™ projects
where Safari is a distant afterthought.

There certainly are legitimate use-cases. I like Jacob's following
suggestion for a check that might help alleviate a misconfiguration
concern, if they did change SameSite to none without activating CSRF
protection. If it were possible to identify other places where there
might be a sharp-edge misconfiguration because of the cross-domain
difference of meaning between samesite and what CSRF needs, that could
be good as well. And those checks would, I think, be worthwhile even
without changing the default, since they are currently possible
configurations.

If CSRF is turned off by default, adding such a check would be a good
idea. It should definitely check for `SESSION_COOKIE_SAMESITE`'s value,
since the session cookie is usually the one that needs protection from
CSRF, but I haven't thought deeply about theotherthe cookies. This could
have implications regarding `HttpResponse.set_cookie`, since it can't be
checked by a system check.

I think what we want to weigh is whether the footgun of *not* having
CSRF by default is bigger than the significant complexity overhead of
managing the CSRF projection in a new project. It's marking all views,
adding tags to all form templates, and I think it can be easy to
underestimate the attention it requires. If we can eliminate this
overhead, especially for beginners starting out with Django and web
development, that sounds like a great benefit. Lowering the barrier to
entry is worth a lot.

I mostly wanted to argue against the removal of the current CSRF
machinery altogether, since it is still necessary for certain use cases.

Removing it from the default template is a harder question. I completely
understand the complexity point, since I've lost track of how many times
I've had to explain what a CSRF error is and why you should care. Still,
I'm not sure if removing it from the default template would be OK, since
it would trade off security for convenience (even if only for marginal
cases).

Best,
Stratos

--
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/A1CC86D7-24E6-457F-9B62-3FD4C82A775C%40gmail.com.

Re: Drop CSRF middleware from the settings template

2023-04-18 Thread Stratos Moros

Hello Everyone,

Looks like lax will do the trick, but it's not like there aren't legit
cases for same-site policy to be set to something less restrictive.

I agree. In my experience there are legitimate cases for setting
SameSite=None, especially concerning iframes.

Specifically, when developing a web app intended to be embedded as an
iframe by a different top-level origin, you can't really use cookies
unless their SameSite attribute is None. This is the case even if you
manage the cookies entirely inside the iframe and its origin.

In such cases, you really do need Django's current CSRF protection.
Personally I wouldn't mind it being off by default, since SameSite=Lax
seems to be enough for most cases, but this could be a footgun for some
people.

Best,
Stratos

On 17 Apr 2023, at 10:55, Jure Erznožnik wrote:

https://security.stackexchange.com/questions/262245/are-csrf-attacks-a-thing-of-the-past

Looks like lax will do the trick, but it's not like there aren't legit
cases for same-site policy to be set to something less restrictive.

LP,
Jure

On 17. 04. 23 09:24, Jacob Rief wrote:

On Monday, April 17, 2023 at 8:45:16 AM UTC+2 Curtis Maloney wrote:

Are you implying that all CSRF attacks protected by Django's
current machinery are entirely mitigated by SameSite=Lax on the
_session_ cookiue?

Yes. Therefore imho, the CSRF protection is just some nasty legacy,
developers have to fiddle with. It doesn't add any security benefit
anymore.
That said, maybe there is still a possible attack vector on cross
site request forgeries, but I was unable to exploit them with
disabled CSRF protection.
Therefore it would be great, if someone with more hacking experience
than myself, could try this.

– Jacob
--
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/18aaa4cf-4612-4373-bd91-90cfb3fd07b8n%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/86ced442-e7f9-aab8-9a03-d9c2362b60f9%40gmail.com.

Re: Add custom autoreload file tracking options setting

2017-01-05 Thread Stratos Moros

I’m -0 on the change. I could move to +0 if I understood why the use 
case described here requires watching additional files.


A different use case we've run into is non-python configuration files. 
Our settings.py reads a few variables off a toml file and it would be 
nice if we could configure runserver to reload automatically when that 
toml file changes.


That said, I agree that auto reloading should probably live outside 
Django.


--
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/D8E34EDB-0BF8-4D78-A567-FB0EE372E631%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Solving the select+1 problem.

2014-06-11 Thread Stratos Moros

Given their sample code, my initial impression was that it was indeed
automatic. Looking a bit closer, there seems to be hardcoded logic
inside the DataSource (the thing I'm assuming provides getAllUserIds and
getUsernameById) to specifically fetch all ids and then all names for
those ids. So they're still doing a manual prefetch_related equivalent
but at a different abstraction level.

I should note that my Haskell knowledge is also minimal, so it is quite
possible that I'm misunderstanding something.

On 11 Jun 2014, at 17:36, Alex Gaynor wrote:

I also do not really know Haskell (I'm sensing a trend...), that said,
it
seems to me the cool part of haxl is that it can be automatic --
analagous

to if writing {{ post.author.name }} in a template caused
select_related("author") to automatically be applied to the queryset
that

yielded post.

Alex

On Wed, Jun 11, 2014 at 6:37 AM, Jacob Kaplan-Moss

wrote:

I'm not great at Haskell, either, but this looks to me to be very
similar

to prefetch_related (
https://docs.djangoproject.com/en/dev/ref/models/querysets/#prefetch-related
).

Jacob

On Wed, Jun 11, 2014 at 6:15 AM, Jonathan Slenders <
jonathan.slend...@gmail.com> wrote:

The "select+1" problem is a problem that people often face in
Django.

Usually, something like select_related solves it, but I don't think
that's always possible.

Facebook released Haxl today and there's an example of their apprach
to

the problem.
https://github.com/facebook/Haxl/tree/master/example/sql

I don't know enough Haskel to understand this code, but it could
contain

some very nice ideas that apply to our ORM as well.

Cheers,
Jonathan

--
You received this message because you are subscribed to the Google
Groups

"Django developers" group.
To unsubscribe from this group and stop receiving emails from it,
send an

email to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to
django-developers@googlegroups.com.
Visit this group at
http://groups.google.com/group/django-developers.

To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/f81a5db1-9777-4cd0-98b7-25b0bc44f498%40googlegroups.com

.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups

"Django developers" group.
To unsubscribe from this group and stop receiving emails from it,
send an

email to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to
django-developers@googlegroups.com.

Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAK8PqJFJoOXVbOX7C7NmhToVsEizD2ZvWCS1vv_LZpfdRv2ayg%40mail.gmail.com

For more options, visit https://groups.google.com/d/optout.

--
"I disapprove of what you say, but I will defend to the death your
right to

say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084

Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAFRnB2UAGp%2BWPJHm_oq9WLFv5yTvtVT5%3Drs6E46WinL49Q%2B1wA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/B3FF8C5C-70FA-4781-95A9-2E06CF618AF2%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using namedtuple instead of pure tuples

2014-02-22 Thread Stratos Moros

Completely unscientific microbenchmarks: 
([gist](https://gist.github.com/stratoukos/dcde41ee0903dcdd577a))

   >>> from timeit import Timer

## creation
# tuple
   >>> Timer('(1, 2, 3, 4, 5)').timeit()
0.02694106101989746

# namedtuple with args
   >>> Timer('T(1, 2, 3, 4, 5)', setup='''
from collections import namedtuple
T = namedtuple("T", "a b c d e")'''
).timeit()
0.773979902267456

# namedtuple with kwargs
   >>> Timer('T(a=1, b=2, c=3, d=4, e=5)', setup='''
from collections import namedtuple
T = namedtuple("T", "a b c d e")'''
).timeit()
1.155663013458252

## item access
# tuple
   >>> Timer('t[0], t[1], t[2], t[3], t[4]', setup='t = (1, 2, 3, 4, 
5)').timeit()

0.3240630626678467

# namedtuple with indices
   >>> Timer('t[0], t[1], t[2], t[3], t[4]', setup='''
from collections import namedtuple
T = namedtuple("T", "a b c d e")
t = T(1, 2, 3, 4, 5)'''
).timeit()
0.2994410991668701

# namedtuple with attributes
   >>> Timer('t.a, t.b, t.c, t.d, t.e', setup='''
from collections import namedtuple
T = namedtuple("T", "a b c d e")
t = T(1, 2, 3, 4, 5)'''
).timeit()
0.9363529682159424

It seems that the only significant slowdown is on a namedtuple's 
creation. I imagine the impact would be negligible on a complete 
request-response cycle, but that would have to be tested.

Accessing a namedtuple's items using attributes is also somewhat slower, 
but this wouldn't be a problem. Existing code would continue to work 
with the same performance and users could decide for themselves which 
way to access a namedtuple's items for new code.

On 22 Feb 2014, at 18:37, Florian Apolloner wrote:

On Saturday, February 22, 2014 5:24:39 PM UTC+1, Adam Kaliński wrote:

What do you guys think?

Sounds good, you might check if namedtuple has negative performance 
effects
(I doubt it, but who knows). The reason we didn't add it yet is that 
it

just exists since 2.6.

cheers,
Florian

--
You received this message because you are subscribed to the Google 
Groups "Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to 
django-developers@googlegroups.com.

Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/61b1a5f0-1d1c-480d-87cd-639c728327a7%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/699D6AD0-A3F2-425A-805D-8376098707B4%40gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSoC 2012] Enhanced contrib.auth

2012-04-04 Thread Stratos Moros

On Wed, 04 Apr 2012 19:25:26 +0300, Adrian Holovaty   
wrote:



Hi Stratos,

The core team is going to take the lead on the auth.User refactoring
-- specifically, yours truly. :-)

Given that the Summer of Code policy prohibits code contributions from
non-students (right?), I don't think the User refactoring would work
as a Summer of Code project. Sorry to break this news, as you've
clearly done a lot of preparation and thinking about the issue, but of
course we'd love to have you contribute to this particular feature
*outside* the Summer of Code.

Adrian



Ok. I'd love to contribute either way.

Thanks for the info.

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: [GSoC 2012] Enhanced contrib.auth

2012-03-30 Thread Stratos Moros

On Fri, 30 Mar 2012 17:35:16 +0300, Tom Evans <tevans...@googlemail.com>  
wrote:


On Fri, Mar 30, 2012 at 10:39 AM, Stratos Moros <stmo...@gmail.com>  
wrote:

You can read the proposal nicely formatted here:
https://gist.github.com/8dd9fb27127b44d4e789


Hi Stratos

It's a long proposal, so this is a brain dump of bits that I find
interesting/worrisome.


Hi Tom.

I'm answering your 3 questions together because they are related to each  
other.


In my proposal, a user model represents an authentication/authorization  
scheme. This is why you have to mixin the authentication scheme directly  
in the model. All other information, such as first_name, last_name etc.  
should live in the user's profile.


The idea isn't to remove custom profiles, but to let developers control  
where they're used. The example I provided about adding custom profiles  
was rather bad. The way I expect most developers to add a fields to a user  
is:


class CustomUser(SomeMixins):
profile = models.ForeignKey(UserPorfile)

This way you can allow your frontend users to log in with, say, either  
with username & password or openid and have a single profile between them,  
while allowing your backend users to login with credentials from an LDAP  
server and have a different profile for them.


This is why authentication backends are deprecated. If you can't specify  
which authentication mechanism is used for each user model, you can't  
easily accomplish the above scenario. You would have to have a single  
table to represent the two different profiles and you would somehow make  
sure that a user trying to log in with facebook doesn't go through the  
LDAP server.


This is also why the identity in the user model is a method and not a  
field. If you want a single user to be authenticated in multiple ways, you  
can override the identity method and return the same value.


Perhaps the profile field should be made part of the user contract, but  
this would be an annoyance in cases where you don't want to store any  
additional information about the users, but use them only for  
authorization purposes (ie. I don't care about his info, I just want to  
know if he can access this page).


Having login and logout be part of the user model was one of the things  
that I wasn't sure about. The reason I put them in the user model is to  
decouple the whole process from the session. This way an authentication  
scheme that doesn't want to use the session to store a logged in user can  
do so. The common case would obviously be to store them in the session, so  
I included the SessionAuthenticationMixin.


The same goes for authorization. Inheriting from a mixin implementing the  
authorization contract would probably add a foreign key to the table  
storing the permissions plus a few methods to query it. This way you can  
handle different user models' permissions in completely different ways.


Thanks for the feedback. I hope I've answered your questions.

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

[GSoC 2012] Enhanced contrib.auth

2012-03-30 Thread Stratos Moros

You can read the proposal nicely formatted here:  
https://gist.github.com/8dd9fb27127b44d4e789


GSoC 2012 Proposal - enhanced contirb.auth
==

Hello, my name is Stratos Moros and I am a Computer Science student in the  
University of Piraeus in Greece.


I would like to participate in Google Summer of Code with Django, working  
on an enhanced contrib.auth.


Goals
-

-   Long term solution

	The proposed replacement doesn't aim at just improving some of the  
current limitations of contrib.auth (e.g. increasing the email field  
size), but at providing a long term solution.


-   Backwards compatibility

	The new contrib.auth will be 100% backwards compatible with the current  
implementation. Developers updating their existing Django installation  
will have the same features available, without having to update their code  
or undergo a database migration.


-   Separation of concerns

	The concepts of identity, authentication and authorization should not be  
tightly coupled by default. Developers will be able to mix and match  
schemes if they want, or use a more integrated approach otherwise.


-   Extensibility

	It's impossible to cover all existing and future authentication /  
authorization schemes. Developers who have needs that aren't covered by  
Django should be able to extend contrib.auth by writing their own or using  
third party user models. Other apps that need to interact with users (e.g.  
a commenting app) will be able to interact with them without knowing the  
specific implementation.


-   Batteries included

	Developers will not be required to implement their own authentication or  
authorization schemes for the common cases. Contrib.auth will have one or  
more built in user models ready for production.


-   Admin compatibility

	Contrib.admin is one of the things that make Django great. It should be  
easy for developers to make their user models accessible through the admin  
interface.


Terminology
---

In order to distinguish between Django's users, a website's users and the  
proposed concept of a user, the terms "developer", "visitor" and "user"  
are used respectively.



Implementation
--

The new contrib.auth will serve three primary functions:

-   Assist developers in writing custom user models.
-   Provide built in user models.
-   Provide a way for developers to interact generically with user models.

The new contrib.auth will allow developers to specify multiple user  
models. A new setting will be introduced called `USER_MODELS` which will  
be a tuple of strings. Each string's format will be `'%(app).%(model)'`,  
similarly to how `AUTH_PROFILE_MODULE` is currently defined. This setting  
will look something like:


USER_MODELS = (
'auth.EmailUser',
'myapp.CustomUser',
# ...
)

### Separation of concerns and the user contract

A user model will be a regular model that fulfills a predefined contract.  
Developers will be able to write their own user models in their  
applications and register them through the `USER_MODELS` setting. Any  
model that fulfills the user contract and is specified in `USER_MODELS`  
will be considered a valid user model. The contract will be subdivided in  
three subcontracts that will be concerned with identity, authentication  
and authorization.


 Identity

The identity contract will answer the "who are you" question for a user  
model. This could be anything from a twitter handle to a biometric  
identifier, or anything else that can uniquely identify a user in a user  
model. To fulfill the identity contract the user model will have to:


-   Implement an `identity` method.

	This method must return a string that uniquely represents a user in a  
user model.


-   Implement a `get_by_identity` method on the model's default manager.

	This method must accept a string representing a user, as returned by the  
`identity` method, and return the either a user object, if it finds one,  
or `None` otherwise.


-   Implement a `__unicode__` method.

	This method must return a string representation of a user that is  
suitable for displaying on the frontend. This will not be required to be  
unique across all users in a user model.


 Authentication

The authentication contract will be concerned with verifying that the user  
is indeed who he claims to be. Again, this could be anything from a  
password to a hardware dongle. To fulfill the authentication contract the  
user model will have to:


-   Implement an `is_authenicated` method.

	This method must accept a request. Contrary to the current  
implementation, the `is_authenticated` method will not always return  
`True`. It is up to the implementation to decide whether the user is  
actually authenticated.


-   Implement an `is_authenticated_b

Re: auth.User refactor: reboot

2012-03-16 Thread Stratos Moros


Hello,

I'm also interested in working on an enhanced auth.user as a GSoC project  
and I'm currently working on my proposal. My proposal is largely based on  
pluggable auth models.


What I'm seeing is that most people are generally negative to the idea,  
including core developers and django-developers' regulars. I have also  
read through the comments of ticket #3011 and the linked Google  
spreadsheet[1] where the idea was eventually rejected for 1.1. Moreover,  
Django's GSoC 2011 page (but not the one for 2012) specifically mentions  
that the idea has been rejected.


That said, I believe that my proposal, when completed, will address most  
of the issues people are raising against the idea of pluggable user models.


My question is whether I should continue writing/developing my proposal or  
is this something that has no chance of being accepted?


Thanks.

Stratos Moros

1: http://spreadsheets.google.com/ccc?key=pSqnCvef6OXmGWQ9qbEVMeA

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Drop CSRF middleware from the settings template

Re: Drop CSRF middleware from the settings template

Re: Add custom autoreload file tracking options setting

Re: Solving the select+1 problem.

Re: Using namedtuple instead of pure tuples

Re: [GSoC 2012] Enhanced contrib.auth

Re: [GSoC 2012] Enhanced contrib.auth

[GSoC 2012] Enhanced contrib.auth

Re: auth.User refactor: reboot

9 matches

Site Navigation

Mail list logo

Footer information