Hi,
about 4 months ago, I started this thread. I want to give some news on
django-formwizard to keep you all up2date.
Stephan Jäkel wrote:
The last not solved problem is handling file uploads.
This problem is solved. The formwizard supports file uploads in any step. I
solved the problem by
On Tue, 2010-09-07 at 03:31 +0100, Luke Plant wrote:
> 1) The attacker can have the same (public) IP address as the victim if
> they are both behind the same firewall, and this will in fact be one of
> the most practical ways to launch a MitM + CSRF attack on HTTPS.
Here and in my other message I
Luke,
Your last couple replies to this thread have been very helpful. Thank
you for cogently clarifying this situation and patiently keeping at
it.
-Paul
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to
On Mon, 2010-09-06 at 22:39 +0200, Patryk Zawadzki wrote:
> Another approach would be not to use a cookie at all. For each {%
> csrf_token %} use a slightly modified variant of the above
> encode_cookie function with:
>
> values = {
> 'host: request.META['HTTP_HOST'],
> 'scheme': request.
Hello there,
I'm watching #5833 and I have a bit of a problem with the
implementation. A good example of their proposal is here:
http://code.djangoproject.com/ticket/5833#comment:68
The API is remarkably similar to Gaynor's django-filters. My problem
with this is that your filtering essentially
On 07/09/10 14:05, Patryk Zawadzki wrote:
> Not deprecated in Django sense. I don't think it's going away any time
> soon. Just that it's been discouraged for a while at the
> psycopg/database level.
Well, maybe "discouraged" is fair, but it does exist and you have the
option (and if you use Tran
On 07/09/10 16:16, Robert Gravsjö wrote:
>> with db.isolation(ISOLATION_SERIALIZABLE):
>> # ...
>>
>
> You don't want to serialize access to the database in a multi-user
> application.
Just in case: serializable transaction != serializing access - among
serializable level transactions, the
Hi folks,
I am running into a validation problem with ModelForms - here is a quick
summary of what is happening
Take a simple model - here we call Model.full_clean as part of the custom save
method to enforce the validation:
from django.db import models
class Stuff(models.Model):
"""(Stuf
Patryk Zawadzki skrev 2010-09-07 16.47:
On Mon, Sep 6, 2010 at 7:12 PM, Patryk Zawadzki wrote:
It would be more useful if you could explicitly
enter_isolation_block() and leave_isolation_block() as needed
(currently there is no way to commit the isolating transaction other
than doing a raw SQ
On Mon, Sep 6, 2010 at 7:12 PM, Patryk Zawadzki wrote:
> It would be more useful if you could explicitly
> enter_isolation_block() and leave_isolation_block() as needed
> (currently there is no way to commit the isolating transaction other
> than doing a raw SQL query or accessing psycopg internal
On Tue, Sep 7, 2010 at 2:57 PM, David De La Harpe Golden
wrote:
> On 06/09/10 14:29, Patryk Zawadzki wrote:
>> The problem only exists when Django sets isolation level to 1, if you
>> use the deprecated "autocommit" setting, you will not be affected.
> Uh. Is this deprecated? At what layer? Since
On 06/09/10 14:29, Patryk Zawadzki wrote:
> The problem only exists when Django sets isolation level to 1, if you
> use the deprecated "autocommit" setting, you will not be affected.
>
Uh. Is this deprecated? At what layer? Since when? I've been using it*
happily for a while (modulo that one kn
On Tue, Sep 7, 2010 at 8:38 AM, Russell Keith-Magee
wrote:
> Firstly, I'm not wild about "secure=request.validated". This looks
> like a really simple way for people to say "secure=True" as a way of
> "fixing" CSRF support that they can't get to work. The choice of
> argument on the attribute isn'
13 matches
Mail list logo
