Re: Status of 3.2 release blockers.

ably the easiest thing is to leave it in place and make it well-defined, or to deprecate `is_dst` in favor of a new argument like `preferred_fold` that uses the semantics of folds instead of the semantics of DST. Best, Paul On Tue, Jan 12, 2021 at 12:48 PM Paolo Melchiorre wrote: > I agree with A

Re: Status of 3.2 release blockers.

ent in the first place. I do think it would be good to make it possible for people to do /some/ conversion over ahead of time if possible, particularly since no deprecation warnings will be issued prior to the change away from pytz. Best, Paul On 1/12/21 10:12 AM, Carlton Gibson wrote: > Hi a

Participation in GSoC 2021.

Hey guys, I'm new to the whole Google Summer of Code program. I would like to be able to contribute to Django for GSoC 2021. If possible, please offer me some guidance on what steps I need to take to accomplish this. Any help would be greatly appreciated. -- You received this message because you

Re: Proposal: Drop dependency on pytz in favor of zoneinfo

ich is also the case, though to a lesser extent, with the faster plan). In any case, it seems uncontroversial that 3.2 should support "bring your own zoneinfo", and I think most people agree that a feature flag in 3.2 is also a good idea, so to the extent that I have time to work on this, I

Re: Proposal: Drop dependency on pytz in favor of zoneinfo

eprecation_shim/_impl.py#L265> > is essentially a noop. Paul, couldn't it actually attempt to adjust > the time the way pytz does? Perhaps by wrapping pytz itself, and > calling its normalize() from the corresponding pytz timezone; or by > simply replicating its time-changing l

Re: Proposal: Drop dependency on pytz in favor of zoneinfo

plies in certain situations. It would be a lot easier to not notice the change until you see a bug caused by it showing up in production. On the other hand, people not testing for this adequately may not realize that the semantics are different than most people think, so they  might have the same bu

Re: Proposal: Drop dependency on pytz in favor of zoneinfo

ahead of me I don't mind at all and feel free to ping me for review. Best, Paul On 10/7/20 10:48 AM, Carlton Gibson wrote: > Hi Paul.  > > Thanks for the input here, and for your patience  > > > I am fairly certain this is going to be a tricky migration and will > inevit

Re: I need a mentor on django

You can visit https://wsvincent.com/, my personal blog https://manascode.com or https://simpleisbetterthancomplex.com/ On Thursday, 11 June 2020 00:45:40 UTC+5:30, Onayemi Hakeem wrote: > > Okay if that is the case I agreed I've been in the wrong mailing list can > you

Re: Proposal: Drop dependency on pytz in favor of zoneinfo

igration, since even pytz's UTC object can be directly attached to datetimes. Right now, I think the obvious first step is to add /support/ for deliberately using zoneinfo / datetime.timezone. This can be done in a perfectly backwards compatible way, so there's no point in delaying.

Proposal: Drop dependency on pytz in favor of zoneinfo

cumentation on stability, but it suffers from the same problems that SemVer in general suffers from (and that there's no avoiding, really), which is that breaking changes are in the eye of the beholder. I leave it to y'all to decide the roll-out schedule for this stuff (assuming it's acc

GSOC 2020

Hello, I hope this email finds you well. My name is Kelyn Paul. I am really interested in applying to Django for GSOC. May you please let me know what are the next steps? Best regards, Kelyn Paul Njeri. -- You received this message because you are subscribed to the Google Groups "D

Re: Proposal: local timezone-aware datetime fields in the admin site

ith "Windows (which, I'm afraid, has its own time zone name)"? I haven't got around to testing locales, I'll report back once I do that. On Wednesday, October 3, 2018 at 11:10:26 PM UTC-7, Aymeric Augustin wrote: > > Hello Paul, > > Yes, if that works, it woul

Proposal: local timezone-aware datetime fields in the admin site

Timezone handling in the Django admin is quite confusing for users when the users are in multiple timezones, because everything in the admin site operates in the server's time. Assuming USE_TZ=True, TIME_ZONE='UTC', USE_I18N, USE_L10N, when viewing a datetime field, users see the UTC time, with

Re: default values on database level

that just implements the simple `db_default` field without attempting PostgreSQL RETURNING or database functions (CURRENT_TIMESTAMP), and just provides static defaults? Cheers, Paul On Monday, April 4, 2016 at 2:08:39 AM UTC-7, Shai Berger wrote: > > Hi everybody, > > Waking t

Setting defaults in the DB to support zero-downtime migrations

advance for being unable to locate that thread; I'd be interested in any thoughts around this. Cheers, Paul -- 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

Re: Allow extra blank rows for adding new records when using list_editable in admin change list view.

I would love to see this change implemented as well. I have a few models that would benefit from having a quick entryline at the bottom of the list_display. Personally, I think that the first possibility, where only the items that are in the 'list_editable' tuple would be editable in the blan

In-memory queryset

nothing like this exists? Is it because it's a terrible idea for a reason that's not obvious to me? Would it not be awesome for the API for interacting with collections of in-memory instances and with a database-backed collection to be the same? Many thanks, Paul -- You received th

Re: Added signals that runs when adding an object to a Many-To-One relation

Good to know. Thanks, Paul On Fri, Feb 3, 2017 at 10:03 AM, Oskar Persson wrote: > No, the save method isn't called unless you specify bulk=False > <https://docs.djangoproject.com/en/1.10/ref/models/relations/#django.db.models.fields.related.RelatedManager.add> > > Den

Re: Added signals that runs when adding an object to a Many-To-One relation

I thought a Many-To-One would not require an intermediate table, so it would be caught by pre-save and post-save on the object containing the Foreign Key. Is that not true? Paul On Fri, Feb 3, 2017 at 8:28 AM, Oskar Persson wrote: > Hi everyone. > > I've created a pull request (

Re: DEP pre-proposal for a simpler URLs syntax.

Actually, we do something very similar to this in a routes.py for a flask app. Except instead of "pass" we call a function that has been imported. Paul *Flask* > Doesn't really have the idea of putting all your routes in one spot. So > pardon the silly example. > >

Re: Better form fields for django.contrib.postgres.fields

*OK thanks for the replies. The first enhancement would be a change in how choices are handled for the ArrayField. With this change,* *choices would be based on the base field. If choices keyword argument is given, a multiple choice field is used and the array value will be composed* *of thes

Better form fields for django.contrib.postgres.fields

Hi, This is my first time contributing to Django. It's a lot of different features in one to improve how form fields are produced for ArrayField, HStoreField and JSON FIeld. I opened a ticket here with more details and a screenshot of the admin for a sample model. https://code.djangoproject.c

'DatabaseWrapper' object has no attribute 'pattern_ops' DJango 1.8.3

Getting the error below when I run DJango test please let me know the reason behind this .Thanks You = ERROR: test_patterns_escape (expressions.tests.ExpressionsTests)

L118 errros

I am getting following errors when I am tried DJango 1.8 test cases against DB2 .What can be the cause for this ?. Can someone comment on this please . == FAIL: test_decimal_numbers (utils_tests.test_numberformat.TestNumberFormat

Re: ValueError: Available apps isn't a subset

talled)) ValueError: Available apps isn't a subset of installed apps, extra apps: fixtures_model_package On Thursday, October 29, 2015 at 6:19:42 PM UTC+5:30, Tim Graham wrote: > > What command are you using to run the tests? It is possible you have stale > pyc files that needed to b

ValueError: Available apps isn't a subset

I am getting following error when I tried to run DJango 1,8 test cases Please help to understand the reason behind this . ERROR: test_reuse_rollback_commit (transactions.tests.AtomicInsideTransactionTests) -- Traceback (most r

Re: Ticket 2273: django.contrib.auth.models.User: username is case-sensitive

itive manner. On Wed, Oct 21, 2015 at 3:39 PM, Shai Berger wrote: > Hi, > > On Thursday 22 October 2015 00:01:24 Paul Egges wrote: > > Perhaps I'm missing something, but this would not change current users, > > only the creation of new users. It seems that logins would still

Re: Ticket 2273: django.contrib.auth.models.User: username is case-sensitive

Perhaps I'm missing something, but this would not change current users, only the creation of new users. It seems that logins would still be case sensitive. It would just prevent new users from being created that would match in a case insensitive manner with an existing user. For example existing us

Re: DJango 1.8 test case fails with IntegrityError error

Hi Shai, interprets_empty_strings_as_null is set to False Regards, Jose On Tuesday, September 22, 2015 at 5:39:14 PM UTC+5:30, Shai Berger wrote: > > On Tuesday 22 September 2015 09:39:17 Jose Paul wrote: > > Dear All, > > > > I am trying to run DJango

Re: DJango 1.8 test case fails with IntegrityError error

Hi Shai, interprets_empty_strings_as_null is set to False Regards, Jose On Tuesday, September 22, 2015 at 5:39:14 PM UTC+5:30, Shai Berger wrote: > > On Tuesday 22 September 2015 09:39:17 Jose Paul wrote: > > Dear All, > > > > I am trying to run DJango

DJango 1.8 test case fails with IntegrityError error

Dear All, I am trying to run DJango 1.8 test cases with DB2 Several insert statement fails Here is the insert command generated by test case. INSERT INTO "AUTH_USER" ("PASSWORD", "LAST_LOGIN", "IS_SUPERUSER", "USERNAME", "FIRST_NAME", "LAST_NAME", "EMAIL", "IS_STAFF", "IS_ACTIVE", "DATE_JO

Re: Drop the TEMPLATE_DEBUG setting

+1! On Sunday, February 15, 2015 at 2:16:25 PM UTC, Aymeric Augustin wrote: > > Hello, > > During the multiple template engines refactor, I didn’t touch > TEMPLATE_DEBUG. > The only purpose of this setting is to control whether Django stores the > information required to display stack traces for

Re: CSRF REASON_NO_REFERER with meta referrer tags

rrer metatag also influences the origin header - if it doesn't, fixing the ticket mentioned above would make most of your concerns go away. Regards, -Paul -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" g

Re: CSRF REASON_NO_REFERER with meta referrer tags

radeoff we have right now. -Paul On Tue, Feb 3, 2015 at 9:43 PM, Jon Dufresne wrote: > On Tue, Feb 3, 2015 at 11:52 AM, Aymeric Augustin > wrote: >> You can fix that problem by saving some authentication info in the user's >> session, most likely with a custom a

Re: Updating the organization of the Django Project

+1 Thanks for your hard work, Aymeric. -Paul On Wed, Jul 23, 2014 at 12:25 PM, charettes wrote: > +1 > > Thanks for putting this up together Aymeric > > Simon > > Le mercredi 23 juillet 2014 09:30:13 UTC-4, Aymeric Augustin a écrit : >> >> Hello, >&g

Flag Field Type Feature Request

flag in value else '0', self.flags)) def formfield(self, **kwargs): defaults = {'form_class': MultipleChoiceField, 'widget':CheckboxSelectMultiple, 'choices':map(lambda f: (f, f), self.flags)} defaults.update(kwargs) return super(FlagField, self).formfi

Re: New contributor and Git

Thanks, Daniele. That looks like good reading. I'm making changes to templates/builtins.txt. I can make the html files and preview my changes in my browser. Seems to me it would make sense to contribute just a few changes as a test of submission procedures. Is that a good idea? ~~

Re: New contributor and Git

That appears to have done the trick. Thanks! ~~ Paul -- 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...@googlegrou

New contributor and Git

icity of host 'github.com (204.232.175.90)' can't be established. So instead I cloned it according to the instructions in "Writing Documentation," which seemed to work. It specifies the following command: git clone git://github.com/Paul-C-Anagnostopoulos/django.git django-trunk T

Re: Proposal: Modifying the CSRF protection scheme

I agree with Jacob on both points. +1 from me, especially since neither of these changes should require changes in application code which is already using the interface correctly. -Paul On Tue, Jul 30, 2013 at 1:22 PM, Jacob Kaplan-Moss wrote: > Hey Shai - > > I have no objection

Re: #3011 - Custom User Models -- Call for final review

g both together by default, developers who have never considered the fact that the two concepts can be separate will do the right thing, and the 90% case for the rest of us of "I need both together" is also met. -Paul -- You received this message because you are subscribed to the Google Groups

Re: preventing 'csrftoken' cookie fixation attacks

alternate CSRF middleware implementation: https://github.com/mozilla/django-session-csrf As always, when reporting potential security problems, please use the secur...@djangoproject.com address. Regards, -Paul On Sat, Oct 27, 2012 at 7:01 PM, wrote: > Hi there, > > I'd like to discuss the beh

Re: contrib.markup deprecation

ourage the use of the sundown library. -Paul On Sat, Oct 13, 2012 at 1:34 PM, Luke Plant wrote: > Hi all, > > https://code.djangoproject.com/ticket/18054 > > I just came across this, and it seems slightly hasty. Most deprecations > of entire contrib modules would require some di

Re: Logging Out with POST by Default?

That's the same ticket as this one, which is more recent and has been open for longer... https://code.djangoproject.com/ticket/15619 FWIW, I agree we need to fix this. On Fri, Sep 21, 2012 at 6:56 AM, Aymeric Augustin wrote: > Le 20 sept. 2012 à 20:03, Carl Meyer a écrit : > >> FWIW I agree, a

Re: Why is CSRF cookie persistent?

ot break existing use cases (mobile browsers are my chief concern) I'd be open to changing the default behavior. We generally consider it a bug if any non-malicious user can, through innocent behavior, trigger the CSRF warning. -Paul [1] Django's CSRF implementation usually sets off a

Re: Django 1.4 bug: Using cache_page and csrf_protect decorators results in a messy Set-Cookie response header.

No. please open a new bug detailing this issue. -Paul On Tue, May 15, 2012 at 6:53 AM, Rafał Stożek wrote: > Should we reopen https://code.djangoproject.com/ticket/15863 then? > > > On Mon, May 14, 2012 at 4:39 PM, Suteepat Damrongyingsupab > wrote: >> >> Hi all,

Re: Django 1.4 bug: Using cache_page and csrf_protect decorators results in a messy Set-Cookie response header.

outside of the caching framework? I thought we fixed that bug, but if you can provide minimal steps to reproduce it in Django 1.4, we'll have to reopen the ticket. -Paul On Sat, May 12, 2012 at 1:13 PM, Suteepat Damrongyingsupab wrote: > I'm using Django 1.4. > According to the Dja

Re: GSoC 2012: Security Enhancements

(maybe 2014 when IE6 is finally, truly, laid to rest), we can revisit the idea of using it as a positive signal. -Paul * It has been patched in version 7 and onward. If you are running unpatched flash, you probably have so many viruses it doesn't matter... http://helpx.adobe.com/flash-player

Re: GitHub migration planning

Max, and others on this thread, Arguing about the specific mechanics of how github issues work isn't productive. Put very plainly: Django will not move to github issues because they cannot support our open community triage process. This is not negotiable. Regards, -Paul -- You received

Re: Django File-based session doesn't expire

switch to using the new signing framework for file-based sessions, which provides the option for stronger datetime based integrity checking. The second would be to improve the cleanup command so that it clears out file-based sessions in addition to the database backed ones. -Paul On Thu, Apr 19,

Re: GSoC 2012: Security Enhancements

ction for older browsers, but it also won't break anything for them. For users with newer browsers, it should prevent CSRF even in cases when the CSRF token is stolen due to misconfiguration or user error. -Paul -- You received this message because you are subscribed to the Google Groups

Re: Django 1.4 default database required?

Thanks, I did look at it, it was the import of the Manager for the other shortcuts that was causing the issue. I'll try and file a bug for this. Paul On Apr 2, 2012, at 12:42 PM, Carl Meyer wrote: > On 04/02/2012 09:35 AM, Optimus Paul wrote: >> I've been running Djang

Django 1.4 default database required?

I've been running Django for quite a while without a "database", we use MongoDB, and it has worked well for us. We upgraded to 1.4 and found that suddenly a default database is required. Is there a reason for this? Or is this a bug? We get the error when importing django.shortcuts.render_to_re

Re: metrics: Django case study

Thanks for sharing these results with us. I found them very interesting, and agree that they provide food for thought, and point to areas that might be improved. -Paul On Sat, Mar 24, 2012 at 12:57 AM, Gary Wilson Jr. wrote: > For those interested, I've made available a couple report

Re: Making sure Web APIs built with Django don't have CSRF vulnerabilities.

and what they're doing. For readers who have not inspected it yet, Django's CSRF implementation is quite instructive: https://code.djangoproject.com/browser/django/trunk/django/middleware/csrf.py -Paul -- You received this message because you are subscribed to the Google Gro

Re: make the File Storage API works with a file-like object instead of the Django File object.

This ticket is related to the issue: https://code.djangoproject.com/ticket/16946 -Paul On Tue, Feb 28, 2012 at 3:29 PM, Jonathan French wrote: > You can create a Django file object from any file-like object just by > passing it to the constructor. > > django.cor

Re: Revisiting multiline tags

Mark me a +1 on this as well. Many of us don't ask for items in discussion that have been marked as "won't fix" because we don't realize that the decisions on these items can be reversed. Thanks, Paul On Fri, Feb 24, 2012 at 2:19 AM, Bradley Ayers wrote: > > On

Re: Django and dictionary ordering

r use case, and strictly limit the maximum runtime of any given process. Any failures of the Django test suite which are caused specifically by this randomization change are bugs. Tickets and patches are welcome. -Paul -- You received this message because you are subscribed to the Google G

Re: Request for review for a small fix in the csrf view

ehavior pretty significantly. -Paul -- 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

Re: unblocking #17277

I'm in support of fixing the problem, and this narrowly scoped solution seems like a reasonable way to go about that. -Paul On Fri, Feb 10, 2012 at 11:45 AM, David Lowe wrote: > Django devs - > > I would love to see my patch in > https://code.djangoproject.com/ticket/1727

Re: start using less (and bootstrap!)

On Thu, Feb 2, 2012 at 2:16 PM, Adam "Cezar" Jenkins wrote: > ... > As far as core. Bootstrap should be a 3rd party app, but possibly having > less support in core might be helpful. > > > Funny how that reads. Perhaps for clarity it should say but ' ... possibly having support for "less" in core

Re: Don't assume that missing fields from POST data are equal to an empty string value.

de bug - we don't special case to save the data from views that throw a 500 because you wrote invalid Python, so I don't see why we should add a special case for when you might write incorrect HTML. -Paul -- You received this message because you are subscribed to the Google Group

Re: DoS using POST via hash algorithm collision

> invasive to app code.  It seems that this crafted-hash-collision > vector doesn't have a clean answer like that.  There are workarounds, > but they may not apply to particular codebases. Yeah. The discussion going on over at python-dev suggests that Python itself may actually implement support a

Re: DoS using POST via hash algorithm collision

> Slow Loris can be avoided by putting a proxy capable of buffering > requests until completion between the app server and the web, right? Yes, use nginx or similar. Slowloris is generally not a problem when that is properly configured. > That seems like a simpler workaround than arch upgrade or

Re: DoS using POST via hash algorithm collision

made public (if you know otherwise please contact me privately). Even though this issue is now public, please continue report security problems privately to secur...@djangoproject.com. -Paul -- You received this message because you are subscribed to the Google Groups "Django developers"

Re: SOPA bill question

While this bill certainly merits discussion, and may indeed be related to sites created with and using Django, this forum is not the place for it. Please do not continue this thread here. -Paul -- You received this message because you are subscribed to the Google Groups "Django devel

Re: Django error page - MemoryError

iable values on the html debug page are doing it wrong. -Paul -- 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 d

Re: Hash collision in 'cache' templatetag

andomly collide. It is on the drawing board to improve this (and most other uses of hashing) by switching to HMAC-SHA256 and using a larger character set for the final digest, but that patch isn't likely to make it into 1.4 given our current timeframe. -Paul [1] As another point of scale, our

Re: Proposal: drop Python 2.5 support in Django 1.5

> 2.5 is EOL and no longer receiving security patches even, it is > *irresponsible* of us to support it (I claim).  ANyways +1 This. +1 from me. We do everything else in our power to encourage secure behavior from our users, this is yet another appropriate step. -Paul -- You receive

Re: Proposal: drop Python 2.5 support in Django 1.5

+1 I thought there was an implicit understanding that only 3 versions of Python would be supported at any given time. If so it makes sense to drop support for 2.4 when we add 3.x. On Sat, Dec 10, 2011 at 9:22 AM, Jannis Leidel wrote: > > I propose that we attempt to merge the py3k work after

Re: Python 3 port - all tests now pass on 2.7.2 and 3.2.2 with the same codebase

I was thinking the same thing. Make absolutely sure it works under 2.5-2.7 and even if there are a couple of issues or items not fully tested under 3.2.2 at least we will be moving in the right direction. paul On Fri, Dec 9, 2011 at 5:21 PM, Joseph Tennies wrote: > I must say that I wo

Re: Small problem with HttpResponseRedirect

As Ian said, Django does the right thing here according to my tests too, and generates the absolute URIs required by RFC 2616. If you've figured out some way to actually get location headers that are noncompliant, that would be a bug, but the handling of // is correct. -Paul -- You rec

Re: Sprint in San Francisco

me If we don't find a specific corporate host, we could probably do it at Noisebridge, which has space appropriate for that. It's often hard to predict what else is going on there though, so it could be noisy or busy. -Paul -- You received this message because you are subscribed to the Goo

Re: Queries about CSRF design following penetration test

Yep. It's always important to be careful. Sorry for the extensive reply, but security is such a rabbit hole, it's easy to jump from one topic to another till you're talking about something completely different. Best, -Paul [1] Django 1.4 sets the session cookie to httpOnly by de

Re: Queries about CSRF design following penetration test

t this - I'm PaulM there and I'm usually in #django-dev. You can also email me directly if you want to talk in private about your specific deployment. So, the tl;dr version: Use HTTPS and HSTS. The recommendations you received are generally good, but aren't relevant to Djang

Re: Allowing models to influence QuerySet.update

On Nov 29, 1:17 pm, Luke Plant wrote: > On 29/11/11 17:10, Paul Winkler wrote: > > > Hmm. I've been thinking of signals as key plug points for third-party > > apps, as well as a way to avoid needing database-specific stored > > procedures and triggers. Maybe I need

Re: Allowing models to influence QuerySet.update

On Nov 29, 7:25 am, Luke Plant wrote: > The docs for QuerySet.update() already say that no post_save/pre_save > signals are emitted. Mea culpa, somehow I missed that. Thanks for pointing it out, and updating the ticket. Hmm. I've been thinking of signals as key plug points for third-party apps,

Allowing models to influence QuerySet.update

There was an old thread about this at https://groups.google.com/group/django-developers/browse_frm/thread/6e41ee7b08d50710/9cf6375d97bed499?lnk=gst&q=update+signal#9cf6375d97bed499 which fizzled out last summer with no conclusion. (I'd reply to that thread but google groups apparently won't let me

Re: Removing pickle from cookie-based session storage

> There's no reason to not use JSON by default since it's adequate for > most cases where you need to store lightweight data client-side, since > it's most useful to use with FormWizard and such, where the fields are > easily serialized as strings. If it can't be a drop-in replacement to > the othe

Re: DecimalField model validation

l but precise decimal numbers get rounded unexpectedly. Unfortunately, these two parameters overlap in difficult ways. I disagree about decimal_places, since the expected behavior is rounding in most other real-world circumstances. Does the combination of documenting the existing rounding behavio

Re: prevent brute force attacks by acting on several failed logins, for example by using a captcha

uld be nice, but I think we can work with what we currently have. -Paul -- 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 gr

Re: Removing pickle from cookie-based session storage

-level code execution in some form or another). I've looked at that code extensively, it's fine. -Paul -- 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.

Re: Removing pickle from cookie-based session storage

in the first message, to the best of my knowledge, there's nothing insecure about the implementation now. The usage of signing to validate pickles received directly by end users expands our reliance on SECRET_KEY pretty heavily. This concerns me, which is why I brought it up here. -Paul -- Yo

Session cookies set to HttpOnly in 1.4

be broken by this change? -Paul https://code.djangoproject.com/ticket/16847 -- 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

Re: Removing pickle from cookie-based session storage

e pickle works by running: import pickletools; print pickletools.dis(data) Hopefully that example was more or less concrete enough for you. ;) -Paul -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group

Re: Removing pickle from cookie-based session storage

more space efficient than our current implementation (which could be compressed, but is not). The other downside to JSON is that you can't serialize native Python objects into a session, but you probably shouldn't be doing that anyway. -Paul [1] https://code.djangoproject.com/browser/djan

Re: prevent brute force attacks by acting on several failed logins, for example by using a captcha

ment about adding this feature. It's something Django needs, and with appropriate effort, I believe we can build a solid foundation that will be useful to many Django users. -Paul -- You received this message because you are subscribed to the Google Groups "Django developers" gr

Re: deprecation vs removal

> what is not cause they have separate deprecation policies. It also > encourages me to slack at upgrading and use something deprecated for a > while longer. Yes, but in the meantime you're using the newer, better supported, and often more-secure code. It allows you the luxury of taking the time,

Removing pickle from cookie-based session storage

trary cookie data. The use of pickle changes an attack from "screw up the data in this application" to "arbitrary remote code execution". In light of this, we should be conservative and use JSON by default instead of pickle. -Paul -- You received this message because you are

Re: deprecation vs removal

I agree with your analysis of the word, but also agree that the terminology is likely to confuse people for a while. PendingDeprecation is a rather unfortunate construction. If we can pull through the phase where people are confused, our terminology will be more precise for the change. +1 from me.

Re: prevent brute force attacks by acting on several failed logins, for example by using a captcha

(to complete my thought from the previous prematurely sent email) The bigger problem is that ANY rate-limiting framework is going to need heavy customization to work for all of the different ways Django is deployed. One size will definitely not fit all in this case. -- You received this message

Re: prevent brute force attacks by acting on several failed logins, for example by using a captcha

s going to need At the moment, if your login field is not rate-limited, that is a configuration mistake which is between you and your webserver, and is not within the realm of what Django tries to do. We need to be careful not to re-implement functionality that is better left to other parts of the sta

Re: We're a group of students at UC Berkeley looking to contribute to Django

Hi Jamin, I'm Paul, one of the core devs for Django. I'm curious which class you're enrolled in and what your requirements are. I'm always excited to see new people looking to get involved in the project, and I happen to be VERY local. If you wanted to meet up some evening in

Re: We're a group of students at UC Berkeley looking to contribute to Django

ker, and the issues there, and the contributing guides, are a great place for these folks to start. -Paul -- 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. T

Re: gunicorn in docs

If you write a good and comprehensive set of instructions for making django work with gunicorn, and are willing to keep them up to date, I see no reason we shouldn't include them. It's what I use, and has the advantage of being very, very easy to get working. -Paul -- You received th

Revisiting proxied SSL headers

ves us a chance to warn users again about the dangers of needlessly enabling the setting. -Paul [1] https://code.djangoproject.com/ticket/14597 [2] https://docs.djangoproject.com/en/dev/releases/1.1/#removed-setremoteaddrfromforwardedfor-middleware [3] https://www.djangoproject.com/weblog/2011/

Re: confusing things in Trac UI (was: Design decision for #1625...)

> I'd be in favor of just removing that "accept" radio button if it isn't > hard to do; doesn't do anything you can't do with the "reassign" option, > just gets confused with the triage state. This is a good idea. I made the same mistakes as a new contributor. > >> I can't own it since I'm not a c

Re: is it time to start deprecating parts of contrib

I'm also +1 on deprecating Databrowse. +0 on webdesign, since it's functionality that's probably in transient use by the more invisible members of our community. If it were more fleshed out, I'd say leave it, but since it's just that single function, it should proba

Re: CSRF protection and cookies

for non-HTTPS, but really, everyone should be using HTTPS. -Paul -- 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 ema

Re: CSRF protection and cookies

effects of XSS in some cases. > If you would like help with testing etc for this, I hope I can offer > some time. Thanks, I'll take you up on that when I do get a chance to start drafting things. I went ahead and created #16859 to help keep track of these issues. https://code.djang

  1   2   3   >