Re: Custom Model field, to_python() / from_db_value() and unittests...
Am 17.06.2015 um 16:48 schrieb charettes: I suggest you use the following pattern which also accounts for py2/3: ... This is stepping into the django-user@ territory so I suggest we move the discussion over there if the provided example doesn't match your needs but you are really just trying to write a portable third-party field. Thanks for you suggestion. I "moved" it to django-user list ;) -- Mfg. Jens Diemer http://www.jensdiemer.de -- 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/mls207%24lkp%242%40ger.gmane.org. For more options, visit https://groups.google.com/d/optout.
Re: Custom Model field, to_python() / from_db_value() and unittests...
Am 16.06.2015 um 18:43 schrieb Tim Graham:
The doc about how to ignore warnings in tests is here:
https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#deprecating-a-feature
Alternatively, you can temporarily remove these lines in runtests.py:
warnings.simplefilter("error", RemovedInDjango20Warning)
warnings.simplefilter("error", RemovedInDjango21Warning)
Thanks!
But then, there can't exists tests that will raise a warning while importing ?!?
So i try to make it clear:
With v1.7 the "__metaclass__ = models.SubfieldBase" is needed. So i remove the
tests without it.
And i found a existing Bug https://code.djangoproject.com/ticket/9619 for:
to_python not called when fetching data with .values(...)
I update the tests and create a ticket and pull request here:
* https://code.djangoproject.com/ticket/24993
* https://github.com/django/django/pull/4874
I can also made pull request for v1.8.x and master...
I also found the Solution for: "to_python() didn't call with Python 3":
The "__metaclass__" syntax changed in Python 3.
The Problem: I didn't read the doc carefully here:
https://docs.djangoproject.com/en/1.7/howto/custom-model-fields/#the-subfieldbase-metaclass
There are three code examples:
* for Python 2 only
* for Python 3 only
* for Python 2+3 using six.with_metaclass()
What's about to remove the first two examples and leave only the
six.with_metaclass() example?!?
I made also a ticket/pull request for this:
* https://code.djangoproject.com/ticket/24992
* https://github.com/django/django/pull/4873
On Tuesday, June 16, 2015 at 12:30:05 PM UTC-4, Jens Diemer wrote:
I try to create a custom model field, that should "Converting values to
Python
objects" as described in the documentation here:
<https://docs.djangoproject.com/en/dev/howto/custom-model-fields/#converting-values-to-python-objects
<https://docs.djangoproject.com/en/dev/howto/custom-model-fields/#converting-values-to-python-objects>>
It doesn't work with Python 2.7 and 3.4 with Django 1.7.x and 1.8.x...
I search around and found no unittest case for this
"howto/custom-model-fields"
So i created a simple test case to investigate why my code not worked.
I made a unittest against "stable/1.7.x", "stable/1.8.x" and "master" here:
https://github.com/jedie/django/branches/yours
<https://github.com/jedie/django/branches/yours>
compare links:
stable/1.7.x
<https://github.com/jedie/django/compare/stable/1.7.x...test_custom_model_fields_1.7.x
<https://github.com/jedie/django/compare/stable/1.7.x...test_custom_model_fields_1.7.x>>
stable/1.8.x
<https://github.com/jedie/django/compare/stable/1.8.x...test_custom_model_fields_1.8.x
<https://github.com/jedie/django/compare/stable/1.8.x...test_custom_model_fields_1.8.x>>
master
<https://github.com/jedie/django/compare/master...test_custom_model_fields_master
<https://github.com/jedie/django/compare/master...test_custom_model_fields_master>>
I run these test and here the result:
*** 1.7.x with Py2:
test_custom_model_field (custom_model_fields.tests.TestModel1Tests) ... FAIL
test_values (custom_model_fields.tests.TestModel1Tests) ... FAIL
test_custom_model_field (custom_model_fields.tests.TestModel2Tests) ... ok
test_values (custom_model_fields.tests.TestModel2Tests) ... FAIL
*** 1.7.x with Py3:
test_custom_model_field (custom_model_fields.tests.TestModel1Tests) ... FAIL
test_values (custom_model_fields.tests.TestModel1Tests) ... FAIL
test_custom_model_field (custom_model_fields.tests.TestModel2Tests) ... FAIL
test_values (custom_model_fields.tests.TestModel2Tests) ... FAIL
*** 1.8.x with Py2:
test_custom_model_field (custom_model_fields.tests.TestModel1Tests) ... ok
test_values (custom_model_fields.tests.TestModel1Tests) ... ok
*** 1.8.x with Py3
test_custom_model_field (custom_model_fields.tests.TestModel1Tests) ... ok
test_values (custom_model_fields.tests.TestModel1Tests) ... ok
*** master with Py2 - doesn't run:
Traceback (most recent call last):
File "/home/jens/PyLucid_env/src/django/tests/runtests.py", line 12, in
from django.apps import apps
File "/home/jens/PyLucid_env/src/django/django/apps/__init__.py", line
1, in
from .config import AppConfig # NOQA
File "/home/jens/PyLucid_env/src/django/django/apps/config.py", line 6,
in
from django.utils.module_loading import module_has_submodule
File "/home/jens/PyLucid_env/src/django/django/utils/module_loading.py",
line
4, in
Custom Model field, to_python() / from_db_value() and unittests...
I try to create a custom model field, that should "Converting values to Python objects" as described in the documentation here: <https://docs.djangoproject.com/en/dev/howto/custom-model-fields/#converting-values-to-python-objects> It doesn't work with Python 2.7 and 3.4 with Django 1.7.x and 1.8.x... I search around and found no unittest case for this "howto/custom-model-fields" So i created a simple test case to investigate why my code not worked. I made a unittest against "stable/1.7.x", "stable/1.8.x" and "master" here: https://github.com/jedie/django/branches/yours compare links: stable/1.7.x <https://github.com/jedie/django/compare/stable/1.7.x...test_custom_model_fields_1.7.x> stable/1.8.x <https://github.com/jedie/django/compare/stable/1.8.x...test_custom_model_fields_1.8.x> master <https://github.com/jedie/django/compare/master...test_custom_model_fields_master> I run these test and here the result: *** 1.7.x with Py2: test_custom_model_field (custom_model_fields.tests.TestModel1Tests) ... FAIL test_values (custom_model_fields.tests.TestModel1Tests) ... FAIL test_custom_model_field (custom_model_fields.tests.TestModel2Tests) ... ok test_values (custom_model_fields.tests.TestModel2Tests) ... FAIL *** 1.7.x with Py3: test_custom_model_field (custom_model_fields.tests.TestModel1Tests) ... FAIL test_values (custom_model_fields.tests.TestModel1Tests) ... FAIL test_custom_model_field (custom_model_fields.tests.TestModel2Tests) ... FAIL test_values (custom_model_fields.tests.TestModel2Tests) ... FAIL *** 1.8.x with Py2: test_custom_model_field (custom_model_fields.tests.TestModel1Tests) ... ok test_values (custom_model_fields.tests.TestModel1Tests) ... ok *** 1.8.x with Py3 test_custom_model_field (custom_model_fields.tests.TestModel1Tests) ... ok test_values (custom_model_fields.tests.TestModel1Tests) ... ok *** master with Py2 - doesn't run: Traceback (most recent call last): File "/home/jens/PyLucid_env/src/django/tests/runtests.py", line 12, in from django.apps import apps File "/home/jens/PyLucid_env/src/django/django/apps/__init__.py", line 1, in from .config import AppConfig # NOQA File "/home/jens/PyLucid_env/src/django/django/apps/config.py", line 6, in from django.utils.module_loading import module_has_submodule File "/home/jens/PyLucid_env/src/django/django/utils/module_loading.py", line 4, in from importlib import import_module File "/home/jens/PyLucid_env/src/django/django/utils/importlib.py", line 6, in ImportError: cannot import name RemovedInDjango19Warning *** master with Py3: test_custom_model_field (custom_model_fields.tests.TestModel1Tests) ... ok test_values (custom_model_fields.tests.TestModel1Tests) ... ok test_custom_model_field (custom_model_fields.tests.TestModel2Tests) ... ok test_values (custom_model_fields.tests.TestModel2Tests) ... ok So the biggest problem is django 1.7.x... But it should work in the same way: <https://docs.djangoproject.com/en/1.7/howto/custom-model-fields/#converting-database-values-to-python-objects> With 1.8.x i must remove the test with existing: __metaclass__ = models.SubfieldBase Otherwise the test will not run: Testing against Django installed in '/home/jens/PyLucid_env/src/django/django' Importing application custom_model_fields Traceback (most recent call last): File "/home/jens/PyLucid_env/src/django/tests/runtests.py", line 448, in options.debug_sql) File "/home/jens/PyLucid_env/src/django/tests/runtests.py", line 235, in django_tests state = setup(verbosity, test_labels) File "/home/jens/PyLucid_env/src/django/tests/runtests.py", line 214, in setup apps.set_installed_apps(settings.INSTALLED_APPS) File "/home/jens/PyLucid_env/src/django/django/apps/registry.py", line 324, in set_installed_apps self.populate(installed) File "/home/jens/PyLucid_env/src/django/django/apps/registry.py", line 108, in populate app_config.import_models(all_models) File "/home/jens/PyLucid_env/src/django/django/apps/config.py", line 198, in import_models self.models_module = import_module(models_module_name) File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module __import__(name) File "/home/jens/PyLucid_env/src/django/tests/custom_model_fields/models.py", line 41, in class CommaSeparatedModelField2(CommaSeparatedModelField1): File "/home/jens/PyLucid_env/src/django/django/db/models/fields/subclassing.py", line 22, in __new__ RemovedInDjango20Warning) django.utils.deprecation.RemovedInDjango20Warning: SubfieldBase has been deprecated. Use Field.from_db_value instead. Maybe i miss something to handle warnings with tests, but didn't find something about warnings he
form validation in contrib.auth
The default auth.form.AuthenticationForm() did not set a max_length for the password field: https://github.com/django/django/blob/72f6513ebaa7a3fd43c26300e9a8c430dc07cdb5/django/contrib/auth/forms.py#L120-L126 Ok there is not really a max_length constraint. Because in the end the auth.models.User must only store the hash value. The available hashers will consume more RAM if the password is very long. (The CPU usage is very similar to a short password) Only if the server has a POST data limit, the password size is limited. But it seems that POST limits are not set or very large on default installations... On the other side: I didn't see any side effects with a limitation e.g.: max_length=1024 Another thing: The auth.models.AbstractUser has the 'username' field with max_length=30 and validators.RegexValidator(r'^[\w.@+-]+$',...) The AuthenticationForm has max_length=254 and no validator... IMHO one principle is: Validate incoming data as soon as possible, isn't it? Next thing is "auth.signals.user_login_failed" This signal will only fired if the auth backends was called. IMHO it should be called on every failed login. Also if the form is not valid. -- Mfg. Jens Diemer http://www.jensdiemer.de -- 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/mis98k%24n71%241%40ger.gmane.org. For more options, visit https://groups.google.com/d/optout.
Re: Adding Support for PyMySQL (for Python 3)
Am 07.12.2011 21:38, schrieb Ian Clelland: PyMySQL is a pure python implementation of PEP 249 for MySQL, and supports Python 2.4 - 3.2, and MySQL 4.1 and higher. Another goal of PyMySQL would be to use Django + MySQL with PyPy, isn't it? See also: https://groups.google.com/group/django-users/browse_thread/thread/cbef429d014c1ad9/ -- Mfg. Jens Diemer http://www.jensdiemer.de -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: The state of per-site/per-view middleware caching in Django
Hi... For PyLucid i made a simple cache middleware [1] simmilar to Django per-site cache middleware [2]. But i doesn't vary on Cookies and don't cache cookies. I simply cache only the response content. Of course: This doesn't solve the problem if "csrfmiddlewaretoken" in content. Here some pseudo code from [1]: - def process_request(self, request): if not self.use_cache(request): return response = cache.get(cache_key) if response is not None: return response def process_response(self, request, response): if not self.use_cache(request): return response # Cache only the raw content response2 = HttpResponse( content=response._container, status=200, content_type=response['Content-Type'] ) patch_response_headers(response2, timeout) cache.set(request.path, response2, timeout) return response - [1] https://github.com/jedie/PyLucid/blob/master/pylucid_project/middlewares/cache.py [2] https://docs.djangoproject.com/en/1.3/topics/cache/#the-per-site-cache Mfg. Jens D. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: CSRF token not validated?
Am 12.09.2011 22:32, schrieb Carl Meyer: Sanity-checking the length sounds reasonable to me - do you mind opening a ticket for this and attaching your patch? Done ;) Ticked: https://code.djangoproject.com/ticket/16827 Patch: https://github.com/django/django/pull/45 -- Mfg. Jens Diemer http://www.jensdiemer.de -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
CSRF token not validated?
I wonder that the CSRF token send from the client didn't be validated.
Don't know if a DOS attack is possible by sending many request with very long
CSRF tokens?
IMHO it's a good idea to check the length before do anything with it.
e.g.:
--
diff --git a/django/middleware/csrf.py b/django/middleware/csrf.py
index b5a8579..8e03635 100644
--- a/django/middleware/csrf.py
+++ b/django/middleware/csrf.py
@@ -72,7 +72,10 @@ def get_token(request):
def _sanitize_token(token):
# Allow only alphanum, and ensure we return a 'str' for the sake of the
post
# processing middleware.
-token = re.sub('[^a-zA-Z0-9]', '', str(token.decode('ascii', 'ignore')))
+if len(token) != 32:
+token = ""
+else:
+token = re.sub('[^a-zA-Z0-9]', '', str(token.decode('ascii',
'ignore')))
if token == "":
# In case the cookie has been truncated to nothing at some point.
return _get_new_csrf_key()
------
--
Mfg.
Jens Diemer
http://www.jensdiemer.de
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: PHP-inspired user-friendly in-browser DJango install
Am 09.09.2011 08:23, schrieb Aymeric Augustin: Nothing prevents you from altering the settings file dynamically and telling the user to restart the webserver. You can run wih an in-memory SQLite database until this is done. So your question isn't related to the development of Django itself; it would be more appropriate on django-users. Note that deploying a Django project is a bit more complicated than a PHP project (just throw the files in WWW_ROOT). IMO setting up the database isn't the most difficult step. I don't know any projects that provide this feature. For PyLucid CMS i created a "standalone package" with a Web-GUI installation. You need not shell to install it. Here some screenshots: http://www.pylucid.org/permalink/340/pylucid-screenshots/PyLucid-standalone/ The Web-GUI install is a simple CGI script for running syncdb, south migrate and create a first superuser etc. The script is here: <https://github.com/jedie/PyLucid/blob/master/scripts/standalone/install_pylucid.cgi> The install procedure is really simple: * Upload all files via FTP to webserver * request http://www.my_server.tld/install_pylucid.cgi * run "syncdb", "migrate", "create superuser", "loaddata" Complete instruction here: http://www.pylucid.org/permalink/331/1b-install-pylucid-standalone-package But the prefered way to install PyLucid is a bootscript which creates a virtualenv: <http://www.pylucid.org/permalink/333/1a1-create-a-pylucid-environment-with-pylucid-boot> -- Mfg. Jens Diemer http://www.jensdiemer.de -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Suppressed template errors in admin
Am 25.08.2011 06:19, schrieb h3:
But this would have side effects on the non-admin templates too.. so
it's not ideal.
Maybe something like this:
TEMPLATE_STRING_IF_INVALID = {'default: '!! Invalid var !!',
'django.contrib.admin': ''}
I do a hack in my admin.py:
-
# some django admin stuff is broken if TEMPLATE_STRING_IF_INVALID != ""
# http://code.djangoproject.com/ticket/3579
if settings.TEMPLATE_STRING_IF_INVALID != "":
# Patch the render_to_response function ;)
from django.contrib.auth import admin as auth_admin
from django.contrib.admin import options
def patched_render_to_response(*args, **kwargs):
old = settings.TEMPLATE_STRING_IF_INVALID
settings.TEMPLATE_STRING_IF_INVALID = ""
result = render_to_response(*args, **kwargs)
settings.TEMPLATE_STRING_IF_INVALID = old
return result
options.render_to_response = patched_render_to_response
auth_admin.render_to_response = patched_render_to_response
-
So you can use TEMPLATE_STRING_IF_INVALID, but it's excluded from django admin
;)
--
Mfg.
Jens Diemer
http://www.jensdiemer.de
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
