Re: backend specific tests

[Tom Forbes]

Hey Dan,

I’ve been working on a project called django_docker_box (
https://github.com/orf/django-docker-box) that might help with this. Docker
is pretty good at spinning up various databases without needing to clutter
your local machine, spend time configuring authentication or dealing with
issues like this.

You might find this helps with you. You can run the entire test suite with
it, or you can just spin up a Postgres database and connect to it from your
local machine (docker-compose run postgres-db) with django:django.

Alternatively you could run:

docker run -p 5432:5432 -e POSTGRES_PASSWORD=django postgres:9.6

And connect to it with postgres:django on localhost:5432

Mysql can be done in the same way:

docker run -p 3306:3306 -e MYSQL_PASSWORD=django mysql:5.7

Hope this helps,

Tom




On 7 November 2018 at 03:51:47, Dan Davis (dansm...@gmail.com) wrote:

What about mysql?   I have 5.7 installed, and tried to run with root
privileges, which is what worked for postgresql.  It still failed quite a
number of times.

On Tue, Nov 6, 2018 at 7:41 PM charettes  wrote:

> Exactly.
>
> Given you should be running tests against a throwaway or at least
> non-critical
> PostgreSQL cluster anyway I don't think requiring superuser privileges is
> an
> issue.
>
> Simon
>
> Le mardi 6 novembre 2018 18:43:47 UTC-5, Dan Davis a écrit :
>>
>> So, a developer using PostgreSQL doesn't need superuser privileges, but
>> you do to run Django's unit tests, because it will test these contributed
>> postgres operations.
>>
>> On Monday, November 5, 2018 at 5:48:20 PM UTC-5, Josh Smeaton wrote:
>>>
>>> I don't think there's a full list of extensions the test suite uses, but
>>> https://docs.djangoproject.com/en/2.1/ref/contrib/postgres/operations/
>>> would be close to a full set I'd imagine.
>>>
>>> On Sunday, 4 November 2018 14:43:23 UTC+11, Dan Davis wrote:

 So, the contributor guidelines page about unit tests mentions running
 database specific tests:


 https://docs.djangoproject.com/en/2.1/internals/contributing/writing-code/unit-tests/#testing-other-python-versions-and-database-backends

 I am working on ticket 29984, and it seems to me that since the
 TruncDay is attempting to cast to the timezone on the database level, it is
 working, and its job is done.  So, the fix should be at the backend level,
 and the ticket provides one for Postgres.

 Following the unit test advice, I created a settings file.   But not
 using my Postgresql admin user.   I get the following errors:

 psycopg2.ProgrammingError: permission denied to create extension
 "btree_gin"
 HINT:  Must be superuser to create this extension.

 I'm not going to do that - do you have any list of required extensions?

>>> --
> 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/d252a3e0-f8f4-4026-b1eb-9dfd79993618%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 (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/CAFzonYYhELA0RRpM07KGsYX08CmM09UjeN8vZRovwfmCUTz_2g%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  (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/CAFNZOJMt_w9p2XXaZqyyKPDQycsNAurb9RGea09TfsdpJgNfkQ%40mail.gmail.com.
For more options, visit htt

Getting started

[abyk476]

Hi, i am Abhith
Can somenone tell me the process to solve a ticket
after i assign myself an easy ticket
thanks

-- 
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/b06d588f-46fa-4db6-beec-c0204719371e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: easy pcikings

[abyk476]

thanks

On Sunday, November 4, 2018 at 7:31:47 PM UTC+5:30, Carlton Gibson wrote:
>
> Hi Abhith. 
>
> Have a look at the Triage Workflow docs: 
> https://docs.djangoproject.com/en/dev/internals/contributing/triaging-tickets/#triage-stages
>
> For each stage of the ticket's lifecycle they give you what's next. (e.g. 
> if it's "New", can you reproduce the issue so it can move to "Accepted", if 
> "Accepted", does it have a patch, and can you add one. And so on.) 
>
> If seems complicated but mostly it's just "Is this a real issue?" and "Can 
> I fix it?" 
>
> Assuming it can be reproduced, creating a Unit Test is the next best step: 
> https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/unit-tests/#unit-tests
> Often, once there's a failing test, the fix won't be far away. 
>
> Make sure you read the Advice for New Contributors: 
> https://docs.djangoproject.com/en/dev/internals/contributing/new-contributors/
>
> And if you get stuck, email django-core-mentorship: 
> https://groups.google.com/forum/#!forum/django-core-mentorship — that's 
> the place for help with contributing. 
> Make sure you include as much details as you can (e.g. ticket number, 
> where you've got to and any errors you're seeing etc) — the more detail you 
> can provide the easier it is to help you. 
>
> I hope that gets you started, and welcome aboard! 
>
> Kind Regards,
>
> Carlton
>
>
> On Sunday, 4 November 2018 14:53:07 UTC+1, aby...@gmail.com wrote:
>>
>> Hi i am Abhith,iam new to django and i have read the newcomers guide.
>> I found an open ticket under new pickings.But i dont know what to do next
>> Can someone pls guide me.
>> thanks,
>>
>

-- 
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/fc4849a5-8e91-429f-8621-61545fbc7d63%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: backend specific tests

[Florian Apolloner]

On Wednesday, November 7, 2018 at 12:43:47 AM UTC+1, Dan Davis wrote:
>
> So, a developer using PostgreSQL doesn't need superuser privileges, but 
> you do to run Django's unit tests, because it will test these contributed 
> postgres operations.
>

 I think one might get away with installing those extensions in the 
template database and the test code is intelligent enough to only install 
them if needed (this is just out of my head though).

-- 
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/350ee3fc-738d-4c18-b561-d5703f37623d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: backend specific tests

[Dan Davis]

Tom,

I'm interested in this - I have a software architect's goal of getting our
Django systems to go to the cloud with Docker, but for Django development,
I am eager to clutter up my local box with these tools.   I know systemctl
quite well, and I have no problem changing postgresql and mysql to be
services not started by default.   I'm a better postgresql dba than mysql,
but I do OK.

On Wed, Nov 7, 2018 at 5:45 AM Tom Forbes  wrote:

> Hey Dan,
>
> I’ve been working on a project called django_docker_box (
> https://github.com/orf/django-docker-box) that might help with this.
> Docker is pretty good at spinning up various databases without needing to
> clutter your local machine, spend time configuring authentication or
> dealing with issues like this.
>
> You might find this helps with you. You can run the entire test suite with
> it, or you can just spin up a Postgres database and connect to it from your
> local machine (docker-compose run postgres-db) with django:django.
>
> Alternatively you could run:
>
> docker run -p 5432:5432 -e POSTGRES_PASSWORD=django postgres:9.6
>
> And connect to it with postgres:django on localhost:5432
>
> Mysql can be done in the same way:
>
> docker run -p 3306:3306 -e MYSQL_PASSWORD=django mysql:5.7
>
> Hope this helps,
>
> Tom
>
>
>
>
> On 7 November 2018 at 03:51:47, Dan Davis (dansm...@gmail.com) wrote:
>
> What about mysql?   I have 5.7 installed, and tried to run with root
> privileges, which is what worked for postgresql.  It still failed quite a
> number of times.
>
> On Tue, Nov 6, 2018 at 7:41 PM charettes  wrote:
>
>> Exactly.
>>
>> Given you should be running tests against a throwaway or at least
>> non-critical
>> PostgreSQL cluster anyway I don't think requiring superuser privileges is
>> an
>> issue.
>>
>> Simon
>>
>> Le mardi 6 novembre 2018 18:43:47 UTC-5, Dan Davis a écrit :
>>>
>>> So, a developer using PostgreSQL doesn't need superuser privileges, but
>>> you do to run Django's unit tests, because it will test these contributed
>>> postgres operations.
>>>
>>> On Monday, November 5, 2018 at 5:48:20 PM UTC-5, Josh Smeaton wrote:

 I don't think there's a full list of extensions the test suite uses,
 but
 https://docs.djangoproject.com/en/2.1/ref/contrib/postgres/operations/
 would be close to a full set I'd imagine.

 On Sunday, 4 November 2018 14:43:23 UTC+11, Dan Davis wrote:
>
> So, the contributor guidelines page about unit tests mentions running
> database specific tests:
>
>
> https://docs.djangoproject.com/en/2.1/internals/contributing/writing-code/unit-tests/#testing-other-python-versions-and-database-backends
>
> I am working on ticket 29984, and it seems to me that since the
> TruncDay is attempting to cast to the timezone on the database level, it 
> is
> working, and its job is done.  So, the fix should be at the backend level,
> and the ticket provides one for Postgres.
>
> Following the unit test advice, I created a settings file.   But not
> using my Postgresql admin user.   I get the following errors:
>
> psycopg2.ProgrammingError: permission denied to create extension
> "btree_gin"
> HINT:  Must be superuser to create this extension.
>
> I'm not going to do that - do you have any list of required extensions?
>
 --
>> 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/d252a3e0-f8f4-4026-b1eb-9dfd79993618%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 (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/CAFzonYYhELA0RRpM07KGsYX08CmM09UjeN8vZRovwfmCUTz_2g%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
> --
> You rec

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

[C. Kirby]

I bit the bullet and put together a small app to handle this, with maybe 
even less typing. It monkey patches all installed models so you can run 
Model.ident_(pk)
Can be found at https://github.com/ckirby/django-model-ident

Chaim

-- 
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/4bdacfe9-8fca-4b59-a15d-27553c731d4e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Password reset token safety

[Alex Toussaint]

Hello,

I'd like to discuss about Django's password reset token functionality.

I've been able, with a simple Python script, from having read-only access 
to my Django webserver to a full read-write by crafting a reset token. 
Isn't it one of the main goals of hashing passwords ? Protecting from 
attackers having read only access to the database ? 
The only "Unpredictable" data that can be needed if the attacker's  last 
database access is old is the last_login, which can be very easily bypassed 
with a simple script bruteforce (as I did here 
)

I would like to know, is there an other way the password reset mechanism 
could work that wouldn't enable such problem ? I haven't found one alone.


-- 
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/96fd4144-450e-4d9a-ab7d-eb308339056c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Password reset token safety

[Florian Apolloner]

Hi there,

On Wednesday, November 7, 2018 at 10:22:06 PM UTC+1, Alex Toussaint wrote:
>
> I've been able, with a simple Python script, from having read-only access 
> to my Django webserver to a full read-write by crafting a reset token. 
>

To be honest that script is weird at best; if you have access to the 
password hash, you will most likely also have access to the last_login -- 
so why bruteforce it at all? And yes it is absolutely expected to be able 
to generate password reset tokens if you know the SECRET_KEY (!!!), the 
password hash, last_login & id.

Isn't it one of the main goals of hashing passwords ? Protecting from 
> attackers having read only access to the database ? 
>

No, the main goal of hashing passwords is not leaking the __original__ 
password. It also protects against attackers with read only access to the 
database as long as the hash functions are sufficiently good (you can 
always try to bruteforce the password).

Cheers,
Florian 

-- 
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/64cef8de-b463-4f98-b439-a98498bb9133%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Password reset token safety

[Tom Forbes]

Would you consider the *secret* key to not be unpredictable?

On Wed, 7 Nov 2018, 21:22 Alex Toussaint 
> Hello,
>
> I'd like to discuss about Django's password reset token functionality.
>
> I've been able, with a simple Python script, from having read-only access
> to my Django webserver to a full read-write by crafting a reset token.
> Isn't it one of the main goals of hashing passwords ? Protecting from
> attackers having read only access to the database ?
> The only "Unpredictable" data that can be needed if the attacker's  last
> database access is old is the last_login, which can be very easily bypassed
> with a simple script bruteforce (as I did here
> )
>
> I would like to know, is there an other way the password reset mechanism
> could work that wouldn't enable such problem ? I haven't found one alone.
>
>
> --
> 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/96fd4144-450e-4d9a-ab7d-eb308339056c%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  (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/CAFNZOJOasT-mn1u5djEWz23UoUJzOBfUEQ0%2B5P4%3Dwsn0%3D6RUzw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Password reset token safety

[James Bennett]

SECRET_KEY is the closest thing Django has to a “root password”. That’s why
we emphasize keeping it secret — someone who knows your SECRET_KEY can
effectively do anything to your site anyway. For example, they could
produce valid session cookies for any user, and then just hop in the admin
interface.

So any attack based on “assume you know the SECRET_KEY” is already going to
be able to do anything, just like anything that says “assume you know the
server’s root password” can do anything.

-- 
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/CAL13Cg-GRyUvqFV4dO7aO1tjtBbXgwJjRjA_sYTFAW0D%3Doe_vA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

[Collin Anderson]

You could probably also just monkey patch like so:

from django.db.models import Manager, QuerySet
Manager.ident = QuerySet.ident = lambda self, pk: self.get(pk=pk)

On Wed, Nov 7, 2018 at 3:33 PM C. Kirby  wrote:

> I bit the bullet and put together a small app to handle this, with maybe
> even less typing. It monkey patches all installed models so you can run
> Model.ident_(pk)
> Can be found at https://github.com/ckirby/django-model-ident
>
> Chaim
>
> --
> 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/4bdacfe9-8fca-4b59-a15d-27553c731d4e%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  (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/CAFO84S5Hkm4D3o%2BAmFgV8YHX2ZKH42hG5QU6UycJpjvS8dp3xw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Password reset token safety

[Alex Toussaint]

The attacker can have access to the password hash but no longer to the last 
login. if that same attacker is exploiting a vulnerability that gets 
patched just after (ex. Heartbleed) or has view on past data (ex. backups)

But if you can anyway craft a valid session cookie with the secret key 
(Which I didn't knew), this is totally useless.

Thanks you for the clarification !

Alex

-- 
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/da8f1bc6-5af8-47da-8a2e-f834cc17d382%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.