Re: [Django] #27961: HTTP_X_FORWARDED_PROTO is bypassed

2017-03-19 Thread Django
#27961: HTTP_X_FORWARDED_PROTO is bypassed
-+-
 Reporter:  cryptogun|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  HTTP handling|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  redirect HTTPS X | Triage Stage:
  -Forwarded-Proto   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by cryptogun):

 Replying to [comment:1 Tim Graham]:
 > I'm having trouble understanding the report. What is the second line in
 each item (e.g. `HTTP_X_FORWARDED_PROTO=None` supposed to represent?
 Values of the [https://docs.djangoproject.com/en/stable/ref/settings
 /#secure-proxy-ssl-header SECURE_PROXY_SSL_HEADER] setting? By the way, if
 there is a security issue here, please
 [https://docs.djangoproject.com/en/dev/internals/security/#reporting-
 security-issues report the issue to the security team].
 Yes your guess is right. Django sets `HTTP_X_FORWARDED_PROTO` to None by
 default as the link you provided tells. I've updated the main thread to
 make it more clear.
 I think this is a small issue so not reported it to the security team.
 Since normally we do a HTTP to HTTPS redirect in nginx by this setting
 `listen: 80; return 302 https://$server_name$request_uri;`

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.389c0ce634778140591c8cbe1fbe23a0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #27961: HTTP_X_FORWARDED_PROTO is bypassed

2017-03-19 Thread Django
#27961: HTTP_X_FORWARDED_PROTO is bypassed
-+-
 Reporter:  cryptogun|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  HTTP handling|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  redirect HTTPS X | Triage Stage:
  -Forwarded-Proto   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by cryptogun:

Old description:

> nginx + gunicorn:
> 1.
> `proxy_set_header X-Forwarded-Proto $scheme;`
> `HTTP_X_FORWARDED_PROTO=None`
> ''No redirect.''
> 2.
> `proxy_set_header X-Forwarded-Proto $scheme;`
> `HTTP_X_FORWARDED_PROTO='http'`
> ''No redirect.''
> 3.
> `proxy_set_header X-Forwarded-Proto $scheme;`
> `HTTP_X_FORWARDED_PROTASDF='http'`
> ''No redirect.''
> 4.
> proxy_set_header X-Forwarded-Protooo $scheme;
> `HTTP_X_FORWARDED_PROTOOO='https'`
> ''No redirect.''
> 5.
> proxy_set_header X-Forwarded-Protooo $scheme;
> `HTTP_X_FORWARDED_PROTOOO=None`
> ''ERR_TOO_MANY_REDIRECTS''
> 6.
> Add an else clause under [these
> lines](https://github.com/django/django/blob/master/django/http/request.py#L196-L197).
>
> {{{
> else:
> return 'http'
> }}}
>
> And set:
> `proxy_set_header X-Forwarded-Proto $scheme;`
> `HTTP_X_FORWARDED_PROTO='http'`
> Chrome would report the expected ''ERR_TOO_MANY_REDIRECTS''
> Did someone forget to add the else clause, or there are 3 'http' 'ftp'
> and 'ftps' scheme left?
> If a site use 5. An attacker may set request `X-Forwarded-Proto` header
> to bypass the HTTPS check and result in 1,2,3.

New description:

 I'm using nginx + gunicorn and display pages via HTTPS:
 1. Both default settings:
 Nginx setting: `proxy_set_header X-Forwarded-Proto $scheme;`
 Django setting: `HTTP_X_FORWARDED_PROTO=None`
 Result: ''No redirect.'' I'm not getting a ''ERR_TOO_MANY_REDIRECTS''
 complain from Chrome.

 2. Use default setting in nginx; use a wrong setting in Django, i.e. the
 'https' part:
 `proxy_set_header X-Forwarded-Proto $scheme;`
 `HTTP_X_FORWARDED_PROTO='http'`
 ''No redirect.''

 3. Use default setting in nginx; use a wrong setting in Django:
 `proxy_set_header X-Forwarded-Proto $scheme;`
 `HTTP_X_FORWARDED_PROTASDF='http'`
 ''No redirect.''

 4. Use custom HTTPS indicator in both nginx and Django:
 proxy_set_header X-Forwarded-Protooo $scheme;
 `HTTP_X_FORWARDED_PROTOOO='https'`
 ''No redirect.'' This is the expected behavior.

 5. Use custom HTTPS indicator in both nginx and Django, and testing for a
 unsafe protocol ( != 'https'):
 proxy_set_header X-Forwarded-Protooo $scheme;
 `HTTP_X_FORWARDED_PROTOOO='https'`
 Chrome complains ''ERR_TOO_MANY_REDIRECTS''. This is the expected
 behavior.

 6. A fix testing by myself:
 Add an else clause under [these
 
lines](https://github.com/django/django/blob/master/django/http/request.py#L196-L197).

 {{{
 else:
 return 'http'
 }}}

 And set:
 `proxy_set_header X-Forwarded-Proto $scheme;`
 `HTTP_X_FORWARDED_PROTO='http'`
 Chrome would report the expected ''ERR_TOO_MANY_REDIRECTS''.

 Did someone forget to add the else clause, or there are 3 'http' 'ftp' and
 'ftps' scheme left?
 If a site use 5. An attacker may set request `X-Forwarded-Proto` header to
 bypass the HTTPS check and result in 1,2,3.

--

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.00f1b30b1b8f2ebc5a5f8a45119787f3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #27959: Wrong output when alter field in sqlmigrate.

2017-03-19 Thread Django
#27959: Wrong output when alter field in sqlmigrate.
+--
 Reporter:  jinzhao |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  1.10
 Severity:  Normal  |   Resolution:  invalid
 Keywords:  migrations  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by jinzhao):

 * status:  new => closed
 * resolution:   => invalid


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.ada2b1ba0c5b0762a980574bcb3ed873%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #27959: Wrong output when alter field in sqlmigrate.

2017-03-19 Thread Django
#27959: Wrong output when alter field in sqlmigrate.
+--
 Reporter:  jinzhao |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.10
 Severity:  Normal  |   Resolution:
 Keywords:  migrations  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--

Comment (by jinzhao):

 You are right. I didn't notice the difference between sqlite and mysql.
 Sorry to create a wrong ticket.

 Replying to [comment:1 Tim Graham]:
 > What is the bug? Creating a new table and copy over the data is expected
 behavior as described in the
 [https://docs.djangoproject.com/en/stable/topics/migrations/#sqlite SQLite
 migration docs].

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.e28ef8932ea821e447893ca8b42c4e14%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #27958: CSRF_COOKIE reset while requesting a broken relative URL over HTTPS

2017-03-19 Thread Django
#27958: CSRF_COOKIE reset while requesting a broken relative URL over HTTPS
-+-
 Reporter:  cryptogun|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  CSRF |  Version:  1.10
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  csrf reset https | Triage Stage:
  403|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * status:  new => closed
 * resolution:   => invalid


Comment:

 If disabling `CSRF_COOKIE_HTTPONLY` fixes the issue, that should be fine
 -- it offers little practical security, see #27611. If you want to keep it
 enabled, then you need to submit AJAX requests as described in #27534.

 Next time, you might want to ask on our
 [TicketClosingReasons/UseSupportChannels support channels] unless you are
 really sure the issue is a bug. As far as I can tell, there's no issue
 here. Thanks.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.8df7efd08b39a4443d7470a0d72853d8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #27961: HTTP_X_FORWARDED_PROTO is bypassed

2017-03-19 Thread Django
#27961: HTTP_X_FORWARDED_PROTO is bypassed
-+-
 Reporter:  cryptogun|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  HTTP handling|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  redirect HTTPS X | Triage Stage:
  -Forwarded-Proto   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * component:  contrib.redirects => HTTP handling


Comment:

 I'm having trouble understanding the report. What is the second line in
 each item (e.g. `HTTP_X_FORWARDED_PROTO=None` supposed to represent?
 Values of the [https://docs.djangoproject.com/en/stable/ref/settings
 /#secure-proxy-ssl-header SECURE_PROXY_SSL_HEADER] setting? By the way, if
 there is a security issue here, please
 [https://docs.djangoproject.com/en/dev/internals/security/#reporting-
 security-issues report the issue to the security team].

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.fac62b688b71ba0c872ad7c160799767%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


[Django] #27961: HTTP_X_FORWARDED_PROTO is bypassed

2017-03-19 Thread Django
#27961: HTTP_X_FORWARDED_PROTO is bypassed
-+-
   Reporter:  cryptogun  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component: |Version:  1.10
  contrib.redirects  |   Keywords:  redirect HTTPS X
   Severity:  Normal |  -Forwarded-Proto
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 nginx + gunicorn:
 1.
 `proxy_set_header X-Forwarded-Proto $scheme;`
 `HTTP_X_FORWARDED_PROTO=None`
 ''No redirect.''
 2.
 `proxy_set_header X-Forwarded-Proto $scheme;`
 `HTTP_X_FORWARDED_PROTO='http'`
 ''No redirect.''
 3.
 `proxy_set_header X-Forwarded-Proto $scheme;`
 `HTTP_X_FORWARDED_PROTASDF='http'`
 ''No redirect.''
 4.
 proxy_set_header X-Forwarded-Protooo $scheme;
 `HTTP_X_FORWARDED_PROTOOO='https'`
 ''No redirect.''
 5.
 proxy_set_header X-Forwarded-Protooo $scheme;
 `HTTP_X_FORWARDED_PROTOOO=None`
 ''ERR_TOO_MANY_REDIRECTS''
 6.
 Add an else clause under [these
 
lines](https://github.com/django/django/blob/master/django/http/request.py#L196-L197).

 {{{
 else:
 return 'http'
 }}}

 And set:
 `proxy_set_header X-Forwarded-Proto $scheme;`
 `HTTP_X_FORWARDED_PROTO='http'`
 Chrome would report the expected ''ERR_TOO_MANY_REDIRECTS''
 Did someone forget to add the else clause, or there are 3 'http' 'ftp' and
 'ftps' scheme left?
 If a site use 5. An attacker may set request `X-Forwarded-Proto` header to
 bypass the HTTPS check and result in 1,2,3.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.54bc04c4f21a28c608807fe7db0776f6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #27538: Value of JSONField is being re-encoded to string even though being already encoded

2017-03-19 Thread Django
#27538: Value of JSONField is being re-encoded to string even though being 
already
encoded
--+--
 Reporter:  Petar Aleksic |Owner:  (none)
 Type:  Bug   |   Status:  closed
Component:  contrib.postgres  |  Version:  1.10
 Severity:  Normal|   Resolution:  duplicate
 Keywords:  JSONField | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by Tim Graham):

 * status:  new => closed
 * resolution:   => duplicate


Comment:

 This behavior doesn't reproduce in Django's test suite. Are you using
 `django-jsonfield`? See ticket:27675#comment:8.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.cd601b95ec3dfb614228405c3e2f96db%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #27538: Value of JSONField is being re-encoded to string even though being already encoded

2017-03-19 Thread Django
#27538: Value of JSONField is being re-encoded to string even though being 
already
encoded
--+--
 Reporter:  Petar Aleksic |Owner:  (none)
 Type:  Bug   |   Status:  new
Component:  contrib.postgres  |  Version:  1.10
 Severity:  Normal|   Resolution:
 Keywords:  JSONField | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by Waken Meng):

 * status:  closed => new
 * resolution:  worksforme =>


Comment:

 I have the same problem, Re-json the JSONField value.


 {{{
 from django.contrib.postgres.fields import JSONField

 class Foo(models.Model):
 photos = JSONFields(max_length=300)

 >>f = Foo()
 >>f.photos = []
 >>f.save()
 >>f.photos
 u'[]'

 >>f.save()
 >>f.refresh_from_db()
 >>f.photos
 u'"[]"'

 >>f.save()
 >>f.refresh_from_db()
 >>f.photos
 u'"\\"[]\\""'

 }}}
 Above was in manage.py shell, and everytime I save the instance, the
 JSONField value is re-jsonized.

 env:
  postgres 9.6.1
  python 2.7.12

  django 1.10.5
  psycopg2 2.6.2

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.b06fffefd73816f2814347464edbf4ed%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #27960: ds = DataSource('/path/to/your/cities.shp') fails on first try (GDALException Unknown error code: "198770787"), but works on second

2017-03-19 Thread Django
#27960: ds = DataSource('/path/to/your/cities.shp') fails on first try
(GDALException Unknown error code: "198770787"), but works on second
---+--
 Reporter:  Etiënne Thomassen  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  GIS|  Version:  1.10
 Severity:  Normal |   Resolution:
 Keywords:  DataSource, GIS| Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Description changed by Etiënne Thomassen:

Old description:

> I can not create a DataSource from a gpx file. It returns GDALException
> Unknown error code: "198770787" with the error code number seemingly
> random. However on the second try it works. And it does not even need to
> be the same file.
>

> {{{
> Python 3.6.0 (default, Dec 24 2016, 08:01:42)
> [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.42.1)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from django.contrib.gis.gdal import DataSource
> >>> ds = DataSource('Bleswerk dec16.gpx')
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/Users/etienne/.virtualenvs/bosbot3/lib/python3.6/site-
> packages/django/contrib/gis/gdal/datasource.py", line 64, in __init__
> Driver.ensure_registered()
>   File "/Users/etienne/.virtualenvs/bosbot3/lib/python3.6/site-
> packages/django/contrib/gis/gdal/driver.py", line 83, in
> ensure_registered
> rcapi.register_all()
>   File "/Users/etienne/.virtualenvs/bosbot3/lib/python3.6/site-
> packages/django/contrib/gis/gdal/prototypes/errcheck.py", line 119, in
> check_errcode
> check_err(result, cpl=cpl)
>   File "/Users/etienne/.virtualenvs/bosbot3/lib/python3.6/site-
> packages/django/contrib/gis/gdal/error.py", line 74, in check_err
> raise GDALException('Unknown error code: "%s"' % code)
> django.contrib.gis.gdal.error.GDALException: Unknown error code:
> "-1935278031"
> >>> ds = DataSource('20140525_170950_gpx.gpx')
> >>> ds.layer_count
> 5
> }}}
>
> This post on StackOverflow pointed me in this direction:
> http://stackoverflow.com/questions/41775536/datasource-gdalexception-
> unknown-error-code-474873798
>
> Strangely, I can now get it to work doing this in my app:
>
> {{{
> try:
> datasource = DataSource(target_path)
> except:
> datasource = DataSource(target_path)
> }}}
>
> Btw this part of my app stopped working migrating from Django 1.8 and
> Python 2.7 to Django 1.9 and Python 3.6. Now on Django 1.10 and Python
> 3.6

New description:

 I can not create a DataSource from a gpx file. It returns GDALException
 Unknown error code: "198770787" with the error code number seemingly
 random. However on the second try it works. And it does not even need to
 be the same file.


 {{{
 Python 3.6.0 (default, Dec 24 2016, 08:01:42)
 [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.42.1)] on darwin
 Type "help", "copyright", "credits" or "license" for more information.
 >>> from django.contrib.gis.gdal import DataSource
 >>> ds = DataSource('gpxfile1.gpx')
 Traceback (most recent call last):
   File "", line 1, in 
   File "/Users/etienne/.virtualenvs/venv1/lib/python3.6/site-
 packages/django/contrib/gis/gdal/datasource.py", line 64, in __init__
 Driver.ensure_registered()
   File "/Users/etienne/.virtualenvs/venv1/lib/python3.6/site-
 packages/django/contrib/gis/gdal/driver.py", line 83, in ensure_registered
 rcapi.register_all()
   File "/Users/etienne/.virtualenvs/venv1/lib/python3.6/site-
 packages/django/contrib/gis/gdal/prototypes/errcheck.py", line 119, in
 check_errcode
 check_err(result, cpl=cpl)
   File "/Users/etienne/.virtualenvs/venv1/lib/python3.6/site-
 packages/django/contrib/gis/gdal/error.py", line 74, in check_err
 raise GDALException('Unknown error code: "%s"' % code)
 django.contrib.gis.gdal.error.GDALException: Unknown error code:
 "-1935278031"
 >>> ds = DataSource('gpxfile2.gpx')
 >>> ds.layer_count
 5
 }}}

 This post on StackOverflow pointed me in this direction:
 http://stackoverflow.com/questions/41775536/datasource-gdalexception-
 unknown-error-code-474873798

 Strangely, I can now get it to work doing this in my app:

 {{{
 try:
 datasource = DataSource(target_path)
 except:
 datasource = DataSource(target_path)
 }}}

 Btw this part of my app stopped working migrating from Django 1.8 and
 Python 2.7 to Django 1.9 and Python 3.6. Now on Django 1.10 and Python 3.6

--

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received 

Re: [Django] #27960: ds = DataSource('/path/to/your/cities.shp') fails on first try (GDALException Unknown error code: "198770787"), but works on second

2017-03-19 Thread Django
#27960: ds = DataSource('/path/to/your/cities.shp') fails on first try
(GDALException Unknown error code: "198770787"), but works on second
---+--
 Reporter:  Etiënne Thomassen  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  GIS|  Version:  1.10
 Severity:  Normal |   Resolution:
 Keywords:  DataSource, GIS| Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Description changed by Etiënne Thomassen:

Old description:

> I can not create a DataSource from a gpx file. It returns GDALException
> Unknown error code: "198770787" with the error code number seemingly
> random. However on the second try it works. And it does not even need to
> be the same file.
>

> {{{
> Python 3.6.0 (default, Dec 24 2016, 08:01:42)
> [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.42.1)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from django.contrib.gis.gdal import DataSource
> >>> ds = DataSource('Bleswerk dec16.gpx')
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/Users/etienne/.virtualenvs/bosbot3/lib/python3.6/site-
> packages/django/contrib/gis/gdal/datasource.py", line 64, in __init__
> Driver.ensure_registered()
>   File "/Users/etienne/.virtualenvs/bosbot3/lib/python3.6/site-
> packages/django/contrib/gis/gdal/driver.py", line 83, in
> ensure_registered
> rcapi.register_all()
>   File "/Users/etienne/.virtualenvs/bosbot3/lib/python3.6/site-
> packages/django/contrib/gis/gdal/prototypes/errcheck.py", line 119, in
> check_errcode
> check_err(result, cpl=cpl)
>   File "/Users/etienne/.virtualenvs/bosbot3/lib/python3.6/site-
> packages/django/contrib/gis/gdal/error.py", line 74, in check_err
> raise GDALException('Unknown error code: "%s"' % code)
> django.contrib.gis.gdal.error.GDALException: Unknown error code:
> "-1935278031"
> >>> ds = DataSource('20140525_170950_gpx.gpx')
> >>> ds.layer_count
> 5
> }}}
>
> This post on StackOverflow pointed me in this direction:
> http://stackoverflow.com/questions/41775536/datasource-gdalexception-
> unknown-error-code-474873798
>
> Strangely, I can now get it to work doing this in my app:
>
> {{{
> try:
> datasource = DataSource(target_path)
> except:
> datasource = DataSource(target_path)
> }}}

New description:

 I can not create a DataSource from a gpx file. It returns GDALException
 Unknown error code: "198770787" with the error code number seemingly
 random. However on the second try it works. And it does not even need to
 be the same file.


 {{{
 Python 3.6.0 (default, Dec 24 2016, 08:01:42)
 [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.42.1)] on darwin
 Type "help", "copyright", "credits" or "license" for more information.
 >>> from django.contrib.gis.gdal import DataSource
 >>> ds = DataSource('Bleswerk dec16.gpx')
 Traceback (most recent call last):
   File "", line 1, in 
   File "/Users/etienne/.virtualenvs/bosbot3/lib/python3.6/site-
 packages/django/contrib/gis/gdal/datasource.py", line 64, in __init__
 Driver.ensure_registered()
   File "/Users/etienne/.virtualenvs/bosbot3/lib/python3.6/site-
 packages/django/contrib/gis/gdal/driver.py", line 83, in ensure_registered
 rcapi.register_all()
   File "/Users/etienne/.virtualenvs/bosbot3/lib/python3.6/site-
 packages/django/contrib/gis/gdal/prototypes/errcheck.py", line 119, in
 check_errcode
 check_err(result, cpl=cpl)
   File "/Users/etienne/.virtualenvs/bosbot3/lib/python3.6/site-
 packages/django/contrib/gis/gdal/error.py", line 74, in check_err
 raise GDALException('Unknown error code: "%s"' % code)
 django.contrib.gis.gdal.error.GDALException: Unknown error code:
 "-1935278031"
 >>> ds = DataSource('20140525_170950_gpx.gpx')
 >>> ds.layer_count
 5
 }}}

 This post on StackOverflow pointed me in this direction:
 http://stackoverflow.com/questions/41775536/datasource-gdalexception-
 unknown-error-code-474873798

 Strangely, I can now get it to work doing this in my app:

 {{{
 try:
 datasource = DataSource(target_path)
 except:
 datasource = DataSource(target_path)
 }}}

 Btw this part of my app stopped working migrating from Django 1.8 and
 Python 2.7 to Django 1.9 and Python 3.6. Now on Django 1.10 and Python 3.6

--

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop 

[Django] #27960: ds = DataSource('/path/to/your/cities.shp') fails on first try (GDALException Unknown error code: "198770787"), but works on second

2017-03-19 Thread Django
#27960: ds = DataSource('/path/to/your/cities.shp') fails on first try
(GDALException Unknown error code: "198770787"), but works on second
-+-
   Reporter:  Etiënne|  Owner:  nobody
  Thomassen  |
   Type:  Bug| Status:  new
  Component:  GIS|Version:  1.10
   Severity:  Normal |   Keywords:  DataSource, GIS
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I can not create a DataSource from a gpx file. It returns GDALException
 Unknown error code: "198770787" with the error code number seemingly
 random. However on the second try it works. And it does not even need to
 be the same file.


 {{{
 Python 3.6.0 (default, Dec 24 2016, 08:01:42)
 [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.42.1)] on darwin
 Type "help", "copyright", "credits" or "license" for more information.
 >>> from django.contrib.gis.gdal import DataSource
 >>> ds = DataSource('Bleswerk dec16.gpx')
 Traceback (most recent call last):
   File "", line 1, in 
   File "/Users/etienne/.virtualenvs/bosbot3/lib/python3.6/site-
 packages/django/contrib/gis/gdal/datasource.py", line 64, in __init__
 Driver.ensure_registered()
   File "/Users/etienne/.virtualenvs/bosbot3/lib/python3.6/site-
 packages/django/contrib/gis/gdal/driver.py", line 83, in ensure_registered
 rcapi.register_all()
   File "/Users/etienne/.virtualenvs/bosbot3/lib/python3.6/site-
 packages/django/contrib/gis/gdal/prototypes/errcheck.py", line 119, in
 check_errcode
 check_err(result, cpl=cpl)
   File "/Users/etienne/.virtualenvs/bosbot3/lib/python3.6/site-
 packages/django/contrib/gis/gdal/error.py", line 74, in check_err
 raise GDALException('Unknown error code: "%s"' % code)
 django.contrib.gis.gdal.error.GDALException: Unknown error code:
 "-1935278031"
 >>> ds = DataSource('20140525_170950_gpx.gpx')
 >>> ds.layer_count
 5
 }}}

 This post on StackOverflow pointed me in this direction:
 http://stackoverflow.com/questions/41775536/datasource-gdalexception-
 unknown-error-code-474873798

 Strangely, I can now get it to work doing this in my app:

 {{{
 try:
 datasource = DataSource(target_path)
 except:
 datasource = DataSource(target_path)
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/059.3eac9d1e67995f015d4a81470e1fb933%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #27959: Wrong output when alter field in sqlmigrate.

2017-03-19 Thread Django
#27959: Wrong output when alter field in sqlmigrate.
+--
 Reporter:  jinzhao |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.10
 Severity:  Normal  |   Resolution:
 Keywords:  migrations  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--

Comment (by Tim Graham):

 What is the bug? Creating a new table and copy over the data is expected
 behavior as described in the
 [https://docs.djangoproject.com/en/stable/topics/migrations/#sqlite SQLite
 migration docs].

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.839066b47b7f9d099ad7fd560da42baa%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


[Django] #27959: Wrong output when alter field in sqlmigrate.

2017-03-19 Thread Django
#27959: Wrong output when alter field in sqlmigrate.
--+
   Reporter:  jinzhao |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  Migrations  |Version:  1.10
   Severity:  Normal  |   Keywords:  migrations
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
 I start a container in docker image `python:2.7-slim` and test like this.

 1. Use `django-admin startproject mysite` to start a project.
 2. Use `./manage.py startapp app` to add a app.
 3. Add a model in `app/models.py`.
 {{{#!python
 class Abcd(models.Model):
 name = models.CharField(max_length=100)
 }}}
 4. Edit `mysite/settings.py`. Add `app.apps.AppConfig` to `INSTALLED_APPS`
 5. Run `./manage.py makemigrations && ./manage.py migrate`.
 6. Edit `app/models.py`. Change the max length of name field to 1000.
 7. Run `./manage.py makemigrations && ./manage.py sqlmigrate app 0002`.

 Here is the output.

 {{{
 ALTER TABLE "app_abcd" RENAME TO "app_abcd__old";
 CREATE TABLE "app_abcd" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT,
 "name" varchar(1000) NOT NULL);
 INSERT INTO "app_abcd" ("id", "name") SELECT "id", "name" FROM
 "app_abcd__old";
 DROP TABLE "app_abcd__old";
 COMMIT;
 }}}

 It will create a new table, and drop all the data in the old table.

 The migrate file seems correct. Here is
 `app/migrations/0002_auto_20170319_1003.py`

 {{{#!python
 # -*- coding: utf-8 -*-
 # Generated by Django 1.10.6 on 2017-03-19 10:03
 from __future__ import unicode_literals

 from django.db import migrations, models


 class Migration(migrations.Migration):

 dependencies = [
 ('app', '0001_initial'),
 ]

 operations = [
 migrations.AlterField(
 model_name='abcd',
 name='name',
 field=models.CharField(max_length=1000),
 ),
 ]
 }}}

 Django is installed by pip, django.VERSION is (1, 10, 6, u'final', 0).

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/054.add51e9c94d2c7debf7abe669d9c626f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #27958: CSRF_COOKIE reset while requesting a broken relative URL over HTTPS

2017-03-19 Thread Django
#27958: CSRF_COOKIE reset while requesting a broken relative URL over HTTPS
-+-
 Reporter:  cryptogun|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  CSRF |  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  csrf reset https | Triage Stage:
  403|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by cryptogun):

 Replying to [comment:1 Tim Graham]:
 > I'm not sure there's a bug in Django here. Why isn't the CSRF token sent
 with the request for the broken relative link?

 New CSRF token did sent and stored in cookie (for the broken relative
 link).
 But `manage.py check --deploy` suggest me to set this to true:
 `CSRF_COOKIE_HTTPONLY = True`
 > If True, client-side JavaScript is not able to access the CSRF cookie.
 This can help prevent malicious JavaScript from bypassing CSRF protection.

 But `{{ csrf_token }}` are static in pages that're already opened
 previously.

 {{{
 if not _compare_salted_tokens(request_csrf_token, csrf_token):
 return self._reject(request, REASON_BAD_TOKEN)

 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.09db053615c851a2129565828298c721%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.