sk someone to raise the issue on
mailing list, a link to the google group page must always be given in
the same comment. It's reasonably easy and it's a lot more inviting to
give the link vs. "There's a mailing list out there somewhere, go and
find it, why don't you?"
On 05/13/2013 12:11 PM, Luke Sneeringer wrote:
> On May 13, 2013, at 10:06 AM, AK wrote:
>
>> WONTFIX does sound rude to me, as well. Perhaps 'onholdindefinite' can
>> be used instead, the effective meaning is the same, just the term itself
>> is more polit
uot;. Instead, anyone
needing it would think "If it is to be fixed, it's clear someone has
to make a case for it." -ak
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To unsubscribe from this group and stop receiving
7;).first('last_name') # first method
has order_by syntax.
So, what do you think?
Best regards,
Wim
How about first as a function? I think it's very often useful not just
for querysets but
for all kind of iterables:
def first(iterable, default=None):
try:
Malcolm, ofcourse I can rewrite it as a patch to current session
module but I think you should understand that anyone who will do svn
update would get broken session module because of extra field in
django_session table.
If it is ok, please answer and I will prepare patch in an hour
(without ip ch
Guys
The only thing I don't understand at the moment is: everyone
understands that current implementation of ORM together with current
implementation of sessions table doesn't allow to force insert and
throw exception if it fails. So I can state this as a special case.
Every framework has limitati
Ivan, although reseeding still not guarantees that there may be no
duplicates as INSERTing does, isn't it ?
And insert needs to be done only once at session start and is
performed ANYWAY at session start. The difference in my way is that
insert is done when new session is created and in django's w
Henrique Ser, you lost the fact that we are using lighttpd, not
apache, but our django works as preforked fastcgi.
I can only say that i will NEVER use a potentially vulnerable session
implementation where any not logged in user may get superuser's
permission, even if a chance for this to happen a
As I said, we restart our django fastcgi server a few times per a day.
I think it is more related to:
> Beginning with python2.4, the seed also uses os.urandom() when available, so
> it starts to get safer.
and our app runs under xen domU debian installation so may be there's
something related
Btw, we use Debian with python 2.4 too
--~--~-~--~~~---~--~~
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 grou
Michael, I really don't know how would it be possible, I only know the
following:
1. My production web server restarts a few times per day. Sometimes
twice (in a really short period ie 2-3 minutes)
2. I got a report from _new_ user that he received e-mail with login
and pass, clicked to link and b
Default django installation uses session lifetime equal to 2 weeks
with no session expiration at browser close. Just calculate what
should be a default strength of session id generator to successfully
generate unique IDs within 2 weeks for a web app with 1 000 000 unique
visitors per a day. As far
> so it doesn't get us any real improvement in security
James, there is a concept of 'fool proof'. Real hackers may do many
things. But current model allows even 10 year old kids to be hackers.
This is just against them. There is no ability to protect all sites
with ssl and I would not like a nei
> I'm still wary of this -- again, it doesn't do anything to prevent
> man-in-the-middle, and it introduces complexity and -- if we're
> worried about session collisions -- introduces a whole new class of
> bugs when you have a bunch of people behind a NAT or firewall who all,
> from the POV of yo
Even more on remote ip checking: it can be done in a flexible way when
user is able to set either don't ever use it, check remote ip, check
user agent name or ever both remote ip and user agent for paranoids :)
I think everyone understands that it's about 2-3 more lines of code.
--~--~-~
Guys I would like to explain some things and decisions in my code.
1. REMOTE_IP. I think it is a good idea to check it. Load balancers
acts as proxy servers. Every web server has a module that allow to
restore REMOTE_IP from X-FORWARDED-FOR, for example apache's module is
called mod_rpaf. And ofc
Bjorn, if you read my first messages and specially my patch #3370, you
find that I made a suggestion that if the guys want to move to unicode
they better drop all native encodings support and so does my patch.
Then people started to answer me that this is wrong. And at the moment
noone is able
After some thoughts I came to the following conclusion: if you guys
want to keep support of legacy charsets in fact you don't have to
force model objects too be unicoded. Firstly, they are passed to
templates and filters and we can't mix legacy charsets with unicode in
one template. Next, if I
> Do you know which parts of django still use bytecode strings?
As far as I know, it's only newforms and this is why the topic was
born: at the moment newforms work right until you want to put any non-
latin1 character through them to db. I've done the patch (#3370) which
fixes the issue but it
Michael, of you read again the topic about euro sign in newforms you
can find that this touches everything. Personally I couldn't find a way
to use utf-8 to connect MySQL and keep using cp1251 in my templates: it
basically doesn't work. With my patch (#3370) and utf8 everywhere it
does.
--~--~--
Guys
Could someone please explain me what was a problem with unicode support
in oldforms so newforms have been made with unicode inside ?
Kick me if I wrong but what is a real reason to convert bytes back and
forth ? Religion ? I agree with everyone who says that unicode is a
must and 'legacy' ch
Guys
The problem is simple but it was born a very long time ago.
For MySQL 4.1 and higher there is hardcoded in
django/db/backends/mysql/base.py:
cursor.execute("SET NAMES 'utf8'")
there were lots of tickets and messages in django-users complaining to
this but in fact they all were ignored.
Perso
Thanks, posted: http://code.djangoproject.com/ticket/1528
--~--~-~--~~~---~--~~
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 unsubsc
Hello guys
After playing with Django 0.91 I've found that it behaves not 100%
correct when MySQL 4.1 is used.
File django/core/db/backends/mysql.py contains code:
if self.connection.get_server_info() >= '4.1':
cursor.execute("SET NAMES utf8")
It means that unicode will be al
24 matches
Mail list logo
