compiler

[Markus Christen]

Good Morning
I have downloaded files, that can helps by my mssql-odbc connection. This 
is my downloaded file:
http://code.google.com/p/django-pyodbc/source/browse/trunk/sql_server/pyodbc/compiler.py?r=190
 
On lines 188 and 273, i become the message "'return' outside of function". 
It's not a space/tab fail, i have checked this.
How can i fix this?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/uvBBHw13tokJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Posting from HTTP to HTTPS on same domain results in CSRF failure

[Kevin]

Hello everyone,

  I am in the process of deploying a Django app which works both on HTTP 
and HTTPS connections, and require that some specific forms only submit via 
HTTPS.  I want the transition process over to HTTPS to be seamless for the 
end-user.  I am implementing this on a site-wide login form.

  Are there any workarounds for this or any middleware I can create to 
allow same domain HTTP to HTTPS transition without worrying about CSRF 
tokens being declined?  To ensure it wasn't a stale cookie issue, I just 
cleared my cookies before posting this.

  The csrf cookie is allowed for any connection, according to Firefox's 
cookie viewer, so shouldn't this mean that the cookie will be accepted over 
HTTPS?

Thanks in advance.

Django version is 1.4 branch.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/AR9a9jddb_QJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Posting from HTTP to HTTPS on same domain results in CSRF failure

[Mike Dewhirst]

On 31/10/2012 7:21pm, Kevin wrote:

Hello everyone,

   I am in the process of deploying a Django app which works both on
HTTP and HTTPS connections, and require that some specific forms only
submit via HTTPS.  I want the transition process over to HTTPS to be
seamless for the end-user.  I am implementing this on a site-wide login
form.

   Are there any workarounds for this or any middleware I can create to
allow same domain HTTP to HTTPS transition without worrying about CSRF
tokens being declined?  To ensure it wasn't a stale cookie issue, I just
cleared my cookies before posting this.

   The csrf cookie is allowed for any connection, according to Firefox's
cookie viewer, so shouldn't this mean that the cookie will be accepted
over HTTPS?


Is there any reason you can't make the entire site https?

Ought to solve the problem. And my understanding is that https 
everywhere is a reasonable approach nowadays.





Thanks in advance.

Django version is 1.4 branch.

--
You received this message because you are subscribed to the Google
Groups "Django users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-users/-/AR9a9jddb_QJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.


--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

getting data from a dictionary in a view

[MikeKJ]

I want to interrogate a dictionary for a particular text

 cursor = connection.cursor()
 cursor.execute("SELECT distinct feature, featuredetails from features 
where the_id = %s", [id])
 feature = dictfetchall(cursor)

results in

[{'featuredetails': u'', 'feature': u'TV_SET'}, {'featuredetails': u'', 
'feature': u'INVERTER'}, {'featuredetails': u'', 'feature': u'HEATING'}]

So I want to know if the key 'feature' contains TV_SET or INVERTER or HEATING

Been trying various things for hours and not got anywhwere so far so any help 
would be much appreciated

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/_esRetDUNk8J.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Help me choose OS for django server

[Waitman Gobble]

On Tue, Oct 30, 2012 at 7:39 PM, Chris Pagnutti wrote:

> Yeah.  Hosting the videos ourselves was one of the primary requirements
> for this project.
>
>
> On Tuesday, October 30, 2012 3:50:30 PM UTC-4, Chris Pagnutti wrote:
>
>> Hi.  I want to set up a production server for a django application.
>> constant.com offers Virtual Private Servers which should give me
>> virtually full control over the server, allowing me to install django and
>> all the stuff I need for my app to run properly.
>>
>> First, is this a good idea?  Do you think I can do this securely using
>> the django, apache, and lighttpd docs? or am I asking for trouble?  What
>> are the major security issues I need to be aware of when administering a
>> server?
>>
>> Also, if I go this route, I'll need to choose an OS.  I'm running a
>> production server (just Apache + mod_wsgi) using my Arch Linux box, but I
>> don't think arch is the best idea.  I'm sorta trying to decide between
>> CentOS and Ubuntu.  Leaning toward CentOS, but just a little worried it
>> might be missing some of the packages I need.  I've never used CentOS
>> before.  Any advice?
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-users/-/NTcYbNQTX3gJ.
>
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>

Hi,

It's a great idea, why submit to the beast. There's an h.264 streaming
module for Apache that works quite nice, you might check out. Also check to
see if you qualify to pay patent royalties, i think under 10 minutes is
*gratis*. But you could deliver in webm format, it's a good *free*
alternative however I find it tends to spangle the dark tones a bit, and a
tad too weak in device/browser support.

I've used Red Hat / Fedora / RHEL / CentOS since the gay 90's so I'm
obviously pro-CentOS. On a personal level I feel like I'm being forced to
swim in jello with water wings while using Ubuntu, but it's cozy for many
folks. I understand it's popular.

Waitman Gobble
San Jose California

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Posting from HTTP to HTTPS on same domain results in CSRF failure

[Kevin Veroneau]

I did this approach before and it seems to break Google Search results. :(
I do want users to use the site and find me easily after all.
On Oct 31, 2012 6:24 AM, "Mike Dewhirst"  wrote:

> On 31/10/2012 7:21pm, Kevin wrote:
>
>> Hello everyone,
>>
>>I am in the process of deploying a Django app which works both on
>> HTTP and HTTPS connections, and require that some specific forms only
>> submit via HTTPS.  I want the transition process over to HTTPS to be
>> seamless for the end-user.  I am implementing this on a site-wide login
>> form.
>>
>>Are there any workarounds for this or any middleware I can create to
>> allow same domain HTTP to HTTPS transition without worrying about CSRF
>> tokens being declined?  To ensure it wasn't a stale cookie issue, I just
>> cleared my cookies before posting this.
>>
>>The csrf cookie is allowed for any connection, according to Firefox's
>> cookie viewer, so shouldn't this mean that the cookie will be accepted
>> over HTTPS?
>>
>
> Is there any reason you can't make the entire site https?
>
> Ought to solve the problem. And my understanding is that https everywhere
> is a reasonable approach nowadays.
>
>
>
>> Thanks in advance.
>>
>> Django version is 1.4 branch.
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Django users" group.
>> To view this discussion on the web visit
>> https://groups.google.com/d/**msg/django-users/-/AR9a9jddb_**QJ
>> .
>> To post to this group, send email to django-users@googlegroups.com.
>> To unsubscribe from this group, send email to
>> django-users+unsubscribe@**googlegroups.com
>> .
>> For more options, visit this group at
>> http://groups.google.com/**group/django-users?hl=en
>> .
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to django-users+unsubscribe@**
> googlegroups.com .
> For more options, visit this group at http://groups.google.com/**
> group/django-users?hl=en
> .
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: getting data from a dictionary in a view

[MikeKJ]

Solved using 
http://www.daniweb.com/software-development/python/code/217019/search-a-python-dictionary-both-ways
 
by Ene Uran , thanks

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/qy6IJs3ZvC0J.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Posting from HTTP to HTTPS on same domain results in CSRF failure

[jirka . vejrazka]

Hi there,

  I'm sorry I don't have a solution for you. However I have a 
warning/recommendation.

  Even if you don't serve the full site over https, you should make sure that 
forms that submit data over HTTPS are served over HTTPS. Otherwise you make it 
difficult for users to verify that their data (credentials etc.) will be 
submitted over a secure channel (and to verify certs prior to submitting form 
data etc.)

  On the plus side, if you serve forms over HTTPS (not only submit responses), 
it'll automatically solve your CSRF token problem.

  HTH

Jirka
-Original Message-
From: Kevin 
Sender: django-users@googlegroups.com
Date: Wed, 31 Oct 2012 01:21:33 
To: 
Reply-To: django-users@googlegroups.com
Subject: Posting from HTTP to HTTPS on same domain results in CSRF failure

Hello everyone,

  I am in the process of deploying a Django app which works both on HTTP 
and HTTPS connections, and require that some specific forms only submit via 
HTTPS.  I want the transition process over to HTTPS to be seamless for the 
end-user.  I am implementing this on a site-wide login form.

  Are there any workarounds for this or any middleware I can create to 
allow same domain HTTP to HTTPS transition without worrying about CSRF 
tokens being declined?  To ensure it wasn't a stale cookie issue, I just 
cleared my cookies before posting this.

  The csrf cookie is allowed for any connection, according to Firefox's 
cookie viewer, so shouldn't this mean that the cookie will be accepted over 
HTTPS?

Thanks in advance.

Django version is 1.4 branch.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/AR9a9jddb_QJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Django/South/MySQL bug

[Tom Evans]

Hi all

I've just run into a slight problem with Django 1.4.1, south 0.7.6 and
py-MySQLdb 1.2.3.

In the fix for Django bug #14091, Django will now always look at
cursor._last_executed in order to get details of the last query
executed, which I guess is for managing connection.queries in debug
mode. However, it does not check for existence of this attribute,
which will only exist if you have already executed a query from my
reading of py-MySQLdb.

cursor._last_executed is an undocumented 'private' part of py-MySQLdb.

For some reason, trying to issue a raw DB query in a south migration
causes Django to die looking at that attribute. Either using south's
"db.execute", or using "from django.db import connection;
c=connection.cursor(); c.execute(..)" as described in the Django
manual results in the same back trace.

This issue only came about because I needed to do a south data
migration that could not efficiently be handled in the ORM. Using the
ORM - either Django's or South's - in the migration works fine. I also
tried issueing a query through the ORM first to attempt to cause the
attribute to be set, but this also fails.

The migration is straightforward, it is adding a hash algorithm so
that we can move back closer to Django's stock auth stack:

def forwards(self, orm):
from django.db import connection
c = connection.cursor()
c.execute(
"""
UPDATE auth_user SET password = 'customsha512$' + password
WHERE password != '!' AND password != '' AND password not like '%$%'
""")

The traceback looks like this:

Traceback (most recent call last):
  File "manage.py", line 9, in 
execute_from_command_line(sys.argv)
  File "lib/django/core/management/__init__.py", line 443, in
execute_from_command_line
utility.execute()
  File "lib/django/core/management/__init__.py", line 382, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
  File "lib/django/core/management/base.py", line 196, in run_from_argv
self.execute(*args, **options.__dict__)
  File "lib/django/core/management/base.py", line 232, in execute
output = self.handle(*args, **options)
  File "lib/south/management/commands/migrate.py", line 108, in handle
ignore_ghosts = ignore_ghosts,
  File "lib/south/migration/__init__.py", line 213, in migrate_app
success = migrator.migrate_many(target, workplan, database)
  File "lib/south/migration/migrators.py", line 235, in migrate_many
result = migrator.__class__.migrate_many(migrator, target,
migrations, database)
  File "lib/south/migration/migrators.py", line 310, in migrate_many
result = self.migrate(migration, database)
  File "lib/south/migration/migrators.py", line 133, in migrate
result = self.run(migration)
  File "lib/south/migration/migrators.py", line 107, in run
return self.run_migration(migration)
  File "lib/south/migration/migrators.py", line 81, in run_migration
migration_function()
  File "lib/south/migration/migrators.py", line 57, in 
return (lambda: direction(orm))
  File "project/idp/migrations/0049_add_mintel_pw_algo.py", line 17, in forwards
""")
  File "lib/south/db/generic.py", line 273, in execute
cursor.execute(sql, params)
  File "lib/django/db/backends/util.py", line 44, in execute
sql = self.db.ops.last_executed_query(self.cursor, sql, params)
  File "lib/django/db/backends/mysql/base.py", line 237, in last_executed_query
return cursor._last_executed
  File "lib/django/db/backends/mysql/base.py", line 144, in __getattr__
return getattr(self.cursor, attr)
AttributeError: 'Cursor' object has no attribute '_last_executed'

If I attempt to do the same operation from the shell, it works
correctly. Therefore, I think there must be something specific to
South that is happening. Any tips or hints would be greatly
appreciated!

Cheers

Tom

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Django/South/MySQL bug

[Andrew Godwin]

Hmm, I'm not sure why issuing a query previously isn't fixing it - South
just uses the same database cursors that the rest of Django uses, it's one
of the few things we don't mess around with.

Surely Django has to have some code to deal with the case when there isn't
that attribute already? Have you tried working out why that's not happening?

Andrew

On Wed, Oct 31, 2012 at 2:19 PM, Tom Evans  wrote:

> Hi all
>
> I've just run into a slight problem with Django 1.4.1, south 0.7.6 and
> py-MySQLdb 1.2.3.
>
> In the fix for Django bug #14091, Django will now always look at
> cursor._last_executed in order to get details of the last query
> executed, which I guess is for managing connection.queries in debug
> mode. However, it does not check for existence of this attribute,
> which will only exist if you have already executed a query from my
> reading of py-MySQLdb.
>
> cursor._last_executed is an undocumented 'private' part of py-MySQLdb.
>
> For some reason, trying to issue a raw DB query in a south migration
> causes Django to die looking at that attribute. Either using south's
> "db.execute", or using "from django.db import connection;
> c=connection.cursor(); c.execute(..)" as described in the Django
> manual results in the same back trace.
>
> This issue only came about because I needed to do a south data
> migration that could not efficiently be handled in the ORM. Using the
> ORM - either Django's or South's - in the migration works fine. I also
> tried issueing a query through the ORM first to attempt to cause the
> attribute to be set, but this also fails.
>
> The migration is straightforward, it is adding a hash algorithm so
> that we can move back closer to Django's stock auth stack:
>
> def forwards(self, orm):
> from django.db import connection
> c = connection.cursor()
> c.execute(
> """
> UPDATE auth_user SET password = 'customsha512$' + password
> WHERE password != '!' AND password != '' AND password not like
> '%$%'
> """)
>
> The traceback looks like this:
>
> Traceback (most recent call last):
>   File "manage.py", line 9, in 
> execute_from_command_line(sys.argv)
>   File "lib/django/core/management/__init__.py", line 443, in
> execute_from_command_line
> utility.execute()
>   File "lib/django/core/management/__init__.py", line 382, in execute
> self.fetch_command(subcommand).run_from_argv(self.argv)
>   File "lib/django/core/management/base.py", line 196, in run_from_argv
> self.execute(*args, **options.__dict__)
>   File "lib/django/core/management/base.py", line 232, in execute
> output = self.handle(*args, **options)
>   File "lib/south/management/commands/migrate.py", line 108, in handle
> ignore_ghosts = ignore_ghosts,
>   File "lib/south/migration/__init__.py", line 213, in migrate_app
> success = migrator.migrate_many(target, workplan, database)
>   File "lib/south/migration/migrators.py", line 235, in migrate_many
> result = migrator.__class__.migrate_many(migrator, target,
> migrations, database)
>   File "lib/south/migration/migrators.py", line 310, in migrate_many
> result = self.migrate(migration, database)
>   File "lib/south/migration/migrators.py", line 133, in migrate
> result = self.run(migration)
>   File "lib/south/migration/migrators.py", line 107, in run
> return self.run_migration(migration)
>   File "lib/south/migration/migrators.py", line 81, in run_migration
> migration_function()
>   File "lib/south/migration/migrators.py", line 57, in 
> return (lambda: direction(orm))
>   File "project/idp/migrations/0049_add_mintel_pw_algo.py", line 17, in
> forwards
> """)
>   File "lib/south/db/generic.py", line 273, in execute
> cursor.execute(sql, params)
>   File "lib/django/db/backends/util.py", line 44, in execute
> sql = self.db.ops.last_executed_query(self.cursor, sql, params)
>   File "lib/django/db/backends/mysql/base.py", line 237, in
> last_executed_query
> return cursor._last_executed
>   File "lib/django/db/backends/mysql/base.py", line 144, in __getattr__
> return getattr(self.cursor, attr)
> AttributeError: 'Cursor' object has no attribute '_last_executed'
>
> If I attempt to do the same operation from the shell, it works
> correctly. Therefore, I think there must be something specific to
> South that is happening. Any tips or hints would be greatly
> appreciated!
>
> Cheers
>
> Tom
>
> --
> You received this message because you are subscribed to the Google Groups
> "South Users" group.
> To post to this group, send email to south-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> south-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/south-users?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send e

Re: Django/South/MySQL bug

[Tom Evans]

PEBKAC. The query has unescaped '%' symbols in it, which causes the
query to fail. This is not reported, and instead it dies trying to log
the query in connection.queries. I'm sorry to waste your time, should
have single-stepped it before emailing in.

I was clearly using a different query to test at the command line last night.

One curious thing is that the exception seems to be swallowed in
South, but reported from the command line.

Cheers

Tom

On Wed, Oct 31, 2012 at 2:25 PM, Andrew Godwin  wrote:
> Hmm, I'm not sure why issuing a query previously isn't fixing it - South
> just uses the same database cursors that the rest of Django uses, it's one
> of the few things we don't mess around with.
>
> Surely Django has to have some code to deal with the case when there isn't
> that attribute already? Have you tried working out why that's not happening?
>
> Andrew
>
> On Wed, Oct 31, 2012 at 2:19 PM, Tom Evans  wrote:
>>
>> Hi all
>>
>> I've just run into a slight problem with Django 1.4.1, south 0.7.6 and
>> py-MySQLdb 1.2.3.
>>
>> In the fix for Django bug #14091, Django will now always look at
>> cursor._last_executed in order to get details of the last query
>> executed, which I guess is for managing connection.queries in debug
>> mode. However, it does not check for existence of this attribute,
>> which will only exist if you have already executed a query from my
>> reading of py-MySQLdb.
>>
>> cursor._last_executed is an undocumented 'private' part of py-MySQLdb.
>>
>> For some reason, trying to issue a raw DB query in a south migration
>> causes Django to die looking at that attribute. Either using south's
>> "db.execute", or using "from django.db import connection;
>> c=connection.cursor(); c.execute(..)" as described in the Django
>> manual results in the same back trace.
>>
>> This issue only came about because I needed to do a south data
>> migration that could not efficiently be handled in the ORM. Using the
>> ORM - either Django's or South's - in the migration works fine. I also
>> tried issueing a query through the ORM first to attempt to cause the
>> attribute to be set, but this also fails.
>>
>> The migration is straightforward, it is adding a hash algorithm so
>> that we can move back closer to Django's stock auth stack:
>>
>> def forwards(self, orm):
>> from django.db import connection
>> c = connection.cursor()
>> c.execute(
>> """
>> UPDATE auth_user SET password = 'customsha512$' + password
>> WHERE password != '!' AND password != '' AND password not like
>> '%$%'
>> """)
>>
>> The traceback looks like this:
>>
>> Traceback (most recent call last):
>>   File "manage.py", line 9, in 
>> execute_from_command_line(sys.argv)
>>   File "lib/django/core/management/__init__.py", line 443, in
>> execute_from_command_line
>> utility.execute()
>>   File "lib/django/core/management/__init__.py", line 382, in execute
>> self.fetch_command(subcommand).run_from_argv(self.argv)
>>   File "lib/django/core/management/base.py", line 196, in run_from_argv
>> self.execute(*args, **options.__dict__)
>>   File "lib/django/core/management/base.py", line 232, in execute
>> output = self.handle(*args, **options)
>>   File "lib/south/management/commands/migrate.py", line 108, in handle
>> ignore_ghosts = ignore_ghosts,
>>   File "lib/south/migration/__init__.py", line 213, in migrate_app
>> success = migrator.migrate_many(target, workplan, database)
>>   File "lib/south/migration/migrators.py", line 235, in migrate_many
>> result = migrator.__class__.migrate_many(migrator, target,
>> migrations, database)
>>   File "lib/south/migration/migrators.py", line 310, in migrate_many
>> result = self.migrate(migration, database)
>>   File "lib/south/migration/migrators.py", line 133, in migrate
>> result = self.run(migration)
>>   File "lib/south/migration/migrators.py", line 107, in run
>> return self.run_migration(migration)
>>   File "lib/south/migration/migrators.py", line 81, in run_migration
>> migration_function()
>>   File "lib/south/migration/migrators.py", line 57, in 
>> return (lambda: direction(orm))
>>   File "project/idp/migrations/0049_add_mintel_pw_algo.py", line 17, in
>> forwards
>> """)
>>   File "lib/south/db/generic.py", line 273, in execute
>> cursor.execute(sql, params)
>>   File "lib/django/db/backends/util.py", line 44, in execute
>> sql = self.db.ops.last_executed_query(self.cursor, sql, params)
>>   File "lib/django/db/backends/mysql/base.py", line 237, in
>> last_executed_query
>> return cursor._last_executed
>>   File "lib/django/db/backends/mysql/base.py", line 144, in __getattr__
>> return getattr(self.cursor, attr)
>> AttributeError: 'Cursor' object has no attribute '_last_executed'
>>
>> If I attempt to do the same operation from the shell, it works
>> correctly. Therefore, I think there must be something specific to
>> South that is happening. Any tips or hints would b

Re: Posting from HTTP to HTTPS on same domain results in CSRF failure

[kahara]

Perhaps this could be fixed by simply redirecting all HTTP requests to 
HTTPS? Also, if you're using Analytics and your visitor comes in from an 
encrypted (Google) search page, then your Analytics will fail as the 
referer header will not contain search terms if the search hit is non-HTTPS.


Joni


keskiviikko, 31. lokakuuta 2012 15.41.11 UTC+2 Kevin kirjoitti:
>
> I did this approach before and it seems to break Google Search results. 
> :(  I do want users to use the site and find me easily after all.
> On Oct 31, 2012 6:24 AM, "Mike Dewhirst" > 
> wrote:
>
>> On 31/10/2012 7:21pm, Kevin wrote:
>>
>>> Hello everyone,
>>>
>>>I am in the process of deploying a Django app which works both on
>>> HTTP and HTTPS connections, and require that some specific forms only
>>> submit via HTTPS.  I want the transition process over to HTTPS to be
>>> seamless for the end-user.  I am implementing this on a site-wide login
>>> form.
>>>
>>>Are there any workarounds for this or any middleware I can create to
>>> allow same domain HTTP to HTTPS transition without worrying about CSRF
>>> tokens being declined?  To ensure it wasn't a stale cookie issue, I just
>>> cleared my cookies before posting this.
>>>
>>>The csrf cookie is allowed for any connection, according to Firefox's
>>> cookie viewer, so shouldn't this mean that the cookie will be accepted
>>> over HTTPS?
>>>
>>
>> Is there any reason you can't make the entire site https?
>>
>> Ought to solve the problem. And my understanding is that https everywhere 
>> is a reasonable approach nowadays.
>>
>>
>>  
>>> Thanks in advance.
>>>
>>> Django version is 1.4 branch.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django users" group.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/**msg/django-users/-/AR9a9jddb_**QJ
>>> .
>>> To post to this group, send email to django...@googlegroups.com
>>> .
>>> To unsubscribe from this group, send email to
>>> django-users...@**googlegroups.com .
>>> For more options, visit this group at
>>> http://groups.google.com/**group/django-users?hl=en
>>> .
>>>
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django users" group.
>> To post to this group, send email to django...@googlegroups.com
>> .
>> To unsubscribe from this group, send email to django-users...@**
>> googlegroups.com .
>> For more options, visit this group at http://groups.google.com/**
>> group/django-users?hl=en
>> .
>>
>>  

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/Omd3okIZKIwJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Posting from HTTP to HTTPS on same domain results in CSRF failure

[Kevin Veroneau]

I am using analytics.  Hmm.  I hoped that there was a django setting I may
have missed somewhere.  I'll tackle it in a few hours and post my findings
and/or solution to help others with a similar issue.  If there are any
other suggestions as well I'm open to more ideas.
On Oct 31, 2012 10:08 AM, "kahara"  wrote:

> Perhaps this could be fixed by simply redirecting all HTTP requests to
> HTTPS? Also, if you're using Analytics and your visitor comes in from an
> encrypted (Google) search page, then your Analytics will fail as the
> referer header will not contain search terms if the search hit is non-HTTPS.
>
>
> Joni
>
>
> keskiviikko, 31. lokakuuta 2012 15.41.11 UTC+2 Kevin kirjoitti:
>>
>> I did this approach before and it seems to break Google Search results.
>> :(  I do want users to use the site and find me easily after all.
>> On Oct 31, 2012 6:24 AM, "Mike Dewhirst"  wrote:
>>
>>> On 31/10/2012 7:21pm, Kevin wrote:
>>>
 Hello everyone,

I am in the process of deploying a Django app which works both on
 HTTP and HTTPS connections, and require that some specific forms only
 submit via HTTPS.  I want the transition process over to HTTPS to be
 seamless for the end-user.  I am implementing this on a site-wide login
 form.

Are there any workarounds for this or any middleware I can create to
 allow same domain HTTP to HTTPS transition without worrying about CSRF
 tokens being declined?  To ensure it wasn't a stale cookie issue, I just
 cleared my cookies before posting this.

The csrf cookie is allowed for any connection, according to Firefox's
 cookie viewer, so shouldn't this mean that the cookie will be accepted
 over HTTPS?

>>>
>>> Is there any reason you can't make the entire site https?
>>>
>>> Ought to solve the problem. And my understanding is that https
>>> everywhere is a reasonable approach nowadays.
>>>
>>>
>>>
 Thanks in advance.

 Django version is 1.4 branch.

 --
 You received this message because you are subscribed to the Google
 Groups "Django users" group.
 To view this discussion on the web visit
 https://groups.google.com/d/**ms**g/django-users/-/AR9a9jddb_**QJ
 .
 To post to this group, send email to django...@googlegroups.com.
 To unsubscribe from this group, send email to
 django-users...@**googl**egroups.com.
 For more options, visit this group at
 http://groups.google.com/**group**/django-users?hl=en
 .

>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django users" group.
>>> To post to this group, send email to django...@googlegroups.com.
>>> To unsubscribe from this group, send email to django-users...@**googl**
>>> egroups.com.
>>> For more options, visit this group at http://groups.google.com/**group**
>>> /django-users?hl=en .
>>>
>>>   --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-users/-/Omd3okIZKIwJ.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: getting data from a dictionary in a view

[MikeKJ]

On Wednesday, October 31, 2012 1:54:07 PM UTC, MikeKJ wrote:
>
>
> Solved using 
> http://www.daniweb.com/software-development/python/code/217019/search-a-python-dictionary-both-waysby
>  Ene 
> Uran , thanks
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/2TsYnRXLNBMJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Posting from HTTP to HTTPS on same domain results in CSRF failure

[David Fischer]

Django does strict referrer checking[1] which includes checking the scheme 
(HTTP vs. HTTPS). Like the others, I suggest you serve the whole site over 
HTTPS and forward HTTP traffic to the appropriate HTTPS URLs.

-David


[1] https://docs.djangoproject.com/en/1.4/ref/contrib/csrf/#how-it-works
[1] 
https://github.com/django/django/blob/master/django/middleware/csrf.py#L147

On Wednesday, October 31, 2012 9:36:42 AM UTC-7, Kevin wrote:
>
> I am using analytics.  Hmm.  I hoped that there was a django setting I may 
> have missed somewhere.  I'll tackle it in a few hours and post my findings 
> and/or solution to help others with a similar issue.  If there are any 
> other suggestions as well I'm open to more ideas.
> On Oct 31, 2012 10:08 AM, "kahara" > 
> wrote:
>
>> Perhaps this could be fixed by simply redirecting all HTTP requests to 
>> HTTPS? Also, if you're using Analytics and your visitor comes in from an 
>> encrypted (Google) search page, then your Analytics will fail as the 
>> referer header will not contain search terms if the search hit is non-HTTPS.
>>
>>
>> Joni
>>
>>
>> keskiviikko, 31. lokakuuta 2012 15.41.11 UTC+2 Kevin kirjoitti:
>>>
>>> I did this approach before and it seems to break Google Search results. 
>>> :(  I do want users to use the site and find me easily after all.
>>> On Oct 31, 2012 6:24 AM, "Mike Dewhirst"  wrote:
>>>
 On 31/10/2012 7:21pm, Kevin wrote:

> Hello everyone,
>
>I am in the process of deploying a Django app which works both on
> HTTP and HTTPS connections, and require that some specific forms only
> submit via HTTPS.  I want the transition process over to HTTPS to be
> seamless for the end-user.  I am implementing this on a site-wide login
> form.
>
>Are there any workarounds for this or any middleware I can create to
> allow same domain HTTP to HTTPS transition without worrying about CSRF
> tokens being declined?  To ensure it wasn't a stale cookie issue, I 
> just
> cleared my cookies before posting this.
>
>The csrf cookie is allowed for any connection, according to 
> Firefox's
> cookie viewer, so shouldn't this mean that the cookie will be accepted
> over HTTPS?
>

 Is there any reason you can't make the entire site https?

 Ought to solve the problem. And my understanding is that https 
 everywhere is a reasonable approach nowadays.


  
> Thanks in advance.
>
> Django version is 1.4 branch.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Django users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/**ms**g/django-users/-/AR9a9jddb_**QJ
> .
> To post to this group, send email to django...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users...@**googl**egroups.com.
> For more options, visit this group at
> http://groups.google.com/**group**/django-users?hl=en
> .
>

 -- 
 You received this message because you are subscribed to the Google 
 Groups "Django users" group.
 To post to this group, send email to django...@googlegroups.com.
 To unsubscribe from this group, send email to django-users...@**googl**
 egroups.com.
 For more options, visit this group at http://groups.google.com/**group*
 */django-users?hl=en
 .

   -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django users" group.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msg/django-users/-/Omd3okIZKIwJ.
>> To post to this group, send email to django...@googlegroups.com
>> .
>> To unsubscribe from this group, send email to 
>> django-users...@googlegroups.com .
>> For more options, visit this group at 
>> http://groups.google.com/group/django-users?hl=en.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/ROfYF78ljy0J.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

models.DecimalField with value 0 shows up as "0E-8" in admin forms by default. Is there a workaround?

[Ben Roberts]

I created a ticket  for 
this, since it really doesn't seem right for a Decimal field to be using E 
notation in forms, but just for zeros.

We use django admin as a client-facing backend, so we need to make it user 
friendly. I have a model with a bunch of DecimalFields representing 
nutritional data.

The fields all look like this:

g_carbs = DecimalField(max_digits=13, decimal_places = 8, null=True, 
blank=True) 

If the field is left blank, or if a non-zero value is provided, the admin 
form looks and works great. For example, for a non-blank, non-zero value 
like 10.5, it displays something like 10.5000, which is fine.

The problem is that for any 0 values, the form field displays 0E-8 which, 
although technically correct, is not going to cut it for clients, who are 
not scientists or engineers for the most part and are unfamiliar with E 
notation. We're using DecimalFields rather than FloatFields to avoid this 
type of notation.

I am not using a custom ModelForm or any custom admin tricks. Its just what 
gets auto-rendered by django admin for that model. 

I'm wondering if there is a work-around to this problem in the mean time.  

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/GuBCaLDAE4MJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Help me choose OS for django server

[Chris Pagnutti]

Hi Waitman,

Do you mean that if I stream mp4 videos from my site, I have to pay someone 
royalties?  

On Tuesday, October 30, 2012 3:50:30 PM UTC-4, Chris Pagnutti wrote:
>
> Hi.  I want to set up a production server for a django application.  
> constant.com offers Virtual Private Servers which should give me 
> virtually full control over the server, allowing me to install django and 
> all the stuff I need for my app to run properly.
>
> First, is this a good idea?  Do you think I can do this securely using the 
> django, apache, and lighttpd docs? or am I asking for trouble?  What are 
> the major security issues I need to be aware of when administering a server?
>
> Also, if I go this route, I'll need to choose an OS.  I'm running a 
> production server (just Apache + mod_wsgi) using my Arch Linux box, but I 
> don't think arch is the best idea.  I'm sorta trying to decide between 
> CentOS and Ubuntu.  Leaning toward CentOS, but just a little worried it 
> might be missing some of the packages I need.  I've never used CentOS 
> before.  Any advice?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/3WNpBYOLb-8J.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Help me choose OS for django server

[Javier Guerra Giraldez]

On Wed, Oct 31, 2012 at 2:17 PM, Chris Pagnutti
 wrote:
> Hi Waitman,
>
> Do you mean that if I stream mp4 videos from my site, I have to pay someone
> royalties?

maybe, maybe not.   the point is that H.264 is not free, not gratis,
not open.  but there's a "free of charge" use-case as a gift from
MPEG-LA to most harmless users... check first with a lawyer, as it's
far from obvious and could get you in deep troubles

-- 
Javier

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Problem with formset

[Lachlan Musicman]

On Thu, Nov 1, 2012 at 7:30 AM, Satinderpal Singh
 wrote:
> I use formset in my views.py file for the forms. It saves the entries from
> the form to the database but the problem is that it shows all the previous
> forms along with the new form for the new entry. The code for my views file
> is given below:
>
> def chemical_analysis(request):
> ChemicalFormSet = modelformset_factory(chem_analysis)
> if request.method=='POST':
> formset = ChemicalFormSet(request.POST, request.FILES)
> if formset.is_valid():
> cd = formset.cleaned_data
> formset.save()

Should that be cd.save()? Where else is cd used?


> return HttpResponseRedirect(reverse('Automation.report.views.result_chem'))
> else:
> return HttpResponse("There was an error with your submission. Please
> try again.")
> else:
> formset = ChemicalFormSet()
> return render_to_response('report/report_add_row.html', {'formset':
> formset}, context_instance=RequestContext(request))
>
> Any help will be appreciated.
>
> --
> Satinderpal Singh
> http://satindergoraya.blogspot.in/
> http://satindergoraya91.blogspot.in/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.



-- 
...we look at the present day through a rear-view mirror. This is
something Marshall McLuhan said back in the Sixties, when the world
was in the grip of authentic-seeming future narratives. He said, “We
look at the present through a rear-view mirror. We march backwards
into the future.”

http://www.warrenellis.com/?p=14314

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Help me choose OS for django server

[Christophe Pettus]

On Oct 31, 2012, at 12:41 PM, Javier Guerra Giraldez wrote:

> maybe, maybe not.   the point is that H.264 is not free, not gratis,
> not open.

If you are streaming H.264-encoded video free to end users, you don't have to 
pay fees, and will never have to:


http://www.mpegla.com/Lists/MPEG%20LA%20News%20List/Attachments/231/n-10-08-26.pdf

If you are changing end users, there are potentially fees, but they are quite 
modest:

http://www.mpegla.com/main/programs/AVC/Documents/AVC_TermsSummary.pdf
--
-- Christophe Pettus
   x...@thebuild.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Easy way to make all form fields read only?

[Paul]

I used to invest something similar; i wanted to to built a read view next 
to an update view that looks identical except for that read is obviously 
read-only. I used crispy-forms to do just that; recently an UneditableField 
(Layout) was added next to Field.
You do however either need to enumerate the model fields in a layout
Paul Bormans

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/5av7W0YQoS8J.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Easy way to make all form fields read only?

[Elena Williams]

I was also going to suggest using crispy forms -- having used it on a
recent project I'd strongly recommend it (it's great when it's plugged in
to  existing stylings such as: uni-form or bootstrap).

I've used it with ModelForm using Layout() and Field() and it works a treat.

---
Elena :)
@elequ
04022 90172



On Thu, Nov 1, 2012 at 7:29 AM, Paul  wrote:

> I used to invest something similar; i wanted to to built a read view next
> to an update view that looks identical except for that read is obviously
> read-only. I used crispy-forms to do just that; recently an UneditableField
> (Layout) was added next to Field.
> You do however either need to enumerate the model fields in a layout
> Paul Bormans
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-users/-/5av7W0YQoS8J.
>
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.