Re: Admin site: Appropriateness of HTTP 500 when using non-allowed query strings
On Apr 10, 2012, at 4:34 AM, 3point2 wrote: > The admin site allows the use of certain query strings to filter > change list pages. The syntax follows queryset field lookups, for > example http://mysite.com/admin/myapp/mymodel/?field__exact=test. > Lookups that are not specified on the ModelAdmin's list_filter option > raise a SuspiciousOperation exception. This is done to prevent a > normal user from obtaining sensitive information (e.g. password > hashes). > > In production use, I'm not sure that returning an HTTP code of 500 > (internal server error) and emailing the server admins is an > appropriate response to a user manipulating the query string. > > I think that 403 (forbidden) would be more accurate. In my mind, 500 > suggests that something went wrong on the server, for example an > unexpected condition or exception in the application code. In this > situation, this is not the case. Django is deliberately forbidding a > user from accessing information for which they have not been > authorized. > > Any thoughts? I agree that no 500 response should be returned only by passing improper querystring parameters, unless those parameters match a custom list filter and that filter raises an unhandled exception. There is already a system in place to avoid this problem though, so if you've found an edge case could you please create a new ticket in Trac with a test case? Thanks a lot, Julien smime.p7s Description: S/MIME cryptographic signature
Errors in tests
Hi, I just upgraded to r17895, and now tests appear to have stopped
working. Here's the tail end of the test run:
==
ERROR: test_user_permission_performance
(regressiontests.admin_views.tests.UserAdminTest)
--
Traceback (most recent call last):
File "/home/vinay/projects/django/tests/regressiontests/admin_views/
tests.py", line 3244, in test_user_permission_performance
response = self.client.get('/test_admin/admin/auth/user/%s/' %
u.pk)
File "/home/vinay/projects/django/django/test/client.py", line 427,
in get
response = super(Client, self).get(path, data=data, **extra)
File "/home/vinay/projects/django/django/test/client.py", line 243,
in get
return self.request(**r)
File "/home/vinay/projects/django/django/core/handlers/base.py",
line 136, in get_response
response = response.render()
File "/home/vinay/projects/django/django/template/response.py", line
104, in render
self._set_content(self.rendered_content)
File "/home/vinay/projects/django/django/template/response.py", line
81, in rendered_content
content = template.render(context)
File "/home/vinay/projects/django/django/template/base.py", line
140, in render
return self._render(context)
File "/home/vinay/projects/django/django/test/utils.py", line 60, in
instrumented_test_render
return self.nodelist.render(context)
File "/home/vinay/projects/django/django/template/base.py", line
823, in render
bit = self.render_node(node, context)
File "/home/vinay/projects/django/django/template/base.py", line
837, in render_node
return node.render(context)
File "/home/vinay/projects/django/django/template/loader_tags.py",
line 123, in render
return compiled_parent._render(context)
File "/home/vinay/projects/django/django/test/utils.py", line 60, in
instrumented_test_render
return self.nodelist.render(context)
File "/home/vinay/projects/django/django/template/base.py", line
823, in render
bit = self.render_node(node, context)
File "/home/vinay/projects/django/django/template/base.py", line
837, in render_node
return node.render(context)
File "/home/vinay/projects/django/django/template/loader_tags.py",
line 123, in render
return compiled_parent._render(context)
File "/home/vinay/projects/django/django/test/utils.py", line 60, in
instrumented_test_render
return self.nodelist.render(context)
File "/home/vinay/projects/django/django/template/base.py", line
823, in render
bit = self.render_node(node, context)
File "/home/vinay/projects/django/django/template/base.py", line
837, in render_node
return node.render(context)
File "/home/vinay/projects/django/django/template/loader_tags.py",
line 62, in render
result = block.nodelist.render(context)
File "/home/vinay/projects/django/django/template/base.py", line
823, in render
bit = self.render_node(node, context)
File "/home/vinay/projects/django/django/template/base.py", line
837, in render_node
return node.render(context)
File "/home/vinay/projects/django/django/template/base.py", line
1193, in render
'use_tz': context.use_tz,
File "/home/vinay/projects/django/django/template/context.py", line
96, in __init__
super(Context, self).__init__(dict_)
File "/home/vinay/projects/django/django/template/context.py", line
18, in __init__
self._reset_dicts(dict_)
File "/home/vinay/projects/django/django/template/context.py", line
23, in _reset_dicts
builtins.update(value)
ValueError: dictionary update sequence element #0 has length 1; 2 is
required
--
Ran 4698 tests in 956.978s
FAILED (errors=166, skipped=109, expected failures=2)
Destroying test database for alias 'default'...
Destroying test database for alias 'other'...
vinay@eta-oneiric64:~/projects/django/tests$
All the errors appear to have the same root cause. I'm testing with
Python 2.7.2+ (default, Oct 4 2011, 20:06:09) on Ubuntu Oneiric 64-
bit.
Can anyone shed any light on this? The value being passed to the
update method is an instance of
django.template.context.RequestContext. I can't see what I might be
doing wrong, so any help would be appreciated.
The tests were run using
PYTHONPATH=.. python runtests.py --settings test_sqlite
in the tests subdirectory.
Regards,
Vinay Sajip
--
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: Awkwardness of overriding View.dispatch for method-agnostic request-handling
I agree that there is a need for this -- it has come up several times for me now -- however, I prefer my proposal (pretty printed here: https://gist.github.com/1957251 , code below...) mentioned in the topic "Class based views: A standard hook for http-method-independent code" (https://groups.google.com/d/topic/django-developers/7c7aI-slGNc/discussion). Instead of separating the handler, I proposed a prepare_view method. def dispatch(self, request, *args, **kwargs): if request.method.lower() in self.http_method_names: handler = getattr(self, request.method.lower(), self.http_method_not_allowed) else: handler = self.http_method_not_allowed self.prepare_view(request, handler, *args, **kwargs) return handler(request, *args, **kwargs) def prepare_view(self, request, handler, *args, **kwargs): """Set local variables before the dispatch handler is called.""" self.request = request self.args = args self.kwargs = kwargs On Wednesday, April 11, 2012 7:12:51 AM UTC+1, schinckel wrote: I agree: but this means that the actual dispatcher (that, according to the comments, "dispatch[es] to the right method", is called handle(), rather than dispatch. Perhaps the assignation of request/args/kwargs could happen before dispatch is called? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/yMkwcy8ehnkJ. 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: Errors in tests
The errors seem to be related to Aymeric's change in r17894. If I
change
def _reset_dicts(self, value=None):
builtins = {'True': True, 'False': False, 'None': None}
if value:
builtins.update(value)
self.dicts = [builtins]
to the seemingly equivalent
def _reset_dicts(self, value=None):
value = copy(value or {})
value.update({'True': True, 'False': False, 'None': None})
self.dicts = [value]
then the errors no longer occur.
Ticket created: https://code.djangoproject.com/ticket/18103
Regards,
Vinay Sajip
--
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: Errors in tests
On 11 April 2012 13:37, Vinay Sajip wrote:
> The errors seem to be related to Aymeric's change in r17894. If I
> change
>
> def _reset_dicts(self, value=None):
> builtins = {'True': True, 'False': False, 'None': None}
> if value:
> builtins.update(value)
> self.dicts = [builtins]
>
> to the seemingly equivalent
>
> def _reset_dicts(self, value=None):
> value = copy(value or {})
> value.update({'True': True, 'False': False, 'None': None})
> self.dicts = [value]
>
> then the errors no longer occur.
I think this is even more correct, as the previous function allowed
for overriding "True" to something else. Although, that might break
somebody's template :)
As for the error, it's quite a puzzle. If update() tries to iterate
thru value, it means it's a non-empty sequence that's not a subclass
of dict, right? Did you manage to track what type of value it is?
There must be a bug somewhere else too.
--
Łukasz Rekucki
--
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: Errors in tests
On Apr 11, 2:50 pm, Łukasz Rekucki wrote:
> As for the error, it's quite a puzzle. If update() tries to iterate
> thru value, it means it's a non-empty sequence that's not a subclass
> of dict, right? Did you manage to track what type of value it is?
> There must be a bug somewhere else too.
When you iterate through a Context instance, you are iterating through
the dictionaries in the context:
In [1]: from django.template import Context
In [2]: c = Context()
In [3]: for d in c:
...: print d
{}
In [4]: c.update({'fuu': 'bar'})
Out[4]: {'fuu': 'bar'}
In [5]: for d in c:
print d
{'fuu': 'bar'}
{}
There is some discussion at https://code.djangoproject.com/ticket/17229,
and the core problem is that you really should not set a context
instance as one of the context dictionaries. However this is done in
many places in our code base, and I suspect user code does this, too.
At this point it might make sense to just revert the commit and then
investigate what to do. I see two ways forward: either disallow
context instances completely, or flatten the context instance to a
Python dict and use that as the base dictionary. So, something like:
is isinstance(value, Context):
value = flatten_context_to_dict(value)
else:
value = {}
value.update(builtins)
self._dicts=[value]
The latter option seems better - it does not risk breaking user code.
- Anssi
--
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.
Django is not a serious framework, really
Hi, I download and tried to use the Django 1.4 yesterday. I am a dummy and I just follow the official document, but When I just start a project. I found that it is what I see from my computer: jason@jason-pc:~/workspace/hunqing$ tree . . ├── hunqing │ ├── __init__.py │ ├── __init__.pyc │ ├── settings.py │ ├── settings.pyc │ ├── urls.py │ ├── urls.pyc │ ├── wsgi.py │ └── wsgi.pyc ├── __init__.py ├── manage.py ├── settings.py └── urls.py but what doc say? mysite/ manage.py mysite/ __init__.py settings.py urls.py wsgi.py If you're a beginner, what are you going to say, yes, F! Why I created more files? I heavily doubted that whether the writers have tested that carefully. Ok, forget that, We'll see and continue. In the later chapter, we created two classes in the models.py in polls, I do all the steps same as the doc except that one columns name, mine is questions whereas the doc is question, so I want to test the power of the syncdb, I modified the model.py and I just do the python manage.py sql polls, that's ok, it is correct name this time. So I just run it to change it in database using python manage.py syncdb, it works too. But go to the db and see, the table is not changed at all. I want to say F again now. That's what doc say: The syncdb command runs the SQL from sqlall on your database for all apps in INSTALLED_APPS that don't already exist in your database. This creates all the tables, initial data and indexes for any apps you've added to your project since the last time you ran syncdb. syncdb can be called as often as you like, and it will only ever create the tables that don't exist. That's gr8, If you just create the tables that don't exist, why do you syncdb successfully? One basic rule of database is consistence, if you can't created the tables you want, why don't get alert? I am not a good programmer though, I do know if you can't do something, just say it. How can I know the error without any prompt? There are many people saying the Django is well-documented, do you still think it is true? -- Best wishes, Jason Ma HP Enterprise Services -- 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: Django is not a serious framework, really
Hi Jason, pyc are compiled py files ... it means you most likely ran the code before doing the "ls". As for the structure of the directories, I'm fairly certain that its MySite first, then MyApp, not 2x mysite. Not going to speak on the database syncs, other then that they work fine for me. I'd also suggest you don't use titles like you do, don't post user problems in the developers list (this is for core django development discussions, not users having problems). If your comment with file layouts was regarding the ".pyc" files, might I suggest you first read a bit of the basics on Python. They aren't really essential, but if pyc files confuse and agitate you as much as your message title suggest, it might alleviate quite a bit of stress. r/Jan 2012/4/11 Jason Ma > Hi, >I download and tried to use the Django 1.4 yesterday. I am a dummy > and I just follow the official document, but When I just start a > project. > I found that it is what I see from my computer: > > jason@jason-pc:~/workspace/hunqing$ tree . > . > ├── hunqing > │ ├── __init__.py > │ ├── __init__.pyc > │ ├── settings.py > │ ├── settings.pyc > │ ├── urls.py > │ ├── urls.pyc > │ ├── wsgi.py > │ └── wsgi.pyc > ├── __init__.py > ├── manage.py > ├── settings.py > └── urls.py > > but what doc say? > mysite/ >manage.py >mysite/ >__init__.py >settings.py >urls.py >wsgi.py > > If you're a beginner, what are you going to say, yes, F! Why I created > more files? I heavily doubted that whether the writers have tested > that carefully. Ok, forget that, We'll see and continue. > In the later chapter, we created two classes in the models.py in > polls, I do all the steps same as the doc except that one columns > name, mine is questions whereas the doc is question, so I want to test > the power of the syncdb, I modified the model.py and I just do the > python manage.py sql polls, that's ok, it is correct name this time. > So I just run it to change it in database using python manage.py > syncdb, it works too. But go to the db and see, the table is not > changed at all. I want to say F again now. That's what doc say: > > The syncdb command runs the SQL from sqlall on your database for all > apps in INSTALLED_APPS that don't already exist in your database. This > creates all the tables, initial data and indexes for any apps you've > added to your project since the last time you ran syncdb. syncdb can > be called as often as you like, and it will only ever create the > tables that don't exist. > > That's gr8, If you just create the tables that don't exist, why do you > syncdb successfully? One basic rule of database is consistence, if you > can't created the tables you want, why don't get alert? I am not a > good programmer though, I do know if you can't do something, just say > it. How can I know the error without any prompt? > > There are many people saying the Django is well-documented, do you > still think it is true? > > -- > Best wishes, > > Jason Ma > HP Enterprise Services > > -- > 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. > > -- 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: Django is not a serious framework, really
On Wednesday, 11 April 2012 at 8:10 PM, Jason Ma wrote: > Hi, > I download and tried to use the Django 1.4 yesterday. I am a dummy > and I just follow the official document, but When I just start a > project. > I found that it is what I see from my computer: > > jason@jason-pc:~/workspace/hunqing$ tree . > . > ├── hunqing > │ ├── __init__.py > │ ├── __init__.pyc > │ ├── settings.py > │ ├── settings.pyc > │ ├── urls.py > │ ├── urls.pyc > │ ├── wsgi.py > │ └── wsgi.pyc > ├── __init__.py > ├── manage.py > ├── settings.py > └── urls.py > > but what doc say? > mysite/ > manage.py > mysite/ > __init__.py > settings.py > urls.py > wsgi.py First rule: If you're following a tutorial and want to follow along, you need to actually follow the instructions as given. The tutorial asks you to type: django-admin.py startproject mysite >From the looks of it, you didn't type that. You typed: django-admin.py startproject hunqing Furthermore, you've evidently run some of the code before you looked at the directory structure. .pyc files are the Python runtime's precompiled byte code output. If you look at the directory structure at the point the tutorial asks you to, you shouldn't see any .pyc files. If you're using an IDE, it's possible the IDE might have compiled these files for you. Regardless, the existence of .pyc files shouldn't be a surprise to anyone that has used Python before. Django's installation guides tells you that you're going to need to install Python -- that should be enough of a hint that you're probably going to need to know a little bit about Python in order to use Django. Django's tutorial can't -- nor should it -- teach you everything there is to know about Python. At some point, we have to assume that you're going to learn the language that Django uses. > If you're a beginner, what are you going to say, yes, F! Why I created > more files? I heavily doubted that whether the writers have tested > that carefully. Ok, forget that, We'll see and continue. We've checked the tutorial quite carefully. To be doubly sure, I've just worked through the start of the tutorial myself to make sure it matches what is described -- and it does. If you follow the instructions as written, you should get the output as described. If you don't follow the instructions as written, then its anyone's guess what you'll get. > In the later chapter, we created two classes in the models.py in > polls, I do all the steps same as the doc except that one columns > name, mine is questions whereas the doc is question, so I want to test > the power of the syncdb, I modified the model.py and I just do the > python manage.py sql polls, that's ok, it is correct name this time. > So I just run it to change it in database using python manage.py > syncdb, it works too. But go to the db and see, the table is not > changed at all. I want to say F again now. That's what doc say: > > The syncdb command runs the SQL from sqlall on your database for all > apps in INSTALLED_APPS that don't already exist in your database. This > creates all the tables, initial data and indexes for any apps you've > added to your project since the last time you ran syncdb. syncdb can > be called as often as you like, and it will only ever create the > tables that don't exist. > > That's gr8, If you just create the tables that don't exist, why do you > syncdb successfully? One basic rule of database is consistence, if you > can't created the tables you want, why don't get alert? I am not a > good programmer though, I do know if you can't do something, just say > it. How can I know the error without any prompt? But it *does* give you a prompt. When you run syncdb, the output tells you exactly what has, and what has not, been created. So, if a table for myapp.MyModel has been created, in the output of syncdb you'll see a message that looks something like: Creating table myapp_mymodel If you then go and modify MyModel, and then run syncdb again, you won't see this message. That means that the table hasn't been created as a result of your syncdb call. If you run syncdb, and you *don't* see a "Creating table" message that you were expecting, then you should probably go looking to see why. > There are many people saying the Django is well-documented, do you > still think it is true? I may be biased, but I certainly think so. If you print Django's documentation, it runs to over 900 pages. That's not 900 pages of auto generated JavaDoc style APIs, either -- it's 900 pages of hand-crafted prose. There aren't too many open source frameworks (or frameworks of any stripe, for that matter) that can claim that. As for the question in your subject -- Is Django a "Serious framework"? Well, Instagram just got sold for $1 billion, and it's a Django site. AMD, Canonical, Discovery, Disqus, HP, IBM, Intel, Lexis-Nexis, the Library of Congress, Mozilla, NASA, National Geographic, the New York Times, Orbitz, PBS, Pinterest, Rdio, VMWare
Re: Django is not a serious framework, really
Hi Jan, I don't mean the .pyc files in the folder, If it was that, everything will be fine. Please read what I typed carefully. And please test the case I just mentioned, I tested again and still the same situation. It maybe the feature, but hope it will get more user-friendly because we are all human being right? We will get more fun if we get more helpful document. Forget it if it bother you. Regards, Jason 在 2012年4月11日 下午8:27，Jan Schotsmans 写道： > Hi Jason, > > pyc are compiled py files ... it means you most likely ran the code before > doing the "ls". > > As for the structure of the directories, I'm fairly certain that its MySite > first, then MyApp, not 2x mysite. > > Not going to speak on the database syncs, other then that they work fine for > me. > > I'd also suggest you don't use titles like you do, don't post user problems > in the developers list (this is for core django development discussions, not > users having problems). > > If your comment with file layouts was regarding the ".pyc" files, might I > suggest you first read a bit of the basics on Python. They aren't really > essential, but if pyc files confuse and agitate you as much as your message > title suggest, it might alleviate quite a bit of stress. > > r/Jan > > 2012/4/11 Jason Ma >> >> Hi, >>I download and tried to use the Django 1.4 yesterday. I am a dummy >> and I just follow the official document, but When I just start a >> project. >> I found that it is what I see from my computer: >> >> jason@jason-pc:~/workspace/hunqing$ tree . >> . >> ├── hunqing >> │ ├── __init__.py >> │ ├── __init__.pyc >> │ ├── settings.py >> │ ├── settings.pyc >> │ ├── urls.py >> │ ├── urls.pyc >> │ ├── wsgi.py >> │ └── wsgi.pyc >> ├── __init__.py >> ├── manage.py >> ├── settings.py >> └── urls.py >> >> but what doc say? >> mysite/ >>manage.py >>mysite/ >>__init__.py >>settings.py >>urls.py >>wsgi.py >> >> If you're a beginner, what are you going to say, yes, F! Why I created >> more files? I heavily doubted that whether the writers have tested >> that carefully. Ok, forget that, We'll see and continue. >> In the later chapter, we created two classes in the models.py in >> polls, I do all the steps same as the doc except that one columns >> name, mine is questions whereas the doc is question, so I want to test >> the power of the syncdb, I modified the model.py and I just do the >> python manage.py sql polls, that's ok, it is correct name this time. >> So I just run it to change it in database using python manage.py >> syncdb, it works too. But go to the db and see, the table is not >> changed at all. I want to say F again now. That's what doc say: >> >> The syncdb command runs the SQL from sqlall on your database for all >> apps in INSTALLED_APPS that don't already exist in your database. This >> creates all the tables, initial data and indexes for any apps you've >> added to your project since the last time you ran syncdb. syncdb can >> be called as often as you like, and it will only ever create the >> tables that don't exist. >> >> That's gr8, If you just create the tables that don't exist, why do you >> syncdb successfully? One basic rule of database is consistence, if you >> can't created the tables you want, why don't get alert? I am not a >> good programmer though, I do know if you can't do something, just say >> it. How can I know the error without any prompt? >> >> There are many people saying the Django is well-documented, do you >> still think it is true? >> >> -- >> Best wishes, >> >> Jason Ma >> HP Enterprise Services >> >> -- >> 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. >> > > -- > 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. -- Best wishes, Jason Ma -- 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: Django is not a serious framework, really
Hi Jason, Le 11 avril 2012 14:10, Jason Ma a écrit : > I heavily doubted that whether the writers have tested that carefully. As one of the many people who replayed the tutorial from A to Z, checked every little detail, updated screenshots, etc. before the release of 1.4, I feel your feedback is rather unfair. > There are many people saying the Django is well-documented, do you > still think it is true? Django's documentation assumes that the reader: - has some familiarity with Python (e.g. knows what a __init__.py or a *.pyc file is) - is an autodidact and is able to investigate by himself when (s)he deviates from the recommended path and encounters an unexpected behavior (e.g. syncdb doesn't perform migrations). Honestly, if this doesn't match your expectations at all, then Django might not be the right framework for you. I still believe our documentation compares favorably to most open-source software entirely developed by volunteers in their free time. Best regards, -- Aymeric. -- 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: Django is not a serious framework, really
gooby pls :) On Wed, Apr 11, 2012 at 10:29 AM, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > Hi Jason, > > Le 11 avril 2012 14:10, Jason Ma a écrit : > > I heavily doubted that whether the writers have tested that carefully. > > As one of the many people who replayed the tutorial from A to Z, > checked every little detail, updated screenshots, etc. before the > release of 1.4, I feel your feedback is rather unfair. > > > There are many people saying the Django is well-documented, do you > > still think it is true? > > Django's documentation assumes that the reader: > - has some familiarity with Python (e.g. knows what a __init__.py or a > *.pyc file is) > - is an autodidact and is able to investigate by himself when (s)he > deviates from the recommended path and encounters an unexpected > behavior (e.g. syncdb doesn't perform migrations). > > Honestly, if this doesn't match your expectations at all, then Django > might not be the right framework for you. > > I still believe our documentation compares favorably to most > open-source software entirely developed by volunteers in their free > time. > > Best regards, > > -- > Aymeric. > > -- > 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. > > -- juanpex -- 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: Django is not a serious framework, really
I wonder why you guys are replying OP. On 4/11/12, Juan Pablo Martínez wrote: > gooby pls :) > > On Wed, Apr 11, 2012 at 10:29 AM, Aymeric Augustin < > aymeric.augus...@polytechnique.org> wrote: > >> Hi Jason, >> >> Le 11 avril 2012 14:10, Jason Ma a écrit : >> > I heavily doubted that whether the writers have tested that carefully. >> >> As one of the many people who replayed the tutorial from A to Z, >> checked every little detail, updated screenshots, etc. before the >> release of 1.4, I feel your feedback is rather unfair. >> >> > There are many people saying the Django is well-documented, do you >> > still think it is true? >> >> Django's documentation assumes that the reader: >> - has some familiarity with Python (e.g. knows what a __init__.py or a >> *.pyc file is) >> - is an autodidact and is able to investigate by himself when (s)he >> deviates from the recommended path and encounters an unexpected >> behavior (e.g. syncdb doesn't perform migrations). >> >> Honestly, if this doesn't match your expectations at all, then Django >> might not be the right framework for you. >> >> I still believe our documentation compares favorably to most >> open-source software entirely developed by volunteers in their free >> time. >> >> Best regards, >> >> -- >> Aymeric. >> >> -- >> 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. >> >> > > > -- > juanpex > > -- > 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. > > -- Sent from my mobile device -- 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: Django is not a serious framework, really
Hi, Jason, I suggest you go to the django-users list for help: http://groups.google.com/group/django-users This list is only for django core development (aka, the framework itself), not for people using Django. And, it's no bother, but you came on rather strong, with wording that real world information, directly contradicts, not only is Django used for a variety of sites, it is also used by some very high profile sites and corporations. Besides that, the documentation is worked on almost as hard as Django's core, very little auto generated content and it is checked, for each release, by a multitude of people. If you found an actual error in said documentation, it would be best to give detailed information and start a constructive conversation about the issue's, so that it can be resolved. Starting with a premise that mostly condenses down to "Django/Django Documentation is a 3de rate POS", isn't very constructive and will only serve to tick of the developers that put their free time into creating this application. But as someone else replied already and I just did again, when following the documentation point by point, the correct layouts and behavior, are obtained as expressed in the documentation. If you repost your problem to the appropriate list (django-users), I would also suggest you give a bit more information. Things like: Python version. OS you are using. (and I think in your case the language of the OS might be useful). Exact commands you used to. Etc. The more information the better. r/Jan 2012/4/11 Jason Ma > Hi Jan, >I don't mean the .pyc files in the folder, If it was that, > everything will be fine. Please read what I typed carefully. And > please test the case I just mentioned, I tested again and still the > same situation. It maybe the feature, but hope it will get more > user-friendly because we are all human being right? We will get more > fun if we get more helpful document. Forget it if it bother you. > > Regards, > Jason > > 在 2012年4月11日 下午8:27，Jan Schotsmans 写道： > > Hi Jason, > > > > pyc are compiled py files ... it means you most likely ran the code > before > > doing the "ls". > > > > As for the structure of the directories, I'm fairly certain that its > MySite > > first, then MyApp, not 2x mysite. > > > > Not going to speak on the database syncs, other then that they work fine > for > > me. > > > > I'd also suggest you don't use titles like you do, don't post user > problems > > in the developers list (this is for core django development discussions, > not > > users having problems). > > > > If your comment with file layouts was regarding the ".pyc" files, might I > > suggest you first read a bit of the basics on Python. They aren't really > > essential, but if pyc files confuse and agitate you as much as your > message > > title suggest, it might alleviate quite a bit of stress. > > > > r/Jan > > > > 2012/4/11 Jason Ma > >> > >> Hi, > >>I download and tried to use the Django 1.4 yesterday. I am a dummy > >> and I just follow the official document, but When I just start a > >> project. > >> I found that it is what I see from my computer: > >> > >> jason@jason-pc:~/workspace/hunqing$ tree . > >> . > >> ├── hunqing > >> │ ├── __init__.py > >> │ ├── __init__.pyc > >> │ ├── settings.py > >> │ ├── settings.pyc > >> │ ├── urls.py > >> │ ├── urls.pyc > >> │ ├── wsgi.py > >> │ └── wsgi.pyc > >> ├── __init__.py > >> ├── manage.py > >> ├── settings.py > >> └── urls.py > >> > >> but what doc say? > >> mysite/ > >>manage.py > >>mysite/ > >>__init__.py > >>settings.py > >>urls.py > >>wsgi.py > >> > >> If you're a beginner, what are you going to say, yes, F! Why I created > >> more files? I heavily doubted that whether the writers have tested > >> that carefully. Ok, forget that, We'll see and continue. > >> In the later chapter, we created two classes in the models.py in > >> polls, I do all the steps same as the doc except that one columns > >> name, mine is questions whereas the doc is question, so I want to test > >> the power of the syncdb, I modified the model.py and I just do the > >> python manage.py sql polls, that's ok, it is correct name this time. > >> So I just run it to change it in database using python manage.py > >> syncdb, it works too. But go to the db and see, the table is not > >> changed at all. I want to say F again now. That's what doc say: > >> > >> The syncdb command runs the SQL from sqlall on your database for all > >> apps in INSTALLED_APPS that don't already exist in your database. This > >> creates all the tables, initial data and indexes for any apps you've > >> added to your project since the last time you ran syncdb. syncdb can > >> be called as often as you like, and it will only ever create the > >> tables that don't exist. > >> > >> That's gr8, If you just create the tables that don't exist, why do you > >> syncdb successfully? One basic rule of database is consistence, if you > >
Re: Django is not a serious framework, really
Would it be hard for django to check during syncdb and complain that a schema migration is required for an app? I vaguely recall being stumped myself after changing a model, running syndb and getting my first database integrity error. I believe even a NOTE in the tutorial clarifying that schema migration is not automatic yet would be sufficient. First impression of new comers to django are rather important I believe. -Original Message- From: Russell Keith-Magee Sent: Wednesday, April 11, 2012 8:54 AM To: django-developers@googlegroups.com Subject: Re: Django is not a serious framework, really On Wednesday, 11 April 2012 at 8:10 PM, Jason Ma wrote: Hi, I download and tried to use the Django 1.4 yesterday. I am a dummy and I just follow the official document, but When I just start a project. I found that it is what I see from my computer: jason@jason-pc:~/workspace/hunqing$ tree . . ├── hunqing │ ├── __init__.py │ ├── __init__.pyc │ ├── settings.py │ ├── settings.pyc │ ├── urls.py │ ├── urls.pyc │ ├── wsgi.py │ └── wsgi.pyc ├── __init__.py ├── manage.py ├── settings.py └── urls.py but what doc say? mysite/ manage.py mysite/ __init__.py settings.py urls.py wsgi.py First rule: If you're following a tutorial and want to follow along, you need to actually follow the instructions as given. The tutorial asks you to type: django-admin.py startproject mysite From the looks of it, you didn't type that. You typed: django-admin.py startproject hunqing Furthermore, you've evidently run some of the code before you looked at the directory structure. .pyc files are the Python runtime's precompiled byte code output. If you look at the directory structure at the point the tutorial asks you to, you shouldn't see any .pyc files. If you're using an IDE, it's possible the IDE might have compiled these files for you. Regardless, the existence of .pyc files shouldn't be a surprise to anyone that has used Python before. Django's installation guides tells you that you're going to need to install Python -- that should be enough of a hint that you're probably going to need to know a little bit about Python in order to use Django. Django's tutorial can't -- nor should it -- teach you everything there is to know about Python. At some point, we have to assume that you're going to learn the language that Django uses. If you're a beginner, what are you going to say, yes, F! Why I created more files? I heavily doubted that whether the writers have tested that carefully. Ok, forget that, We'll see and continue. We've checked the tutorial quite carefully. To be doubly sure, I've just worked through the start of the tutorial myself to make sure it matches what is described -- and it does. If you follow the instructions as written, you should get the output as described. If you don't follow the instructions as written, then its anyone's guess what you'll get. In the later chapter, we created two classes in the models.py in polls, I do all the steps same as the doc except that one columns name, mine is questions whereas the doc is question, so I want to test the power of the syncdb, I modified the model.py and I just do the python manage.py sql polls, that's ok, it is correct name this time. So I just run it to change it in database using python manage.py syncdb, it works too. But go to the db and see, the table is not changed at all. I want to say F again now. That's what doc say: The syncdb command runs the SQL from sqlall on your database for all apps in INSTALLED_APPS that don't already exist in your database. This creates all the tables, initial data and indexes for any apps you've added to your project since the last time you ran syncdb. syncdb can be called as often as you like, and it will only ever create the tables that don't exist. That's gr8, If you just create the tables that don't exist, why do you syncdb successfully? One basic rule of database is consistence, if you can't created the tables you want, why don't get alert? I am not a good programmer though, I do know if you can't do something, just say it. How can I know the error without any prompt? But it *does* give you a prompt. When you run syncdb, the output tells you exactly what has, and what has not, been created. So, if a table for myapp.MyModel has been created, in the output of syncdb you'll see a message that looks something like: Creating table myapp_mymodel If you then go and modify MyModel, and then run syncdb again, you won't see this message. That means that the table hasn't been created as a result of your syncdb call. If you run syncdb, and you *don't* see a "Creating table" message that you were expecting, then you should probably go looking to see why. There are many people saying the Django is well-documented, do you still think it is true? I may be biased, but I certainly think so. If you print Django's documentation, it runs to over 900 pages. That's not 900 pages of auto generated Ja
Re: Django is not a serious framework, really
I wonder how someone can write such a provocative message as the thread-starter. Django - is great - thanks for all! On Wed, 2012-04-11 at 14:57 +0100, Babatunde Akinyanmi wrote: > I wonder why you guys are replying OP. > > On 4/11/12, Juan Pablo Martínez wrote: > > gooby pls :) > > > > On Wed, Apr 11, 2012 at 10:29 AM, Aymeric Augustin < > > aymeric.augus...@polytechnique.org> wrote: > > > >> Hi Jason, > >> > >> Le 11 avril 2012 14:10, Jason Ma a écrit : > >> > I heavily doubted that whether the writers have tested that carefully. > >> > >> As one of the many people who replayed the tutorial from A to Z, > >> checked every little detail, updated screenshots, etc. before the > >> release of 1.4, I feel your feedback is rather unfair. > >> > >> > There are many people saying the Django is well-documented, do you > >> > still think it is true? > >> > >> Django's documentation assumes that the reader: > >> - has some familiarity with Python (e.g. knows what a __init__.py or a > >> *.pyc file is) > >> - is an autodidact and is able to investigate by himself when (s)he > >> deviates from the recommended path and encounters an unexpected > >> behavior (e.g. syncdb doesn't perform migrations). > >> > >> Honestly, if this doesn't match your expectations at all, then Django > >> might not be the right framework for you. > >> > >> I still believe our documentation compares favorably to most > >> open-source software entirely developed by volunteers in their free > >> time. > >> > >> Best regards, > >> > >> -- > >> Aymeric. > >> > >> -- > >> 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. > >> > >> > > > > > > -- > > juanpex > > > > -- > > 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. > > > > > > -- > Sent from my mobile device > -- 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: Django is not a serious framework, really
The document clearly states that "You'll see a message for each database table it creates". I guess Jason Ma had a hard time reading the document because it is written in English. Native Chinese speakers who are not quite familiar with English will feel desperate when they had to read serveral pages of document in English. Just imagine how desperate will you be if you have to read pages of document in Chinese when you just learned Ni Hao. Django is getting more and more popular in China recently. More and more people there are asking questions like how to do this or that in Django, most of the time, it is just because it is too hard for them to understand the document on their own. I propose that Django has a Chinese translation of its document. Sure, there is a huge amount of work. If core team decides to work on this, I would like to help. Disclaimer: I do not know Jason Ma, I guess he is a Native Chinese speaker because I googled his email found his email appears on some Chinese website. On 4月11日, 下午9时29分, Aymeric Augustin wrote: > Hi Jason, > > Le 11 avril 2012 14:10, Jason Ma a écrit : > > > I heavily doubted that whether the writers have tested that carefully. > > As one of the many people who replayed the tutorial from A to Z, > checked every little detail, updated screenshots, etc. before the > release of 1.4, I feel your feedback is rather unfair. > > > There are many people saying the Django is well-documented, do you > > still think it is true? > > Django's documentation assumes that the reader: > - has some familiarity with Python (e.g. knows what a __init__.py or a > *.pyc file is) > - is an autodidact and is able to investigate by himself when (s)he > deviates from the recommended path and encounters an unexpected > behavior (e.g. syncdb doesn't perform migrations). > > Honestly, if this doesn't match your expectations at all, then Django > might not be the right framework for you. > > I still believe our documentation compares favorably to most > open-source software entirely developed by volunteers in their free > time. > > Best regards, > > -- > Aymeric. -- 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: Django is not a serious framework, really
I saw the Chinese date-stamp in his email and deducted the same, hence why I said it might be wise to add the language of his installation, so people are aware (but to django-users). Don't really know what serveral pages are, but I do understand language barrier problems :p (just kidding, hugz typo's) As for a Chinese documentation project, I think that might be something for the Chinese users, who are fluent in English, to do. I don't think many of the devs are versed in Mandarin or Cantonese, (other then the little Cantonese they might have picked up from watching movies out of Hong Kong XD). Personally, as I keep telling people in my lil country, even if it bothers you, try doing stuff in other languages, knowing them will only benefit you in the long run. I personally hate dubbed TV shows, especially children programs for over the age of 8. If they leave them in the native language, with subtitles, the kids will pick up the basics of the languages very easily and the more contact they have at a young age, with other languages, the more easily they'll learn new languages throughout their life. But, for older users, I can certainly understand it to be a potential source of frustrations, even more so, if you are professionally tasked to research the subject and don't have the time to get well versed in English. r/Jan 2012/4/11 bhuztez > The document clearly states that "You'll see a message for each > database table it creates". > > I guess Jason Ma had a hard time reading the document because it is > written in English. Native Chinese speakers who are not quite familiar > with English will feel desperate when they had to read serveral pages > of document in English. Just imagine how desperate will you be if you > have to read pages of document in Chinese when you just learned Ni > Hao. > > Django is getting more and more popular in China recently. More and > more people there are asking questions like how to do this or that in > Django, most of the time, it is just because it is too hard for them > to understand the document on their own. I propose that Django has a > Chinese translation of its document. Sure, there is a huge amount of > work. If core team decides to work on this, I would like to help. > > > Disclaimer: I do not know Jason Ma, I guess he is a Native Chinese > speaker because I googled his email found his email appears on some > Chinese website. > > > On 4月11日, 下午9时29分, Aymeric Augustin > wrote: > > Hi Jason, > > > > Le 11 avril 2012 14:10, Jason Ma a écrit : > > > > > I heavily doubted that whether the writers have tested that carefully. > > > > As one of the many people who replayed the tutorial from A to Z, > > checked every little detail, updated screenshots, etc. before the > > release of 1.4, I feel your feedback is rather unfair. > > > > > There are many people saying the Django is well-documented, do you > > > still think it is true? > > > > Django's documentation assumes that the reader: > > - has some familiarity with Python (e.g. knows what a __init__.py or a > > *.pyc file is) > > - is an autodidact and is able to investigate by himself when (s)he > > deviates from the recommended path and encounters an unexpected > > behavior (e.g. syncdb doesn't perform migrations). > > > > Honestly, if this doesn't match your expectations at all, then Django > > might not be the right framework for you. > > > > I still believe our documentation compares favorably to most > > open-source software entirely developed by volunteers in their free > > time. > > > > Best regards, > > > > -- > > Aymeric. > > -- > 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. > > -- 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: Django is a serious framework, really
The other day I went back to one of my first django projects. It's running on production since 2007/2008 flawlessly serving a rather complex scientific database for about 10 visits/month, still using django 1.1. The reason was that the current maintainer needed some help with the project and django. I was extremely happy to see how easy it was to get back to an understanding of the code and to show the current maintainer what he missed. He is not a programmer, but only got some variables wrong and missed to write a view function. The problem and another problem, too, were solved within an hour. Django has it's limits, but it is one of the most serious frameworks out there. Thanks to everyone who contributes to it and especially to those who took the best of python and designed an API and project structure which prove to be well-arranged til today. -- erik Am 11.04.2012 um 14:54 schrieb Russell Keith-Magee: > On Wednesday, 11 April 2012 at 8:10 PM, Jason Ma wrote: [snip] Erik Stein Programmierung, Grafik Oranienstr. 32 10999 Berlin, Germany fon +49 30 69201880 fax +49 30 692018809 email e...@classlibrary.net -- 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: Admin site: Appropriateness of HTTP 500 when using non-allowed query strings
Julien, I'm not describing an edge case. Django will return an HTTP 500 for ANY field lookup on a related model that is not in the list_filter option. To test, simply create a model that has a ForeignKey to another model and hook it up into the admin site. Don't include any list_filter options. Then craft a valid query string on the change list page that queries a field on the related model. You will get an HTTP 500. For example: myapp/models.py: class MyModel(models.Model): parent = ForeignKey(AnotherModel) myapp/admin.py admin.site.register(MyModel) then visit http://localhost:8000/admin/myapp/mymodel/?parent__pk=1 and you will get a SuspiciousOperation exception with a return code of 500. Just to be clear, I'm not against the SuspiciousOperation exception being raised. I just think it should use a more appropriate HTTP status code, like 403. On Apr 11, 11:47 am, Julien Phalip wrote: > On Apr 10, 2012, at 4:34 AM, 3point2 wrote: > > > > > > > > > > > The admin site allows the use of certain query strings to filter > > change list pages. The syntax follows queryset field lookups, for > > examplehttp://mysite.com/admin/myapp/mymodel/?field__exact=test. > > Lookups that are not specified on the ModelAdmin's list_filter option > > raise a SuspiciousOperation exception. This is done to prevent a > > normal user from obtaining sensitive information (e.g. password > > hashes). > > > In production use, I'm not sure that returning an HTTP code of 500 > > (internal server error) and emailing the server admins is an > > appropriate response to a user manipulating the query string. > > > I think that 403 (forbidden) would be more accurate. In my mind, 500 > > suggests that something went wrong on the server, for example an > > unexpected condition or exception in the application code. In this > > situation, this is not the case. Django is deliberately forbidding a > > user from accessing information for which they have not been > > authorized. > > > Any thoughts? > > I agree that no 500 response should be returned only by passing improper > querystring parameters, unless those parameters match a custom list filter > and that filter raises an unhandled exception. There is already a system in > place to avoid this problem though, so if you've found an edge case could you > please create a new ticket in Trac with a test case? > > Thanks a lot, > > Julien > > smime.p7s > 1KViewDownload -- 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: So has Instagram...
Folks. this is pretty far off-topic; let's take M&A discussions elsewhere please. Jacob On Wednesday, April 11, 2012 at 12:55 AM, shacker wrote: > On Monday, April 9, 2012 10:03:57 PM UTC-7, diogobaeder wrote: > > ... just been acquired by Facebook? And it uses Django? > > > > Indeed. We can only hope that Instagram will stay on Django under Facebook's > care, though I won't be surprised if it's eventually subsumed into their PHP > soup. > > But speaking of giving thanks, I'd like to do that too. After working mostly > in Django over the past five years, I recently switched jobs into a Java shop > running a "minor" framework, and came face to face with how much complexity > it takes to build complex systems without something like Django working for > you behind the scenes. It really is shocking to see the contortions some > institutions go through to get things done that Django and Rails people now > consider almost trivial. So here's a huge helping of thanks to all of the > work the Django developers and contributors have put into it over the years, > for all of the efficiencies and pleasantness we all have enjoyed on account > of it. Your work is deeply appreciated. > > ./s > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-developers/-/1NmvhUTCNd0J. > To post to this group, send email to django-developers@googlegroups.com > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto:django-developers+unsubscr...@googlegroups.com). > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. -- 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: Admin site: Appropriateness of HTTP 500 when using non-allowed query strings
If a query string references a foreign key that isn't in list_filter then
it can hardly be a "valid query string". This isn't an authorization
problem ("You lack permission to perform that operation"), it's a real
fatal error ("You asked us for something we don't understand/support").
>From a security standpoint, it's best to leak as little as possible about
structure and relations when you reach undefined behavior. Special-casing
this particular unhandled exception may leak information. Much better to
play dumb and handle it like every other unhandled exception.
It's not a code path you should ever reach in normal use, only when someone
is getting crafty with the admin URLs. A 400 response suggests that there
is a fixable error somewhere, and there isn't.
Best,
Alex Ogier
On Apr 11, 2012 2:44 PM, "3point2" wrote:
> Julien, I'm not describing an edge case. Django will return an HTTP
> 500 for ANY field lookup on a related model that is not in the
> list_filter option.
>
> To test, simply create a model that has a ForeignKey to another model
> and hook it up into the admin site. Don't include any list_filter
> options. Then craft a valid query string on the change list page that
> queries a field on the related model. You will get an HTTP 500.
>
> For example:
>
> myapp/models.py:
>
> class MyModel(models.Model):
>parent = ForeignKey(AnotherModel)
>
> myapp/admin.py
>
> admin.site.register(MyModel)
>
> then visit http://localhost:8000/admin/myapp/mymodel/?parent__pk=1 and
> you will get a SuspiciousOperation exception with a return code of
> 500.
>
> Just to be clear, I'm not against the SuspiciousOperation exception
> being raised. I just think it should use a more appropriate HTTP
> status code, like 403.
>
>
> On Apr 11, 11:47 am, Julien Phalip wrote:
> > On Apr 10, 2012, at 4:34 AM, 3point2 wrote:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > > The admin site allows the use of certain query strings to filter
> > > change list pages. The syntax follows queryset field lookups, for
> > > examplehttp://mysite.com/admin/myapp/mymodel/?field__exact=test.
> > > Lookups that are not specified on the ModelAdmin's list_filter option
> > > raise a SuspiciousOperation exception. This is done to prevent a
> > > normal user from obtaining sensitive information (e.g. password
> > > hashes).
> >
> > > In production use, I'm not sure that returning an HTTP code of 500
> > > (internal server error) and emailing the server admins is an
> > > appropriate response to a user manipulating the query string.
> >
> > > I think that 403 (forbidden) would be more accurate. In my mind, 500
> > > suggests that something went wrong on the server, for example an
> > > unexpected condition or exception in the application code. In this
> > > situation, this is not the case. Django is deliberately forbidding a
> > > user from accessing information for which they have not been
> > > authorized.
> >
> > > Any thoughts?
> >
> > I agree that no 500 response should be returned only by passing improper
> querystring parameters, unless those parameters match a custom list filter
> and that filter raises an unhandled exception. There is already a system in
> place to avoid this problem though, so if you've found an edge case could
> you please create a new ticket in Trac with a test case?
> >
> > Thanks a lot,
> >
> > Julien
> >
> > smime.p7s
> > 1KViewDownload
>
> --
> 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.
>
>
--
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: Admin site: Appropriateness of HTTP 500 when using non-allowed query strings
On Apr 11, 2012, at 11:44 AM, 3point2 wrote: > Julien, I'm not describing an edge case. Django will return an HTTP > 500 for ANY field lookup on a related model that is not in the > list_filter option. > > To test, simply create a model that has a ForeignKey to another model > and hook it up into the admin site. Don't include any list_filter > options. Then craft a valid query string on the change list page that > queries a field on the related model. You will get an HTTP 500. > > For example: > > myapp/models.py: > > class MyModel(models.Model): > parent = ForeignKey(AnotherModel) > > myapp/admin.py > > admin.site.register(MyModel) > > then visit http://localhost:8000/admin/myapp/mymodel/?parent__pk=1 and > you will get a SuspiciousOperation exception with a return code of > 500. > > Just to be clear, I'm not against the SuspiciousOperation exception > being raised. I just think it should use a more appropriate HTTP > status code, like 403. Thanks for providing a test case. It kind of is an edge case as it requires some specific unusual conditions to be reproduced. But anyways, I've verified that this behavior has been in place in Django for a long time (at least since 1.2). Also it doesn't seem to be tested at all. I do agree that a 500 isn't appropriate here. However I don't think a 403 is appropriate either. Instead it should probably redirect you to the changelist with the querystring ?e=1, just like other unhandled exceptions. Again, this behavior currently isn't tested, so more thoughts should probably be put in this. There's enough material to open a ticket though. Could you do that and provide a recap of this discussion? Regards, Julien smime.p7s Description: S/MIME cryptographic signature
Re: Django is not a serious framework, really
On Wednesday, 11 April 2012 at 11:10 PM, bhuztez wrote: > The document clearly states that "You'll see a message for each > database table it creates". > > I guess Jason Ma had a hard time reading the document because it is > written in English. Native Chinese speakers who are not quite familiar > with English will feel desperate when they had to read serveral pages > of document in English. Just imagine how desperate will you be if you > have to read pages of document in Chinese when you just learned Ni > Hao. I studied Mandarin in high school, so I know *exactly* how desperate you get :-) However, my point stands -- if he "just typed what was in the tutorial", then he *won't* get the result he described. He's doing *something* else. I have great sympathy and patience for anyone working through a language barrier, but I don't have sympathy for someone who doesn't follow the instructions, and then blames us because our instructions are wrong. > Django is getting more and more popular in China recently. More and > more people there are asking questions like how to do this or that in > Django, most of the time, it is just because it is too hard for them > to understand the document on their own. I propose that Django has a > Chinese translation of its document. Sure, there is a huge amount of > work. If core team decides to work on this, I would like to help. If someone wants to take on the task of writing and maintaining a translating of the tutorial (or the whole documentation base), I'm sure we can find a way to host it. We've always been very proud of our internationalization infrastructure, and I see no reason why this shouldn't be extended to our documentation. At one point, I believe there was a French translation of the docs; however, I don't know if that is still being maintained. Ideally, we'd have some sort of toolset to help with this sort of translation (just like we have Transifex for the in-app strings) -- but failing that, simple text with a clear warning that it possibly lags behind the English translation will probably suffice. Yours, Russ Magee %-) -- 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: Django is a serious framework, really
Yo Jason, I'm really sorry for you, and imma let you finish, but Django is one of the best frameworks of all time. (I knew I'd get a chance to use that meme one day!) On Wed, Apr 11, 2012 at 7:37 PM, Erik Stein wrote: > > -- erik > > Am 11.04.2012 um 14:54 schrieb Russell Keith-Magee: > > > On Wednesday, 11 April 2012 at 8:10 PM, Jason Ma wrote: > > [snip] > > > Erik Stein > Programmierung, Grafik >Oranienstr. 32 10999 Berlin, Germany >fon +49 30 69201880 fax +49 30 692018809 >email e...@classlibrary.net > > > > -- > 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. > > -- 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.
An appeal for insight into the development of Django
Dear developers of Django! I am a student of Software Engineering at the Vienna University of Technology and currently writing my master thesis on project management and the development methods used in open source projects. In my research I analyzed open source development and compared it with elements found in various proprietary approaches, both agile and well-defined. But to provide balanced and up-to-date results my work relies on first- hand information and expert opinion, for which I need your help. Django matches my criteria regarding size, activity and available information and I would be glad to include it in my case study. I am looking for an interview partner with good insight into the project structure and a solid overview of all stages of development, ideally a member of the core team with long-term dedication to the project. The interview would take about 20 minutes on Skype (or a similar phone- based tool). If you prefer a written chat, that can be arranged as well. My daily schedule is flexible, so whatever time suits you best should work for me. The subject areas I would like to cover in the interview are Django's: * Development flow and release cycles * Social structures, responsibilities and decision making * Code structure and architectural considerations * Special conditions caused by the open source environment I realize your time might be scarce, but if you decide to contribute to this case study your help shall be all the more appreciated. Once finished I will gladly share my results and any new insights gained on the topic with you. Kind regards, Martin Schönberger (maschon...@gmail.com) -- 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.
