On 12/7/06, Honza Král <[EMAIL PROTECTED]> wrote:
> Hi, is anybody using MultipleChoiceField with any success?
> It didn't work for me, so I produced a patch (ticket 3114) to correct
> the behaviour.
>
> The ticket also includes some tests that fail when run against the
> current SVN version. Coul
On 12/12/06, Massimiliano Ravelli <[EMAIL PROTECTED]> wrote:
> I'm testing this patch in my real application with no problem.
> I'm using r4193 as with r4194 I found a strange problem with the new
> prefix parameter .
Which problem did you have with the prefix parameter? Was it just a
problem of
I was trying to implement custom filter for the first time and looked
to how to do that first to official documentation and it is clear with
exception of saying where actually put the code of the filter
(http://www.djangoproject.com/documentation/templates/#built-in-filter-reference).
I have trie
On 12/12/06, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> On 12/12/06, Rob Hudson <[EMAIL PROTECTED]> wrote:
> > Is there a way to make this happen *after* all the content was sent to
> > the user and the HTML tag closed?
>
> I don't think so, since the request/response cycle is how Django
> works, a
On 12/12/06, Rob Hudson <[EMAIL PROTECTED]> wrote:
>
> * Benjamin Slavin ([EMAIL PROTECTED]) wrote:
> > I think auto purge would need further discussion to figure out the
> > best solution.
Auto-purge should be optional, in any case. I like my session table
the way it is, thanks. :)
> Is there
* Benjamin Slavin ([EMAIL PROTECTED]) wrote:
> The get_new_session_key method would probably be a good place to
> start, though I have little familiarity with the interface to the
> session middleware. I'm swamped right now, so I'll look into it in
> the next few days. If you need any assistance
On 12/12/06, Rob Hudson <[EMAIL PROTECTED]> wrote:
> > I agree that this would be a valuable addition. Perhaps you could
> > submit a patch... if you're not comfortable doing that, perhaps
> > someone else will.
>
> I'd be happy to attempt it. In looking at the code it seems like you
> could cal
Benjamin Slavin wrote:
> Django does use an algorithm that generates difficult-to-guess session
> IDs; however, no current implementation of sessions (by anyone) is
> completely safe.
I've verified this, actually, with WebScarab, retrieving 1000
consecutive session ids and visualizing them on a p
Honza Král wrote:
> > Can we attach to the ticket the new patch naming it
> > "multiple_choice_4194.patch" ?
>
> done
Thanks Honza.
> I added this one as well, the patches aren't completely identical due
> to the auto_id parameter.
Ops ! I missed it.
I'm testing this patch in my real applicat
On 12/12/06, Massimiliano Ravelli <[EMAIL PROTECTED]> wrote:
>
> Honza Král wrote:
>
> > the old patches should still work with very little tweaking, but I am
> > attaching a new set (against 4194) just to be sure
>
> Thank you very much Honza !
>
> I had no problem at all with the old patch; I pro
Honza Král wrote:
> the old patches should still work with very little tweaking, but I am
> attaching a new set (against 4194) just to be sure
Thank you very much Honza !
I had no problem at all with the old patch; I proposed a new one only
to make the life of committers easier ;-)
Can we atta
Trac rejected me when I tried to overwrite the patches in the ticket,
so I hope you don't mind them here on the list.
On 12/12/06, Massimiliano Ravelli <[EMAIL PROTECTED]> wrote:
>
> I had some problem with MultipleChoiceField and request.POST
> (QueryDict).
>
> Your patch fixes this problem and p
I had some problem with MultipleChoiceField and request.POST
(QueryDict).
Your patch fixes this problem and passes the tests I attached to ticket
3129 too. (multiple_choice_tests.patch in
http://code.djangoproject.com/ticket/3129).
Adrian checked in a part of your patch (changeset 4185
http://c
graham_king wrote:
> If just one person could give it a test, I think there's a good case
> for integrating it into the trunk. It behaves like the previous version
> but runs faster and the sort works. Without this you can't actually use
> the filter interface on more than a few thousand entries.
On 12/12/06, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> With sparse session keys, the only reasonable attack I can see is MITM
> or replay. And no fingerprinting based on the request will help that,
> since all the headers are in the clear.
Yup. If you're really concerned about those types of att
It looks like these same articles have been checked against Django's
session code in this bug:
http://code.djangoproject.com/ticket/362
Cool. :)
-Rob
On 20061212.1819, Rob Hudson said ...
> Yeah, I kind of got off topic. My apologies. Maybe I should post the
> same message in a new thread...
Jeremy Dunck wrote:
> But I agree session hijacking is a concern, though totally unrelated
> to the discussion of whether to move messages to sessions. :)
Yeah, I kind of got off topic. My apologies. Maybe I should post the
same message in a new thread... I think session security is important
On 12/12/06, Benjamin Slavin <[EMAIL PROTECTED]> wrote:
> Sessions are based on data passed from the client to the server.
> Because this data can easily be forged, session impersonation is
> possible. That's where picking hard-to-guess identifiers comes in.
> If you have a secure random session
On 12/12/06, Rob Hudson <[EMAIL PROTECTED]> wrote:
>
> I remember reading many articles on PHP sessions and about session
> hijacking, etc. Has Django's sessions been looked at from this
> perspective or can Django's sessions have similar issues?
Django does use an algorithm that generates diffi
On 12/12/06, Rob Hudson <[EMAIL PROTECTED]> wrote:
> In one of those articles, he describes the "impersonation" scenario,
> which is what I wonder if Jeremy is referring to:
No, I was referring to the situation James outlined earlier.
But I agree session hijacking is a concern, though totally un
I agree that it's more intuitive to tie messages to sessions.
I remember reading many articles on PHP sessions and about session
hijacking, etc. Has Django's sessions been looked at from this
perspective or can Django's sessions have similar issues?
Some reference material by Chris Shifflett, o
+1 for moving messages to sessions as well
Regards,
Aidas Bendoraitis [aka Archatas]
On 12/12/06, Favo <[EMAIL PROTECTED]> wrote:
>
> We have a abstract for message, if anonymous, use add_session_message,
> if auth user, use add_auth_user_message.
>
> +1 if django move auth message to session.
We have a abstract for message, if anonymous, use add_session_message,
if auth user, use add_auth_user_message.
+1 if django move auth message to session.
The problem mentioned by James Bennett seems not a big issue.
--~--~-~--~~~---~--~~
You received this mess
On 12/12/06, graham_king <[EMAIL PROTECTED]> wrote:
>
> Has anyone else had a chance to test this new SelectBox.js ?
I've just started using it. We have about 15 people using admin most
of the day.
> I would
> really appreciate if someone could drop this js into their app and take
> a look - I
On Mon, 2006-12-11 at 19:16 +0100, Michael Radziej wrote:
> Now it's there! Thanks!
>
>
Now you see it. Now you don't!
The beauty of wiki magic :P
Alan Trick
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Dj
Has anyone else had a chance to test this new SelectBox.js ? I would
really appreciate if someone could drop this js into their app and take
a look - I guarantee you faster select boxes and faster page load times
on all your admin interface that uses the filter interface. We've had
it in producti
hi,
after i've read this blog post:
http://superjared.com/entry/urgent-upgrade-django-if-deployed-fastcgi/
i also became a little nervous because i also have a fastcgi-backed website.
but the problem is, i am unable to reproduce this problem.
actually i use a custom fastcgi script ( the fastc
27 matches
Mail list logo
