{% with %} tag
For a while I've been thinking that it would be nice to have a tag so you could re-use an expression in a template. I did one up and put it on http://www.djangosnippets.org/snippets/132/ Is this useful enough for core? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Add a salt to the newforms fields names
On Mar 23, 10:46 pm, "Amit Upadhyay" <[EMAIL PROTECTED]> wrote:
> But the original poster gave me this idea: would it be useful to have a
> field which specifically disallows auto-complete. May be an optional
> argument for CharField? [HTML allows to do a autocomplete=off in input
> fields].
You can do this already:
name = CharField(widget=TextInput(attrs={'autocomplete': 'off}))
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Add a salt to the newforms fields names
On Mar 24, 7:37 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > Just an idea, but maybe someone could make a new field class that > encapsulates a hidden HTML input element (hidden by style) that has no > label, and the developer can name it something conspicuous (like > `email`). The end result of this field could be that if any content > gets put into it, the form raises a ValidationError during cleaning. > Since the field is hidden by css (set display: hidden), no legit users > will see it. Ok, here you go: http://www.djangosnippets.org/snippets/131/ --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Pluggable urlresolving
At the moment BaseHandler is tied to RegexURLResolver. This makes it impossible to change the urlresolver in a convenient way. (For the mod_python handler it's easy, just extend the mod_python handler, but for the development server you cannot change the handler) Thus django core code must be altered (be it only in a marginal way) in order to use a custom resolver. My proposal is to introduce another setup setting, URL_RESOLVERS. And allow for multiple resolvers to be defined here, so that third party apps using the default resolver will still work even when using a custom urlresolver. (Assuming, of course, that django resolver is not removed from the settings). The custom resolvers must use the same interface as the RegexResolver does, thus throw the same errors and return the same stuff). One issue is that the default django resolver needs be initiated. Perhaps a custom urlresolver must be too.. The make this possible i added the method create_resolver to the urlresolvers module. It returns the regexresolver, and replaces the initiation currently done in BaseHandler. (It's the same code, just in a different location) To make things work i removed the default resolver from get_response in BaseHandler and replaced it with: [nothing changed] # Try all resolvers... # The first one is the preferred one, but if it fails, give the subsequent ones a try # Yet, if all routes fail, return the first exception.. failed_resolve = True failed_resolve_exception = False for rslv in settings.URL_RESOLVERS: try: resolver = __import__(rslv , globals(), locals(), ["create_resolver"]).create_resolver(request) callback, callback_args, callback_kwargs = resolver.resolve(request.path) except exceptions.PermissionDenied, e: # Once forbidden stays forbidden # I'm not sure whether this is always the most suitable solution, after all # in a differnt url setup an url could point to an entirely different resource # but i'm affraid to intruduce a potential security risk when there is a rather # naive urlsetup. failed_resolve_exception = e break except Exception, e: failed_resolve_exception = failed_resolve_exception or e else: failed_resolve = False break try: if failed_resolve: raise failed_resolve_exception [nothing changed] Considering the reluctance in changing the whole urlresolving thingy, would such a patch be acceptable? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Mentors still needed for Google Summer of Cod
On Thursday 15 March 2007 13:53, Jannis Leidel wrote: > Hi list, > > After reading the list of mentoring organizations of Google's Summer > of Code 2007 [1] I'm quite confused aboout not finding Django on it. > Any ideas what went wrong? > > Best, > Jannis Leidel As far as I can see, Django is on the list now. Great news for me since I'm going to apply for a Django project. :-) I've started to write an application, and I would LOVE any feedback you can possibly give me. Please comment on both language and content. I have a feeling my wording isn't too good, since english isn't my native language. Here's the beginning of my application (plaintext and HTML format): http://mamich.eu/soc-application.txt http://mamich.eu/soc-application.html Please note that this is only a draft of the abstract. I'll complement it with a presentation of myself and a more detailed description of what I'm planning to do as soon as I can. I'm a bit concerned my undertaking is a bit too big for just three months of work. What do you think? /Christoffer Carlborg pgp1QVZR0Z7TH.pgp Description: PGP signature
Re: Add a salt to the newforms fields names
Just an idea, but maybe someone could make a new field class that encapsulates a hidden HTML input element (hidden by style) that has no label, and the developer can name it something conspicuous (like `email`). The end result of this field could be that if any content gets put into it, the form raises a ValidationError during cleaning. Since the field is hidden by css (set display: hidden), no legit users will see it. However, most bots are chintzy HTTP clients that don't understand JS or CSS. The bots will see these fields and fill them out, but users will not. It is a very effective spam prevention method, and by making a field to do this, it is very extensible and easy to understand. Creating a form wrapping class is a good idea, but it may prove difficult for new users, especially when a simple approach exists. On Mar 22, 5:06 pm, "Baptiste" <[EMAIL PROTECTED]> wrote: > Hello all, > > (Please apologize my bad English, don't mind about it and try to > understand... I'll do my best !) > > First, have a quick look on the spammer main method - I am talking > about bots, not human spammers that can't be filtered - : POST data > are sent to the server with classical names of fields, like "comment", > "website", "title", ... > One of the method to prevent or limit spam is to display altered field > names that the bots can't identify. > > I propose me to work on that... but first, I wanted to know if it was > an interesting feature, and if we could chose a protocol to make these > things work. So these are some ideas : > * The BaseForm constructor has a new parameter : "scramble". Set to > True (default False), the things could work like that : > in _html_output(), for each field, we generate a md5 hash of the name > +a secret+a date(no day, just week, month, year, because an user can > keep a page open a few days, not a week. that will prevent the > recording of the hash, if date is in it). We pass this string to each > BoundField, and all works like before. In the generated code, names > don't mean anything and cannot be used by spammers to identify fields. > * If the user gets back data returned by a scrambled form : he > instantiates a form with these data, the parameter scramble to True, > and the form will have a different behaviour. It will treat the data > by doing a loop on the dictionary, recreating the hash, and comparing > it with fields names to make a new dictionary with correct names and > values, what would allow the user to do again form['name']. > It may sound a little bit confuse - it is. So please tell me what you > think about that, and how you would do it. > > Regards > Baptiste. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
unicode issues in multiple tickets (#952, #1356, #3370) and thread about Euro sign in django-users
Hi,
I came across thoes tickets and the corresponding thread just yesterday and as
fas as I understood the main problem is that newforms ist talking unicode
internally and at the interface to the django-ORM.
I attached my solution to this problem for django.newforms.models (diffed
against latest SVN), which does an encoding to settings.DEFAULT_CHARSET onto
the save() between the newforms and django-ORMs.
This patch wouldn't be needed or could be removed if django-ORM and/or
db-backends all talk unicode/utf-8.
Regards,
Dirk
--
"Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ...
Jetzt GMX ProMail testen: www.gmx.net/de/go/mailfooter/promail-out
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Index: models.py
===
--- models.py (Revision 4775)
+++ models.py (Arbeitskopie)
@@ -8,6 +8,7 @@
from forms import BaseForm, DeclarativeFieldsMetaclass, SortedDictFromList
from fields import Field, ChoiceField
from widgets import Select, SelectMultiple, MultipleHiddenInput
+from django.conf import settings
__all__ = ('save_instance', 'form_for_model', 'form_for_instance', 'form_for_fields',
'ModelChoiceField', 'ModelMultipleChoiceField')
@@ -38,7 +39,10 @@
for f in opts.fields:
if not f.editable or isinstance(f, models.AutoField):
continue
-setattr(instance, f.name, clean_data[f.name])
+try:
+ setattr(instance, f.name, clean_data[f.name].encode(settings.DEFAULT_CHARSET))
+except:
+ setattr(instance, f.name, clean_data[f.name])
if commit:
instance.save()
for f in opts.many_to_many:
Re: ORACLE - column at array pos 0 fetched with error: 1406
Hi Tristan,
Unfortunately, cx_Oracle - and therefore Django/Oracle - doesn't
support UTF-8 yet.
What works for setting your environment to Latin1/ISO8859 (with
os.environ['NLS_LANG'] = 'American_America.WE8ISO8859P1'). If you make
sure you're whole website uses ISO8859 then Oracle will translate it
correctly to whatever character set your database uses (probably
UTF-8).
It's far from ideal, but it works.
Ciao,
- Matthias
Tristan wrote:
> I am under 4697 of
> http://code.djangoproject.com/svn/django/branches/boulder-oracle-sprint/
> Before reporting this message as a ticked, I would like to be sure if
> it is my mistake or a bug exists.
> Into an x model, I defined next field:
>caracter = models.CharField('Campo Character',
> maxlength=10)
> When I attemp to enter next data to this field in the Admin I have
> next situations:
> áéíóú = No problem
> áéíóúa = System generates mentioned error (ORA 1406) but
> complete data is saved.
> áéíóaa = No problem
> á¿567890 = No problem
> 1234567890 = No problem.
> á¿5678901 = System generates mentioned error (ORA 1406) but
> complete data is saved. See related error for this data below.
> What I identified is that when using characters such as á, é, ¿, etc.
> system seems to use two (2) characters or positions. Although data was
> saved, I can not access to any record when browsing with Django. When
> inserting/changing using sqlplus command, I have no problems during
> commit and during query.
> My Oracle variable NLS_LANG=.UTF8 and use Windows XP2.
>
>
> Part of the data where error occurs is:
>
> # or checking the Model here, neither of which is
> good.
> elif isinstance(field, datetime.datetime) and \
> field.hour == field.minute == field.second ==
> field.microsecond == 0:
> yield field.date()
> else:
> yield field
> for unresolved_row in cursor:
> row = list(resolve_cols(unresolved_row))
> if fill_cache:
> obj, index_end = get_cached_row(self.model, row,
> 0)
> else:
> obj = self.model(*row[:index_end])
> for i, k in enumerate(extra_select):
> ▼ Local vars
> Variable Value
> cursor >
> extra_select []
> fill_cache False
> full_query 'SELECT "TESTDB_DBTEST"."ID", "TESTDB_DBTEST"."FECHA",
> "TESTDB_DBTEST"."CARACTER", "TESTDB_DBTEST"."TEXTO",
> "TESTDB_DBTEST"."MONTO"\n FROM "TESTDB_DBTEST" ORDER BY
> "TESTDB_DBTEST"."FECHA" ASC'
> get_cached_row
> index_end 5
> params []
> resolve_cols
> select ['"TESTDB_DBTEST"."ID"', '"TESTDB_DBTEST"."FECHA"',
> '"TESTDB_DBTEST"."CARACTER"', '"TESTDB_DBTEST"."TEXTO"',
> '"TESTDB_DBTEST"."MONTO"']
> self Error in formatting:column at array pos 0 fetched with error:
> 1406
> sql ' FROM "TESTDB_DBTEST" ORDER BY "TESTDB_DBTEST"."FECHA" ASC'
>
> Tristan.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: ORACLE - column at array pos 0 fetched with error: 1406
Hi Tristan,
Unfortunately, cx_Oracle - and therefore Django/Oracle - doesn't
support UTF-8 yet.
What works for setting your environment to Latin1/ISO8859 (with
os.environ['NLS_LANG'] = 'American_America.WE8ISO8859P1'). If you make
sure you're whole website uses ISO8859 then Oracle will translate it
correctly to whatever character set your database uses (probably
UTF-8).
It's far from ideal, but it works.
Ciao,
- Matthias
Tristan wrote:
> I am under 4697 of
> http://code.djangoproject.com/svn/django/branches/boulder-oracle-sprint/
> Before reporting this message as a ticked, I would like to be sure if
> it is my mistake or a bug exists.
> Into an x model, I defined next field:
>caracter = models.CharField('Campo Character',
> maxlength=10)
> When I attemp to enter next data to this field in the Admin I have
> next situations:
> áéíóú = No problem
> áéíóúa = System generates mentioned error (ORA 1406) but
> complete data is saved.
> áéíóaa = No problem
> á¿567890 = No problem
> 1234567890 = No problem.
> á¿5678901 = System generates mentioned error (ORA 1406) but
> complete data is saved. See related error for this data below.
> What I identified is that when using characters such as á, é, ¿, etc.
> system seems to use two (2) characters or positions. Although data was
> saved, I can not access to any record when browsing with Django. When
> inserting/changing using sqlplus command, I have no problems during
> commit and during query.
> My Oracle variable NLS_LANG=.UTF8 and use Windows XP2.
>
>
> Part of the data where error occurs is:
>
> # or checking the Model here, neither of which is
> good.
> elif isinstance(field, datetime.datetime) and \
> field.hour == field.minute == field.second ==
> field.microsecond == 0:
> yield field.date()
> else:
> yield field
> for unresolved_row in cursor:
> row = list(resolve_cols(unresolved_row))
> if fill_cache:
> obj, index_end = get_cached_row(self.model, row,
> 0)
> else:
> obj = self.model(*row[:index_end])
> for i, k in enumerate(extra_select):
> ▼ Local vars
> Variable Value
> cursor >
> extra_select []
> fill_cache False
> full_query 'SELECT "TESTDB_DBTEST"."ID", "TESTDB_DBTEST"."FECHA",
> "TESTDB_DBTEST"."CARACTER", "TESTDB_DBTEST"."TEXTO",
> "TESTDB_DBTEST"."MONTO"\n FROM "TESTDB_DBTEST" ORDER BY
> "TESTDB_DBTEST"."FECHA" ASC'
> get_cached_row
> index_end 5
> params []
> resolve_cols
> select ['"TESTDB_DBTEST"."ID"', '"TESTDB_DBTEST"."FECHA"',
> '"TESTDB_DBTEST"."CARACTER"', '"TESTDB_DBTEST"."TEXTO"',
> '"TESTDB_DBTEST"."MONTO"']
> self Error in formatting:column at array pos 0 fetched with error:
> 1406
> sql ' FROM "TESTDB_DBTEST" ORDER BY "TESTDB_DBTEST"."FECHA" ASC'
>
> Tristan.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Add a salt to the newforms fields names
On Mar 23, 8:08 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Fri, 2007-03-23 at 06:48 +, Baptiste wrote: > > That feature would be unable by default, and the user could use it > > just for forms which didn't need to be autocompleted, eg. a comment > > form (which can use cookies to remember the user, it is really more > > powerful). > > Autocomplete isn't just designed to work on a single site. One of the > benefits of using "name" as the name of an input field requiring your > name is so that a client's web browser will recognise it as a name field > and help you autocomplete any values you have entered into other name > fields, even on other sites. I appreciate it's not a "drop dead" > requirement, but it is very useful, given the number of forms we tend to > fill out using web applications. It is to the user to choose ;-) > > > For the form which need it, like search forms, just no > > parameter scramble, and all works like before. > > But -if I have understood what you meant- the spammers search the with > > the input name in the majority of the cases, and rarely with the label > > content... > > I've seen software designed to do automated form submissions -- during a > post-mortem audit of a compromised system -- and it read labels, id and > name attributes on field elements. Maybe the one you saw... but not all the bots ! For the id, it is already possible to manage that by using the 'auto_id' parameter which can be a random string... > > I think using things like a unique hash is more beneficial and user > friendly in the long run. I don't understand that, sorry. But okay, maybe that was a bad idea. Just a suggestion, heh ! > > Regards, > Malcolm Baptiste. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Add a salt to the newforms fields names
I tried hacking around with newforms, to implement part of my Stopping Spambots with Hashes and Honeypots (http://www.nedbatchelder.com/text/stopbots.html). My approach was to create a BotProofForm class which would wrap an instance of an ordinary form. This let me rename fields without changing the underlying implementation of BaseForm (or BoundField). I didn't get everything working, but I think the approach would work for hashing field names. More difficult was how to add honeypot fields, since hiding them requires changing the HTML representation of fields. --Ned. Baptiste wrote: > Hello all, > > (Please apologize my bad English, don't mind about it and try to > understand... I'll do my best !) > > First, have a quick look on the spammer main method - I am talking > about bots, not human spammers that can't be filtered - : POST data > are sent to the server with classical names of fields, like "comment", > "website", "title", ... > One of the method to prevent or limit spam is to display altered field > names that the bots can't identify. > > I propose me to work on that... but first, I wanted to know if it was > an interesting feature, and if we could chose a protocol to make these > things work. So these are some ideas : > * The BaseForm constructor has a new parameter : "scramble". Set to > True (default False), the things could work like that : > in _html_output(), for each field, we generate a md5 hash of the name > +a secret+a date(no day, just week, month, year, because an user can > keep a page open a few days, not a week. that will prevent the > recording of the hash, if date is in it). We pass this string to each > BoundField, and all works like before. In the generated code, names > don't mean anything and cannot be used by spammers to identify fields. > * If the user gets back data returned by a scrambled form : he > instantiates a form with these data, the parameter scramble to True, > and the form will have a different behaviour. It will treat the data > by doing a loop on the dictionary, recreating the hash, and comparing > it with fields names to make a new dictionary with correct names and > values, what would allow the user to do again form['name']. > It may sound a little bit confuse - it is. So please tell me what you > think about that, and how you would do it. > > Regards > Baptiste. > > > > > > > > -- Ned Batchelder, http://nedbatchelder.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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Add a salt to the newforms fields names
On 3/22/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > > On Fri, 2007-03-23 at 06:48 +, Baptiste wrote: > > That feature would be unable by default, and the user could use it > > just for forms which didn't need to be autocompleted, eg. a comment > > form (which can use cookies to remember the user, it is really more > > powerful). > > Autocomplete isn't just designed to work on a single site. One of the I am -1 on this too. But the original poster gave me this idea: would it be useful to have a field which specifically disallows auto-complete. May be an optional argument for CharField? [HTML allows to do a autocomplete=off in input fields]. -- Amit Upadhyay Blog: http://www.rootshell.be/~upadhyay +91-9820-295-512 --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Add a salt to the newforms fields names
On Fri, 2007-03-23 at 06:48 +, Baptiste wrote: > That feature would be unable by default, and the user could use it > just for forms which didn't need to be autocompleted, eg. a comment > form (which can use cookies to remember the user, it is really more > powerful). Autocomplete isn't just designed to work on a single site. One of the benefits of using "name" as the name of an input field requiring your name is so that a client's web browser will recognise it as a name field and help you autocomplete any values you have entered into other name fields, even on other sites. I appreciate it's not a "drop dead" requirement, but it is very useful, given the number of forms we tend to fill out using web applications. > For the form which need it, like search forms, just no > parameter scramble, and all works like before. > But -if I have understood what you meant- the spammers search the with > the input name in the majority of the cases, and rarely with the label > content... I've seen software designed to do automated form submissions -- during a post-mortem audit of a compromised system -- and it read labels, id and name attributes on field elements. I think using things like a unique hash is more beneficial and user friendly in the long run. Regards, Malcolm --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
