Re: CSRF REASON_NO_REFERER with meta referrer tags

[Karen Tracey]

This has bee brought up before, see:
https://code.djangoproject.com/ticket/16870

I am not aware of any change in this area that would affect the decision
made in that ticket.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CACS9rafr6f01-9c7vBNprnz1CTJGgOUyZvfSbOw_da0b_4i4%2BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

CSRF REASON_NO_REFERER with meta referrer tags

[Jon Dufresne]

Hi,

In the interest of security, I recently started using meta referrer
tags in my HTML [0]. To share the least amount of data as possible, I
opted for the "none" policy [1].

This new HTML5 feature breaks Django POST views. The reason: the CSRF
mechanism checks that, when serving over HTTPS, that a HTTP_REFERER
header is set in order to validate the CSRF check. Otherwise, the CSRF
check fails with REASON_NO_REFERER [2]. There is comment in the code
that reads as follows:

# Suppose user visits http://example.com/
# An active network attacker (man-in-the-middle, MITM) sends a
# POST form that targets https://example.com/detonate-bomb/ and
# submits it via JavaScript.
#
# The attacker will need to provide a CSRF cookie and token, but
# that's no problem for a MITM and the session-independent
# nonce we're using. So the MITM can circumvent the CSRF
# protection. This is true for any HTTP connection, but anyone
# using HTTPS expects better! For this reason, for
# https://example.com/ we need additional protection that treats
# http://example.com/ as completely untrusted. Under HTTPS,
# Barth et al. found that the Referer header is missing for
# same-domain requests in only about 0.2% of cases or less, so
# we can use strict Referer checking.

As of right now Chrome is the only browser (that I've tested) that
actually implements the meta referrer tag, but Firefox's next release
will as well. This combination prevented successful login for users.
Unfortunately I didn't detect this problem early in development as I
develop using HTTP, but serve production using HTTPS.

I'm not convinced that this check is really protecting the user from
an attack. Is there additional documentation, beyond this comment, on
why this is more secure? Is there evidence of other web frameworks
using this same technique? I would like to understand more.

Additionally, as a web user, one may use a Firefox/Chrome extension
that purposely strips the HTTP_REFERER from all requests. Django
applications would be effectively broken for such users. In my
opinion, the HTTP_REFERER can't be considered reliable or trustworthy
for such critical operation.

The question: I'm wondering how Django developers feel about removing
this check (or altering it?) in order to help support meta referrer
tags for developers and projects that wish to use it. If there is
general agreement I'll file a ticket and create a pull request.

Cheers,
Jon


[0] https://blog.mozilla.org/security/2015/01/21/meta-referrer/
[1] http://www.w3.org/TR/referrer-policy/#referrer-policy-state-none
[2] 
https://github.com/django/django/blob/27dd7e727153cbf12632a2161217340123687c44/django/middleware/csrf.py#L135

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CADhq2b4_ph2pCRw%3DukmCmHBxmP56xFxykCiyqo8Li4P0tzM1ig%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSOC 2015 project ideas suggestion

[Russell Keith-Magee]

On Mon, Feb 2, 2015 at 11:58 PM, Asif Saifuddin  wrote:

> Hi Fabio,
>
> Thank you for your project ideas. I'm going to follow the ideas from
> https://code.djangoproject.com/wiki/SummerOfCode2015
>

While this is definitely a safe option, don't rule out a
'not-on-the-official-list' project. The GSoC project list is a good list of
pre-vetted projects, but it's not exhaustive. A well posed project,
especially one relating to an old ticket, would certainly be a good
candidate for the GSoC -  For example, multiple schema support is #6148

https://code.djangoproject.com/ticket/6148

Yours,
Russ Magee %-)

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJxq849-9bAeo7dfoAk1XdGBFnBkykGVekRbJbs19_5UH3C1Kg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSOC 2015 project ideas suggestion

[Asif Saifuddin]

Hi Josh,

There are two technical problems that need to be solved in order to make
this happen.

   - Implement the packaging definitions to allow for multiple packages.
   - Clean up dependencies between components. Despite the best of
   intentions, there are some interesting dependencies between modules, some
   of which may need to be clarified or separated.

The aim of this project would be to clean up one or more of Django's
internal "parts" so that it could be delivered as a standalone package.
This may not be something that can be immediately delivered - for example,
it may be necessary to move or rename components to enable separate
packaging. In this case, the project deliverable would be to document the
strategy, and provide whatever initial moves in that direction are possible.

A simpler version of this project would be to enable separate packaging and
distribution of Django's contrib apps.

alongside reduce tight coupling how should I approach to following part?

"A simpler version of this project would be to enable separate packaging
and distribution of Django's contrib apps."


I am looking for dev teams suggestions


./auvipy





On Mon, Feb 2, 2015 at 9:58 PM, Asif Saifuddin  wrote:

> Hi Fabio,
>
> Thank you for your project ideas. I'm going to follow the ideas from
> https://code.djangoproject.com/wiki/SummerOfCode2015
>
>
> for your babel porting probably Aymeric Augustin's template refactor
> project have some plan with babel integration, but I'm willing to work on
> reduce decoupling/Improve template dispatching for first priority from my
> side till now.
>
>
> Regards
>
> ./auvipy
>
> On Mon, Feb 2, 2015 at 9:39 PM, Fabio Caritas Barrionuevo da Luz <
> bna...@gmail.com> wrote:
>
>> Some ideas. (which still require approval of the core developers):
>>
>>
>> * Improve database backend base API and related features(including
>> introspection feature used by inspectdb), so that it is less complicated to
>> add in the future support the specific features of some backends. eg
>> multiple database schemas (common used in Oracle and PostgreSQL) and/or
>> Oracle synonym tables
>>
>> * port Django i18n and i10 and related translation features to use Babel:
>> http://babel.pocoo.org/
>>
>>
>>
>> Em terça-feira, 27 de janeiro de 2015 14:15:20 UTC-3, Asif Saifuddin
>> escreveu:
>>
>>> Hi,
>>>
>>> Although probably It's quite very early to ask about GSOC 2015 in
>>> January,  I would like to start analyzing to prepare myself for choosing a
>>> correct project and submitting a good proposal for that to get selected. I
>>> haven't found any GSOC 2015 project ideas pages yet. But got some older
>>> idea pages  of year 2013 and 2014. Should I look forward to the ideas that
>>> were unimplemented or wait for gsoc 2015 wiki ideas page?
>>>
>>> ./auvipy
>>>
>>  --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/django-developers/WF3My-cZNtY/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, 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 http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/cbb457c7-66cb-4370-99de-c9cfcd2a5622%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKAqTgpmtLaNke2%3DaRC%2BPitvpdyfA_9uWdON%2BJc-5GTVTvJekQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

1.8a and geodjango on windows 7, AttributeError: function 'GDALAllRegister' not found

[mattxbart]

Hi all,
I had a working 1.7.4 (using geodjango) on windows 7 install, no issues. 
I'm using osgeo4w to manage all the gdal/gis libraries. When I install the 
django 1.8a release or off git master, I get the following traceback:

$ ./manage.py shell
Traceback (most recent call last):
  File "./manage.py", line 10, in 
execute_from_command_line(sys.argv)
  File "c:\Python27\lib\site-packages\django\core\management\__init__.py", 
line
338, in execute_from_command_line
utility.execute()
  File "c:\Python27\lib\site-packages\django\core\management\__init__.py", 
line
312, in execute
django.setup()
  File "c:\Python27\lib\site-packages\django\__init__.py", line 18, in setup
apps.populate(settings.INSTALLED_APPS)
  File "c:\Python27\lib\site-packages\django\apps\registry.py", line 108, 
in pop
ulate
app_config.import_models(all_models)
  File "c:\Python27\lib\site-packages\django\apps\config.py", line 202, in 
impor
t_models
self.models_module = import_module(models_module_name)
  File "c:\Python27\lib\importlib\__init__.py", line 37, in import_module
__import__(name)
  File "c:\Python27\lib\site-packages\django\contrib\auth\models.py", line 
42, i
n 
class Permission(models.Model):
  File "c:\Python27\lib\site-packages\django\db\models\base.py", line 126, 
in __
new__
new_class.add_to_class('_meta', Options(meta, **kwargs))
  File "c:\Python27\lib\site-packages\django\db\models\base.py", line 310, 
in ad
d_to_class
value.contribute_to_class(cls, name)
  File "c:\Python27\lib\site-packages\django\db\models\options.py", line 
246, in
 contribute_to_class
self.db_table = truncate_name(self.db_table, 
connection.ops.max_name_length(
))
  File "c:\Python27\lib\site-packages\django\db\__init__.py", line 36, in 
__geta
ttr__
return getattr(connections[DEFAULT_DB_ALIAS], item)
  File "c:\Python27\lib\site-packages\django\db\utils.py", line 238, in 
__getite
m__
backend = load_backend(db['ENGINE'])
  File "c:\Python27\lib\site-packages\django\db\utils.py", line 109, in 
load_bac
kend
return import_module('%s.base' % backend_name)
  File "c:\Python27\lib\importlib\__init__.py", line 37, in import_module
__import__(name)
  File 
"c:\Python27\lib\site-packages\django\contrib\gis\db\backends\postgis\bas
e.py", line 9, in 
from .features import DatabaseFeatures
  File 
"c:\Python27\lib\site-packages\django\contrib\gis\db\backends\postgis\fea
tures.py", line 1, in 
from django.contrib.gis.db.backends.base.features import 
BaseSpatialFeatures

  File 
"c:\Python27\lib\site-packages\django\contrib\gis\db\backends\base\featur
es.py", line 3, in 
from django.contrib.gis.db.models import aggregates
  File 
"c:\Python27\lib\site-packages\django\contrib\gis\db\models\__init__.py",
 line 7, in 
from django.contrib.gis.geos import HAS_GEOS
  File "c:\Python27\lib\site-packages\django\contrib\gis\geos\__init__.py", 
line
 16, in 
from .geometry import GEOSGeometry, wkt_regex, hex_regex
  File "c:\Python27\lib\site-packages\django\contrib\gis\geos\geometry.py", 
line
 13, in 
from django.contrib.gis.gdal.error import SRSException
  File "c:\Python27\lib\site-packages\django\contrib\gis\gdal\__init__.py", 
line
 47, in 
from django.contrib.gis.gdal.driver import Driver  # NOQA
  File "c:\Python27\lib\site-packages\django\contrib\gis\gdal\driver.py", 
line 4
, in 
from django.contrib.gis.gdal.prototypes import ds as vcapi, raster as 
rcapi
  File 
"c:\Python27\lib\site-packages\django\contrib\gis\gdal\prototypes\raster.
py", line 22, in 
register_all = void_output(lgdal.GDALAllRegister, [])
  File "c:\Python27\lib\ctypes\__init__.py", line 378, in __getattr__
func = self.__getitem__(name)
  File "c:\Python27\lib\ctypes\__init__.py", line 383, in __getitem__
func = self._FuncPtr((name_or_ordinal, self))
AttributeError: function 'GDALAllRegister' not found

I've installed all 32b libs, looks like something in the new raster 
functionality? How do I get this working?

Thanks,
Matt

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2508dc69-1dc9-41d9-abae-fa89c784c0ea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSOC 2015 project ideas suggestion

[Asif Saifuddin]

Hi Fabio,

Thank you for your project ideas. I'm going to follow the ideas from
https://code.djangoproject.com/wiki/SummerOfCode2015


for your babel porting probably Aymeric Augustin's template refactor
project have some plan with babel integration, but I'm willing to work on
reduce decoupling/Improve template dispatching for first priority from my
side till now.


Regards

./auvipy

On Mon, Feb 2, 2015 at 9:39 PM, Fabio Caritas Barrionuevo da Luz <
bna...@gmail.com> wrote:

> Some ideas. (which still require approval of the core developers):
>
>
> * Improve database backend base API and related features(including
> introspection feature used by inspectdb), so that it is less complicated to
> add in the future support the specific features of some backends. eg
> multiple database schemas (common used in Oracle and PostgreSQL) and/or
> Oracle synonym tables
>
> * port Django i18n and i10 and related translation features to use Babel:
> http://babel.pocoo.org/
>
>
>
> Em terça-feira, 27 de janeiro de 2015 14:15:20 UTC-3, Asif Saifuddin
> escreveu:
>
>> Hi,
>>
>> Although probably It's quite very early to ask about GSOC 2015 in
>> January,  I would like to start analyzing to prepare myself for choosing a
>> correct project and submitting a good proposal for that to get selected. I
>> haven't found any GSOC 2015 project ideas pages yet. But got some older
>> idea pages  of year 2013 and 2014. Should I look forward to the ideas that
>> were unimplemented or wait for gsoc 2015 wiki ideas page?
>>
>> ./auvipy
>>
>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/WF3My-cZNtY/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/cbb457c7-66cb-4370-99de-c9cfcd2a5622%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKAqTgpWbaSU%3DS%3DtvNq%3Dp-WiZMz2WD3r5H7%3D%2Bdv469udGn5tNA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSOC 2015 project ideas suggestion

[Fabio Caritas Barrionuevo da Luz]

Some ideas. (which still require approval of the core developers):


* Improve database backend base API and related features(including 
introspection feature used by inspectdb), so that it is less complicated to 
add in the future support the specific features of some backends. eg 
multiple database schemas (common used in Oracle and PostgreSQL) and/or 
Oracle synonym tables

* port Django i18n and i10 and related translation features to use 
Babel: http://babel.pocoo.org/ 



Em terça-feira, 27 de janeiro de 2015 14:15:20 UTC-3, Asif Saifuddin 
escreveu:
>
> Hi,
>
> Although probably It's quite very early to ask about GSOC 2015 in January, 
>  I would like to start analyzing to prepare myself for choosing a correct 
> project and submitting a good proposal for that to get selected. I haven't 
> found any GSOC 2015 project ideas pages yet. But got some older idea pages 
>  of year 2013 and 2014. Should I look forward to the ideas that were 
> unimplemented or wait for gsoc 2015 wiki ideas page?
>
> ./auvipy
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/cbb457c7-66cb-4370-99de-c9cfcd2a5622%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Usage of field cardinality flags in database schema backends

[Anssi Kääriäinen]

I don't like the idea of extended usage of field.get_internal_type(). The 
problem is that we haven't defined what the internal_type means, and it is 
actually used for different meanings in different places of code currently.

As an example, AutoFields have internal type as AutoField. The AutoField 
value is needed so that we can create correct auto-increment SQL for the 
schema. On the other hand, AutoField's internal type should also be an 
IntegerField (because other than the autoincrement part, AutoField is just 
like an IntegerField), and for example expressions do value casts 
automatically for all fields whose internal_type ends with IntegerField. 
So, now AutoField which should work exactly like an integer field for 
expressions doesn't work like an integer field for expressions.

Similar problems arise also when trying to define get_internal_type() for 
relational fields. For example, on one hand ForeignKey's 
get_internal_type() should be the same as the related field's type (because 
the concrete field is of that type in the database), but on the other hand 
it should be 'ForeignKey', so that we know it is a relation.

We should define an exact meaning for get_internal_type(), and use the 
method for only that. I haven't seen any explanation of the actual problems 
usage of field flags in django.db causes. We have perfectly good flags to 
use for checking if a field is a relational or a m2m relation, and we 
should use those when needed.

 - Anssi

On Monday, February 2, 2015 at 10:49:11 AM UTC+2, Loïc Bistuer wrote:
>
> Thanks Markus for the detailed report. 
>
> On a conceptual level I think we should aim for: 
>
> - django.db.* only relies on get_internal_type(). 
> - django.* only relies on field flags. 
>
> To address the immediate regressions I suggest we backport 
> https://github.com/django/django/pull/4002/files as far back as 1.7. That 
> would address #24236 without requiring 
> https://github.com/django/django/pull/3998/files. 
>
> In master: 
>
> - Replace all isinstance(field.rel) by isinstance(field) as a first step, 
> this will help normalize things for future refactors (i.e. composite / 
> virtual fields refactor, refactor of *Rel into proper fields like 
> ReverseForeignKey, etc.) 
>
> - Replace all isistance(field) by get_iternal_type() in the ORM. 
>
> - More tricky, replace all isinstance(field) in the rest of django by 
> cardinality flag when possible and identify every place where we can't do 
> it yet because we rely on the implementation of these fields. 
>
> -- 
> Loïc 
>
> > On Jan 31, 2015, at 18:19, Markus Holtermann  > wrote: 
> > 
> > Hey all, 
> > 
> > Since Django 1.8 (currently in alpha state), model fields gained 
> cardinality flags as part of the _meta refactoring. So, there is 
> one_to_one, one_to_many, many_to_one and many_to_many. These flags are 
> currently only used inside user-facing APIs such as forms and the admin. 
> > 
> > Furthermore model fields have a get_internal_type() method that returns 
> self.__class__.__name__ if they don't explicitly override that function (as 
> many of the built-in fields do). This method is heavily used inside the 
> backends. 
> > 
> > Besides those two ways to "try" to figure out what Django has to do in a 
> certain situation, the code uses e.g. isinstance(field.rel, ManyToManyRel) 
> and isinstance(field, ManyToManyField) to check for many-to-many 
> relationships. 
> > 
> > This is quite confusing. At least to me. In 
> https://github.com/django/django/commit/38c17871bb6dafd489367f6fe8bc56199223adb8
>  
> I committed a patch that uses field.many_to_many in order to figure out if 
> a certain column needs to be copied from one table to another (it doesn't 
> if it's an m2m relation) when altering a table on SQLite. 
> > 
> > However changing that to use get_internal_name() and keep existing code 
> working is not trivial since neither ForeignKey nor ManyToManyField or 
> OneToOneField have those methods defined. Thus fields inheriting from 
> either of them need to explicitly define the method to return "ForeignKey", 
> "ManyToManyField" or "OneToOneField". (The backport of that patch to 1.7 
> unfortunately breaks existing projects). 
> > 
> > I have a pull request open to fix the issue on 1.7 related to m2m 
> fields: https://github.com/django/django/pull/3998 . 
> > 
> > However, I don't really like that repetitive pattern of checking for 
> inheritance and get_internal_type(). I'm thinking about keeping the pattern 
> in 1.8 (and replacing the above checks with the one in the pull request) 
> and accept https://github.com/django/django/pull/4002 for 1.9. Thus all 
> projects and apps that rely on the class name of a related fields need to 
> update their code and explicitly return the class name. 
> > 
> > Thoughts and input highly welcome. 
> > 
> > /Markus 
> > 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups "Django developers 

Re: Usage of field cardinality flags in database schema backends

[Loïc Bistuer]

Thanks Markus for the detailed report.

On a conceptual level I think we should aim for:

- django.db.* only relies on get_internal_type().
- django.* only relies on field flags.

To address the immediate regressions I suggest we backport 
https://github.com/django/django/pull/4002/files as far back as 1.7. That would 
address #24236 without requiring 
https://github.com/django/django/pull/3998/files.

In master:

- Replace all isinstance(field.rel) by isinstance(field) as a first step, this 
will help normalize things for future refactors (i.e. composite / virtual 
fields refactor, refactor of *Rel into proper fields like ReverseForeignKey, 
etc.)

- Replace all isistance(field) by get_iternal_type() in the ORM.

- More tricky, replace all isinstance(field) in the rest of django by 
cardinality flag when possible and identify every place where we can't do it 
yet because we rely on the implementation of these fields.

-- 
Loïc

> On Jan 31, 2015, at 18:19, Markus Holtermann  wrote:
> 
> Hey all,
> 
> Since Django 1.8 (currently in alpha state), model fields gained cardinality 
> flags as part of the _meta refactoring. So, there is one_to_one, one_to_many, 
> many_to_one and many_to_many. These flags are currently only used inside 
> user-facing APIs such as forms and the admin.
> 
> Furthermore model fields have a get_internal_type() method that returns 
> self.__class__.__name__ if they don't explicitly override that function (as 
> many of the built-in fields do). This method is heavily used inside the 
> backends.
> 
> Besides those two ways to "try" to figure out what Django has to do in a 
> certain situation, the code uses e.g. isinstance(field.rel, ManyToManyRel) 
> and isinstance(field, ManyToManyField) to check for many-to-many 
> relationships.
> 
> This is quite confusing. At least to me. In 
> https://github.com/django/django/commit/38c17871bb6dafd489367f6fe8bc56199223adb8
>  I committed a patch that uses field.many_to_many in order to figure out if a 
> certain column needs to be copied from one table to another (it doesn't if 
> it's an m2m relation) when altering a table on SQLite.
> 
> However changing that to use get_internal_name() and keep existing code 
> working is not trivial since neither ForeignKey nor ManyToManyField or 
> OneToOneField have those methods defined. Thus fields inheriting from either 
> of them need to explicitly define the method to return "ForeignKey", 
> "ManyToManyField" or "OneToOneField". (The backport of that patch to 1.7 
> unfortunately breaks existing projects).
> 
> I have a pull request open to fix the issue on 1.7 related to m2m fields: 
> https://github.com/django/django/pull/3998 .
> 
> However, I don't really like that repetitive pattern of checking for 
> inheritance and get_internal_type(). I'm thinking about keeping the pattern 
> in 1.8 (and replacing the above checks with the one in the pull request) and 
> accept https://github.com/django/django/pull/4002 for 1.9. Thus all projects 
> and apps that rely on the class name of a related fields need to update their 
> code and explicitly return the class name.
> 
> Thoughts and input highly welcome.
> 
> /Markus
> 
> 
> -- 
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/b66842ee-62d6-43f2-a3df-838020cf60a2%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/16A1F25D-DC93-4DC5-9CF1-6CD7C89642CB%40gmail.com.
For more options, visit https://groups.google.com/d/optout.