Re: Rename salt to mask in CSRF

Cool, PR here: https://github.com/django/django/pull/12479 On Thu, Feb 20, 2020 at 1:59 AM Adam Johnson wrote: > I guess it's not a very big change so could be worth it to increase > readability. > > On Wed, 19 Feb 2020 at 16:12, Ram Rachum wrote: > >> In any case, if i

Re: Rename salt to mask in CSRF

key/mask/one-time-pad to that cipher function. > > I think "mask" and "unmask" are more correct terms to use in the code and > docstrings. Not sure if it's worth the effort to change though > > > On Wed, 19 Feb 2020 at 06:39, Matemática A3K > wrote:

Rename salt to mask in CSRF

Hi guys, Recently I was working with Django's CSRF protection, customizing it to my needs, and discussing with co-workers exactly how it works and how it has protection against the BREACH attack being used to retrieve the CSRF key. Relevant code here:

Re: Use "raise from" where appropriate, all over the codebase

FYI: I opened a thread on Python-ideas where we continued the discussion on my `raise as` proposal, Shai's proposal, etc.: https://mail.python.org/archives/list/python-id...@python.org/thread/KM7NRNFZHALOBKJUXVYQL2SLDP3MAANW/ On Fri, Feb 7, 2020 at 1:16 PM Ram Rachum wrote: > > > On F

Re: Use "raise from" where appropriate, all over the codebase

On Fri, Feb 7, 2020 at 12:23 PM Carlton Gibson wrote: > > I'm basing it on the fact that Carlton approved this PR for the style > guide: https://github.com/django/django/pull/12350 > > No. I don't think we should merge that change. (It's "approved" qua itself > before reviewing, and dependent on

Re: Use "raise from" where appropriate, all over the codebase

On Fri, Feb 7, 2020 at 12:27 AM Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > Hello Ram, > > On 6 Feb 2020, at 19:08, Ram Rachum wrote: > > In other words, "raise from" is the inevitable future, it's just that > we're not in a rush to get ther

Re: Use "raise from" where appropriate, all over the codebase

Hi guys, I'm disappointed that you're against this change... But I understand that you have a different perspective. Here's my last-ditch effort to convince you. If I understand correctly, you both agree that using "raise from" in this context is better than using plain raise, just that the

Re: Use "raise from" where appropriate, all over the codebase

I made a pull request for the style guide if anyone would like to review: https://github.com/django/django/pull/12350 On Mon, Jan 20, 2020 at 6:05 PM Ram Rachum wrote: > Jon: That's awesome! I also liked R101. I didn't think of that. > > Adam: I thought so too, but after going ov

Re: Use "raise from" where appropriate, all over the codebase

Jon: That's awesome! I also liked R101. I didn't think of that. Adam: I thought so too, but after going over dozens of R100 cases, I didn't find even one where a raise without "from" inside an except clause was justified. I challenge you to show me even one such example. On Mon, Jan 20, 2020 at

Re: Use "raise from" where appropriate, all over the codebase

On Sat, Jan 18, 2020 at 5:05 PM Shai Berger wrote: > [snip] But as it turns out, `from` puts the > original exception on the `__cause__` in *addition* to `__context__`: > > [snip] > So that is not a concern. > Awesome! I did not know that. > > Regarding automatically enforcing this format

Re: Use "raise from" where appropriate, all over the codebase

> Uri. > אורי > u...@speedy.net > > > On Sat, Jan 18, 2020 at 11:55 AM Ram Rachum wrote: > >> Hi guys, >> >> I recently made a big ticket/PR to Django, and Shai Berger told me I >> should first talk about it in this mailing list. >> >&

Re: Use "raise from" where appropriate, all over the codebase

n >> displayed via console output, as you see the inner exception first and have >> to scroll up to see the exception you actually have to handle. >> >> Tom >> >> On 18 Jan 2020, at 09:55, Ram Rachum wrote: >> >>  >> >> Hi guys,

Use "raise from" where appropriate, all over the codebase

Hi guys, I recently made a big ticket/PR to Django, and Shai Berger told me I should first talk about it in this mailing list. This is the ticket: https://code.djangoproject.com/ticket/31177 and its PR: https://github.com/django/django/pull/12339 It's a generalization of this ticket that I

Re: Using `SECRET_KEY` in password hashers

a custom password > hasher... > Yep, that's true. > > -- > C > > > On 9 June 2015 at 16:01, Ram Rachum <r...@rachum.com> wrote: > >> If the leak happened because someone got into your code repo, you're >> right. (I can't rule out a scenario where

Re: Using `SECRET_KEY` in password hashers

. So isn't this an improvement? On Tue, Jun 9, 2015 at 8:55 AM, Shai Berger <s...@platonix.com> wrote: > On Tuesday 09 June 2015 08:23:03 Ram Rachum wrote: > > On Tue, Jun 9, 2015 at 8:22 AM, Curtis Maloney < > cur...@acommoncreative.com> > > wrote: > > > On 9

Re: Using `SECRET_KEY` in password hashers

re > invalid. > > -- > Curtis > > > On 9 June 2015 at 15:16, Ram Rachum <ram.rac...@gmail.com> wrote: > >> Hi, >> >> What do you think about using the project's `SECRET_KEY` as an additional >> salt in Django's password hashers? The advantage woul

Using `SECRET_KEY` in password hashers

Hi, What do you think about using the project's `SECRET_KEY` as an additional salt in Django's password hashers? The advantage would be that they'll be harder to crack, as an attacker would need access both to the database table and the code for the secret key. The disadvantage I can think of

Re: Why can't templates access properties

itional properties on a > QuerySet :) > > -- > Curtis > > On 27 May 2015 at 07:14, Ram Rachum <ram.rac...@gmail.com> wrote: > >> I found the cause of my problem: `django.db.models.Manager.from_queryset` >> copies all the methods from the `QuerySet` class to t

Re: Why can't templates access properties

properties as well? On Tuesday, May 26, 2015 at 10:19:25 PM UTC+3, Tim Graham wrote: > > Accessing properties in templates should work as far as I know. Maybe > there is an error in your application. > > On Tuesday, May 26, 2015 at 2:27:40 PM UTC-4, Ram Rachum wrote: >> >> Hi

Why can't templates access properties

Hi, I noticed that when I use variables in Django templates that access object properties, it doesn't work. (e.g. I have {{ foo.bar }} while bar is a Python property.) See the documentation for variables in Django templates:

Re: A general way to batch SQL queries in Django

ith Django?* Thanks for your help, Ram Rachum. On Sat, Feb 28, 2015 at 12:40 AM, Michael Manfre <mman...@gmail.com> wrote: > Stored procedures, at least with MSSQL, provide another way of returning > multiple result sets with a single SQL statement. The queries will be > parsed and exec

Re: A general way to batch SQL queries in Django

t over that single > connection though, which is the closest you're going to get. > > Regards, > > On Friday, 27 February 2015 23:14:05 UTC+11, Ram Rachum wrote: >> >> Hi guys, >> >> After asking this question on django-users: >> >> https://group

A general way to batch SQL queries in Django

Hi guys, After asking this question on django-users: https://groups.google.com/forum/#!topic/django-users/EuPduHjSNos And in several other forums, and not finding a solution, I've reached a conclusion: It would be really helpful to allow batching SQL queries in Django. I should preface by

Re: Idea about authentication

Hi everybody, I've submitted the patch, and corrected it, and it's been sitting on the issue tracker for 2 weeks without anyone commenting. Does anyone care to discuss this? I want to have this merged in, or discuss any problems in merging it in. On Sun, Sep 15, 2013 at 11:27 PM, Ram Rachum

Re: Idea about authentication

Submitted patch: https://code.djangoproject.com/ticket/21105#comment:1 On Sunday, September 15, 2013 10:09:55 PM UTC+3, Donald Stufft wrote: > > > On Sep 15, 2013, at 2:59 PM, Florian Apolloner > <f.apo...@gmail.com> > wrote: > > Hi Ram, > > On Sunday, Septembe

Re: Idea about authentication

wrote: > > > > On Sunday, September 15, 2013 11:45:29 AM UTC+2, Ram Rachum wrote: > >> What if instead of calculating the PBKDF2 hash of the password, we'll >> calculate the PBKDF2 hash of its SHA1 hash? Then the time of checking >> passwords wouldn't depend on their

Re: Idea about authentication

th reading up on if you > want to get further into crypto: > http://en.wikipedia.org/wiki/Side_channel_attack > > -- > Curtis > > > > On 15 September 2013 19:00, Ram Rachum <ram.r...@gmail.com > >wrote: > >> Hi guys, >> >> I just saw the new relea

Idea about authentication

Hi guys, I just saw the new release announcement and I had an idea. What if, in addition to sorting the hard to compute hash for every password, we will also store the sha 1 hash of the first 5 characters ofthe password's sha1 hash? Wouldn't this allow us to quickly rule out 99% of passwords,

Re: Why not switch hasher when number of iterations changes?

Wonderful, thank you! On Mon, Mar 18, 2013 at 10:59 PM, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > On 18 mars 2013, at 21:51, Ram Rachum <ram.rac...@gmail.com> wrote: > > > Why does Django switch to the new hasher only if the algorithm was > cha

Why not switch hasher when number of iterations changes?

Look at this code: https://github.com/django/django/blob/master/django/contrib/auth/hashers.py#L55 Why does Django switch to the new hasher only if the algorithm was changed, and not if the number of iterations (which could be critical) changed? Thanks, Ram. -- You received this message

Re: Can you confirm Stack Overflow answer about `.exists()`?

want to access the data." On Fri, Jan 18, 2013 at 6:08 PM, Javier Guerra Giraldez <jav...@guerrag.com>wrote: > On Fri, Jan 18, 2013 at 10:58 AM, Ram Rachum <r...@rachum.com> wrote: > > I suggest copying your explanation into the documentation. > > it's already there

Re: Can you confirm Stack Overflow answer about `.exists()`?

Thanks Carl! I suggest copying your explanation into the documentation. Thanks, Ram. On Fri, Jan 18, 2013 at 5:26 PM, Carl Meyer <c...@oddbird.net> wrote: > Hi Ram, > > On 01/18/2013 06:25 AM, Ram Rachum wrote: > > Can someone who's familiar with Django internals p

Can you confirm Stack Overflow answer about `.exists()`?

Can someone who's familiar with Django internals please confirm or deny the following answer to my question? http://stackoverflow.com/a/14369747/76701 Thanks, Ram. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion

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

In which Django release are we hoping to release this port? 1.4 or 1.5? Ram. -- 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/-/Y8-2tS9lth4J. To