Re: Thank you to our security aware developers

[Ryan McIntosh]

One use might be to make it available to client side UI.  If the value were 
changed to a different value that was still acceptable, you might want to allow 
that in some circumstances in order to facilitate different UI options.

Ryan

- Original Message -
From: "Pedro J. Aramburu" 
To: django-developers@googlegroups.com
Sent: Thursday, 6 December, 2012 11:06:38 PM
Subject: Re: Thank you to our security aware developers

So, I don't understand one thing. If it's checking the validity on the 
backend of a hidden field in the frontend, that should mean that the 
backend should have the original (or proper) value of the frontend so why 
does it have that hidden field on the first place?


El viernes, 30 de noviembre de 2012 20:03:09 UTC-3, Chris Cogdon escribió:
>
> I want to give a big "thumbs up" to the folk that worked on 
> InlineForeignKeyField, inlineformset_factory, and their friends.
>
> I just used inlineformset_factory for my project, saw that it was writing 
> the parent id out into hidden form variables and, thinking that this seemed 
> "unnecessary" and a possible vector for an attack. Ie, anything that's in 
> the hands of the end-user should never be trusted. 
>
> So, I faked up a page that had all the proper stuff, but changed one of 
> the IDs in the hidden field to point to a different parent, and submitted. 
> I got: "The inline foreign key did not match the parent instance primary 
> key."
>
> Woot! Very good. Thank you, guys!
>
> The only nit I'd have about this is that (I think) this error message 
> should never occur, and if it does, something is wrong that is outside the 
> hands of a (normal) end-user. Something less "you did something (too 
> complex to understand) wrong" would likely be better , such as:
>
> "Web-site internal error. Inline foreign key mismatch."
>
> To an end-user that seems like enough programmer-ese that they'll not try 
> hunting to figure out what _they_ did wrong.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/SoZ4rkeWrnMJ.
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.

-- 
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: SOPA bill question

[Ryan McIntosh]

You're right of course, James.  There's not anything django-development related 
that can be done.  But there are a lot of bright minds reading this list and 
most of the subscribers on this list appreciate that there's a difference 
between off-topic noise and something that is actually soap-box worthy.  But 
the mission is accomplished now that the word has gone out.

If you want to actually do something, get on it.  If you just want to pull out 
your hair and talk about how much "you wish someone would do something" than 
that's another matter.

If django needs to be hacked on to add support for decentralized domain 
registration or to include some additional DNS related support that comes out 
of the SOPA workarounds, I'll be the first to submit a patch.

/Climbs down from soap box.

peace,

Ryan McIntosh
Software Architect
PeaceWorks Technology Solutions
ph: (204) 480-0314
cell: (204) 770-3682
r...@peaceworks.ca

- Original Message -
From: "James Bennett" <ubernost...@gmail.com>
To: django-developers@googlegroups.com
Sent: Wednesday, December 28, 2011 11:07:53 AM GMT -06:00 US/Canada Central
Subject: Re: SOPA bill question

Folks, we've had three different members of core point out that,
important as it is, this is a topic for another list/forum. Please
take the discussion there, now.



-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

-- 
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.

-- 
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: Queries about CSRF design following penetration test

[Ryan McIntosh]

Good morning,

I have also looked into this mechanism and I wanted to add to the discussion.  
Many of my thoughts regard not simply Django's "stock" behavior, but the ease 
with which a developer may unexpectedly expose their work to security 
vulnerabilities.

One important note to remember is that an application _can_ inject a CSRF 
cookie above the domain via settings.CSRF_COOKIE_DOMAIN, 
settings.CSRF_COOKIE_PATH and settings.CSRF_COOKIE_SECURE.

This places a great onus of responsibility on the developer to ensure that this 
cookie is never leaked or set above an appropriate domain.

An example where this is dangerous would be a site with multiple subdomains 
using the same django instance and multiple applications to serve the same 
site.  Because the cookie is available to client side applications as well as 
server side applications which are potentially outside the developer's control, 
a potential to exploit or leak the CSRF is present if the aforementioned 
settings are not secure.

A new token isn't generated for each request because in the case of an 
application exception, it's important to not leave the user stranded.  This 
could be worked around by storing a set of valid CSRF tokens at the database 
level and expiring them as needed.  Potentially, this would be a good way to 
expire CSRF tokens prior to the cookie expiration as well - while at the same 
time ensuring the session hasn't been hijacked.  Such a middleware seems to be 
what Dr. Winterbottom is looking for to resolve his security concerns.  The 
implementation would be rather straightforward as well.  Is there value right 
now in developing something like this for the community at large?

peace,

Ryan McIntosh
Software Architect
PeaceWorks Technology Solutions
ph: (204) 480-0314
cell: (204) 770-3682
r...@peaceworks.ca

- Original Message -
From: "David Winterbottom" <david.winterbot...@tangentlabs.co.uk>
To: django-developers@googlegroups.com
Sent: Thursday, December 1, 2011 3:19:27 PM GMT -06:00 US/Canada Central
Subject: Queries about CSRF design following penetration test

All,

A site I work on was penetration tested this week and several queries were
raised about the site's (and hence Django's) CSRF implementation.  The
points seem valid to a degree but I wanted to check if there were design
decisions behind the current implementation.

Note, we're using Django 1.3.1.

*CSRF tokens are not generated per-request or with a max age*
Django's CSRF token is only generated when the cookie is not found, and as
the cookie is set to a max age of a year, the token remains the same
between requests (and visits).  Is there a reason why a new token isn't
generated for each request?  I appreciate that this doesn't really open up
a huge security hole, but it does differ from OWASP's recommendations:
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)

The security company also recommend that the CSRF token should have a
maximum age so that it expires if you wait too long.

*No server-side check of the CSRF token*
Basically, as long as the cookie token matches the form token, the request
is valid - even if they differ from what was set originally.  I found some
previous discussion of this (
http://groups.google.com/group/django-developers/browse_thread/thread/571e875c9c4b806f/7ece8e94d48f6586?lnk=gst=csrf#7ece8e94d48f6586)
and it seems that setting a CSRF cookie can only be done from a site with
the same top-level domain.  Hence, this is only an issue if someone
malicious controls a subdomain.  In their examples, they are hand-crafting
the HTTP request to spoof this but I guess that is not representative of
what can be done via a browser-based CSRF attack.  How much of a security
issue is this?

I'm happy to share the relevant pages of the report if anyone's interested.

All thoughts appreciated.

-- 
*Dr. David Winterbottom*
Head of Programming

Tangent Labs
84-86 Great Portland Street
London W1W 7NR
England, UK

-- 
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.

-- 
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: queryset caching note in docs

[Ryan McIntosh]

I think the discussion actually went a bit sideways.  Is there value in a model 
method to return an iterator which pulls results from a temporary table that 
gets filled from a model query?  This puts the onus on the django-user to use 
the correct method.

Model.foo().bar().buffered() or .from_tmp()

peace,

Ryan

- Original Message -
From: "Marco Paolini" 
To: django-developers@googlegroups.com
Sent: Wednesday, November 2, 2011 12:11:41 PM GMT -06:00 US/Canada Central
Subject: Re: queryset caching note in docs

On 02/11/2011 17:33, Tom Evans wrote:
> On Wed, Nov 2, 2011 at 4:22 PM, Marco Paolini  wrote:
>> On 02/11/2011 17:12, Tom Evans wrote:
>>> If you do a database query that quickly returns a lot of rows from the
>>> database, and each row returned from the database requires long
>>> processing in django, and you use mysql_use_result, then other mysql
>>> threads are unable to update any table being used, where as if you do
>>> the same thing with mysql_store_result, the tables are unlocked as
>>> soon as the client has retrieved all the data from the server.
>>>
>> other connections in other transactions are locked too?
>
> Yes. The exact wording from the C API:
>
> """
> On the other hand, you shouldn't use mysql_use_result() if you are
> doing a lot of processing for each row on the client side, or if the
> output is sent to a screen on which the user may type a ^S (stop
> scroll). This ties up the server and prevent other threads from
> updating any tables from which the data is being fetched.
> """
>
> mysql treats the table as in use until the result is freed.
>
> If this behaviour was in place, then you wouldn't have even raised the
> original query - the approach you were using was to iterate through a
> result set and modify the table you are fetching from. With
> mysql_use_result, you would have deadlocked that table in the mysql
> server as soon as you tried to update it without first completing the
> first query.
Yeah, the discussion has drifted a bit from it's staring point

so, summarizing again:
  - mysql supports chunked fetch but will lock the table while fetching is in 
progress (likely causing deadlocks)
  - postgresql does not seem to suffer this issue and chunked fetch seems 
doable (not trivial) using named cursor
  - oracle does chunked fetch already (someone confirm this, please)
  - sqlite3 COULD do chunked fetch by using one connection per cursor 
(otherwise cursors will not be isolated)

Marco

-- 
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.

-- 
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: deprecation vs removal

[Ryan McIntosh]

As someone maintaining some very old django sites with hacks to the core, 
deprecation warnings are very useful to me.  I know I'm not alone.  There is no 
reason to not flag deprecated methods/functions/routines/etc prior to removal.

If you're being nagged by deprecation warnings than... well... That's the point!

The annotation "Will be deprecated" is also useful.  

Change requires care, IMHO.

Many hackers on this list continually work on the latest version.  Many don't.

peace,

Ryan McIntosh
Software Architect
PeaceWorks Technology Solutions
ph: (204) 480-0314
cell: (204) 770-3682
r...@peaceworks.ca

- Original Message -
From: "Alexander Schepanovski" <suor@gmail.com>
To: "Django developers" <django-developers@googlegroups.com>
Sent: Sunday, October 2, 2011 12:48:38 AM GMT -06:00 US/Canada Central
Subject: Re: deprecation vs removal

> It allows you the luxury of taking the time,
> and encourages you to upgrade even if you don't have time to make
> application changes.

It doesn't really saves time for me. But maybe I'm an uncommon case.
Some of things I do with django are pretty tied up to its internals.

But even a common user, who himself doesn't hack into django may use
third-party libs that do: migration, automatic caching, any orm, form
and template extenders. And for the developers of that libs
deprecation is a waste not help, at least what it feels for me. For
common user this means he cannot upgrade until all hos libs upgraded
or he himself is forced into hacking them.

So dropping deprecation could be a strategic win in a sense it will
help django infrastructure flourish. At least this is worth
considering.

-- 
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.

-- 
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: Timezone-aware storage of DateTime

[Ryan McIntosh]

 > ... but if django were going to do so, it ought to store the datetimes
with the timezone information intact, rather than converting everything to
the project's timezone. So, if a conversion to UTC were to take place, there
would need to be a separate field in the database to store the timezone.

Is that a crutch of your database?  It isn't something I would ever live
with.  All the *sql database servers I hate have an idea of what a
timestamp+offset is.  Django should leverage this.  IMHO, no such field
should exist in the underlying database but for ticks since epoch if tzs
aren't supported...  Everything useful should be derived if necessar...

I apologize for entering tardis y *con mas fortis* allah.  I have been
following for a bit and honestly, if other devs on this thread don't step
up, I will.  [Here] be *silly* dragons

No pointing fingers though... ;-)

On Wed, Jun 29, 2011 at 4:27 AM, Daniel Swarbrick <
daniel.swarbr...@gmail.com> wrote:
> On Jun 28, 3:26 pm, Stephen Burrows 
> wrote:
>> I agree that it would be nice to be able to store tz-aware datetimes -
>> but if django were going to do so, it ought to store the datetimes
>> with the timezone information intact, rather than converting
>> everything to the project's timezone. So, if a conversion to UTC were
>> to take place, there would need to be a separate field in the database
>> to store the timezone.
>
> As I've already illustrated earlier in this thread, storing the TZ
> with the timestamp in a DB that will treat it as a text string (such
> as SQLite) is going to break chronological SQL sorting. Perhaps
> contrary to popular misconception, Postgres does not store the TZ in
> "timestamp with time zone" fields. They are normalized to UTC and
> stored as Julian dates. The TZ is interpreted on input of a timestamp
> value, if the entered value is being specified in a TZ other than the
> client connection's current TZ. The TZ is also displayed in a SELECT
> of a timestamp field - but the TZ is that of the client connection,
> not that of the originally inserted value.
>
> Storing the TZ in a separate field is going to get pretty nasty for
> sorting as well, as the query will have to somehow concatenate or
> compute together the two fields before applying the sorting algorithm.
>
> I think the best way to handle multi-TZ timestamps is the way that
> Unix and other multi-user, multi-timezone OSes have been doing it for
> decades (mostly wrt to filesystems) - respect the TZ of the client
> inputting the data, normalize to a common TZ (usually UTC) and store
> as such. Perform all sorting and timestamp comparison/arithmetic in
> that single, normalized TZ. Upon output, render the value in the
> client's TZ.
>
> ...and that is essentially what Postgres does.
>
> --
> 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.
>
>

-- 
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: Design design needed: #14093 - Unable to create a new session key on higher traffic

[Ryan McIntosh]

Hi,

This could be done as an optional configuration with a hardcoded default of 
1.  Since no configuration change is necessary to retain original behavior, 
than would this still qualify as a feature change?

I think I will weigh in on one aspect of this as I have run into this problem 
before.  The side effect is as you describe until traffic increases further.  
At that point, users may not be able to login successfully until traffic 
subsides.  "Minor issue" could be relative.

peace,

Ryan McIntosh
Software Architect
PeaceWorks Computer Consulting
ph: (204) 480-0314
cell: (204) 770-3682
r...@peaceworks.ca

- Original Message -
From: "Tim Graham" <timogra...@gmail.com>
To: "Django developers" <django-developers@googlegroups.com>
Sent: Tuesday, 8 February, 2011 08:48:09 GMT -06:00 US/Canada Central
Subject: Design design needed: #14093 - Unable to create a new session key on 
higher traffic

Hi,

I wanted to raise this ticket for discussion as to what the best
solution might be.  As suggested in the ticket, I think adding a
setting to control the number of cache attempts instead of hard-coding
"1" might be a reasonable approach.  I'm not sure if that solution
would be considered a "feature addition" (adding a new setting) and
thus not appropriate for this stage of the release cycle.

Has anyone else experienced the issue and devised a workaround?  It's
a minor issue since the side-effect seems to be that the login
silently fails and a user must retry.

Thanks,
Tim

-- 
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.

-- 
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: How To Create A Form With Generic Relations In Django

[Ryan McIntosh]

SuperForm(ProjectForm, TodoForm):
  pass
  #stuff

peace,

Ryan McIntosh
Software Architect
PeaceWorks Computer Consulting
ph: (204) 480-0314
cell: (204) 770-3682
r...@peaceworks.ca

- Original Message -
From: "Harry" <glazed...@gmail.com>
To: "Django developers" <django-developers@googlegroups.com>
Sent: Friday, 24 September, 2010 10:17:02 GMT -06:00 US/Canada Central
Subject: How To Create A Form With Generic Relations In Django

Hi,

How can I create a Form with normal form elements and generic elements
together as ModelForm For using frontend CRUD.

For example;

Generic Model:

class Todo(models.Model):
  user = models.ForeignKey(User, related_name="todo")
  title = models.CharField(max_length=100, unique=False)
  slug = models.SlugField(max_length=50)
  completed = models.BooleanField()
  created_at = models.DateTimeField(auto_now_add=True)
  updated_at = models.DateTimeField(auto_now_add=True)

  content_type = models.ForeignKey(ContentType, related_name="todos")
  object_id = models.PositiveIntegerField()
  content_object = generic.GenericForeignKey()


And other model:

class Project(models.Model):
  user = models.ForeignKey(User, related_name="project")
  title = models.CharField(max_length=255, unique=True)
  slug = models.SlugField(max_length=50)
  description = models.TextField()
  active = models.BooleanField()
  created_at = models.DateTimeField(auto_now_add=True)
  updated_at = models.DateTimeField(auto_now_add=True)

  # Generic relation with Todo model
  todo = generic.GenericRelation(Todo)


Forms:
Created a formset for making Todo inline for Project and passed
formset to form template. But its not merged with ProjectForm when
render form.

  from django.contrib.contenttypes.generic import
generic_inlineformset_factory
  TodoFormSet = generic_inlineformset_factory(Todo, extra=1)
  formset = TodoFormSet(instance=Project())


Now if I create a ModelForm,

for project: (project/create urlpattern, with this i can get
ProjectForm to produce form)
for todo: (project/todo/create urlpattern, with this i can get
TodoForm to produce todo)

How to i do ProjectForm inline TodoForm form? and produce new
ProjectForm?

Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.