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'
On Tue, Sep 7, 2010 at 8:29 AM, Thomas Guettler wrote:
> If you have a daemon that lives forever, I would do it like this (untested
> if this does not leave an idle transaction open):
> The place where the daemon hangs around if nothing can be done lives must
> not use the ORM. If there is somethi
On Tue, Sep 7, 2010 at 4:08 AM, Patryk Zawadzki wrote:
> Hi,
>
> Since CSRF is already being reafactored up-side down in the trunk, I
> thought it might be a good idea to propose a slight modification.
Erm... it is? That's news to me.
Django 1.2 introduced a bunch of very big changes, but those
Patryk Zawadzki wrote:
> On Mon, Sep 6, 2010 at 4:47 PM, Robert Gravsjö wrote:
>> Patryk Zawadzki skrev 2010-09-06 15.29:
>>> The isolating transaction keeps going on until you either (1) commit,
>>> (2) rollback or (3) disconnect. Django only commits/rollbacks the
>>> transactions it explicitly
On Sun, Sep 5, 2010 at 5:05 PM, VernonCole wrote:
> "Once we're at a Django 2.6 minimum supported version, using 2to3 to
> maintain
> parallel implementations becomes a lot easier."
>
> As much as I admire Russ, and I do, I don't think that the above
> statement is correct.
My apologies -- in the
On Mon, 2010-09-06 at 21:11 +0200, Patryk Zawadzki wrote:
> See above, I'm concerned about the case when the attacker is able to
> perform a replay attack. If you validate CSRF against the client's IP
> (and possibly against a TTL field¹), you effectively prevent that type
> of attack. If the CSR
I ran into this issue with daemons/scheduled jobs and "idle in
transaction" in Django quite a while ago. I have a nice writeup of the
problem and solution on this StackOverflow question if anybody's
interested:
http://stackoverflow.com/questions/1303654/threaded-django-task-doesnt-automatically-ha
On Mon, Sep 6, 2010 at 10:39 PM, Patryk Zawadzki wrote:
> ...
First stab at a patch attached. Did not try to run it yet so it might
contain syntax errors.
--
Patryk Zawadzki
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to thi
On Mon, Sep 6, 2010 at 9:11 PM, Patryk Zawadzki wrote:
> Consider the following example. It was based on the code I wrote to
> handle the new Facebook API so it might be a bit of an overkill but it
> shows it's possible. A simpler solution would be to return (TTL + ':'
> + md5(token + user_ip + se
Hi,
Since CSRF is already being reafactored up-side down in the trunk, I
thought it might be a good idea to propose a slight modification.
Currently CSRF either falls through to the resolved view function or
calls settings.CSRF_FAILURE_VIEW. More than once I've found myself
wanting something in b
Thanks everybody!
while indeed it's clear django will not official run on 3.0 any soon,
it's clearer to me why & how.
yes I'm aware of __future__ import, though it's not really magic (eg.
support for bytes / unicode types is more of a compatibility thing,
for argparse python 2.7 minimum is necess
On Mon, Sep 6, 2010 at 8:25 PM, Luke Plant wrote:
> Almost everything in this discussion and all your misconceptions are
> covered here:
>
> http://code.djangoproject.com/wiki/CsrfProtection
I've read it before joining the discussion.
> For HTTP (not HTTPS), MitM attacks are out of scope for our
On Mon, 2010-09-06 at 18:46 +0200, Patryk Zawadzki wrote:
> On Mon, Sep 6, 2010 at 6:34 PM, Luke Plant wrote:
> > OK, that does it. I call 'troll'. If you're not trolling, my
> > apologies, but I have run out of energy trying to explain this to you.
>
> I'm still waiting for you to explain anyt
On Mon, Sep 6, 2010 at 4:47 PM, Robert Gravsjö wrote:
> Patryk Zawadzki skrev 2010-09-06 15.29:
>> The isolating transaction keeps going on until you either (1) commit,
>> (2) rollback or (3) disconnect. Django only commits/rollbacks the
>> transactions it explicitly starts, it does not care about
On Mon, 2010-09-06 at 16:47 +0200, Robert Gravsjö wrote:
> Can you please show me the code you're running to reproduce this?
>
> Regards,
> roppert
I've experienced what Patryk is describing here. It seems that the
Django ORM, when not explicitly in a transaction, doesn't commit or
rollback after
On Mon, Sep 6, 2010 at 6:34 PM, Luke Plant wrote:
> OK, that does it. I call 'troll'. If you're not trolling, my
> apologies, but I have run out of energy trying to explain this to you.
I'm still waiting for you to explain anything.
You said you were afraid of a third-party injecting cookies o
On Mon, 2010-09-06 at 18:14 +0200, Patryk Zawadzki wrote:
> On Mon, Sep 6, 2010 at 5:56 PM, Patryk Zawadzki wrote:
> > In fact current implementation is weaker than the old one. You are now
> > depending on the client delivering the challenge and the response,
> > both being sent over HTTP. An att
On Mon, Sep 6, 2010 at 5:56 PM, Patryk Zawadzki wrote:
> In fact current implementation is weaker than the old one. You are now
> depending on the client delivering the challenge and the response,
> both being sent over HTTP. An attacker no longer has to steal a valid
> session cookie, it's enough
On Mon, Sep 6, 2010 at 5:54 PM, Luke Plant wrote:
> On Mon, 2010-09-06 at 16:42 +0200, Patryk Zawadzki wrote:
>> If you use a separate *secure* cookie for CSRF over SSL then it's not
>> possible to submit data from an unsafe page to a safe processor.
>> Secure cookies are only sent to SSL targets
On Mon, Sep 6, 2010 at 4:42 PM, Patryk Zawadzki wrote:
> On Mon, Sep 6, 2010 at 3:55 PM, Luke Plant wrote:
>> On Sun, 2010-09-05 at 19:49 +0200, Patryk Zawadzki wrote:
>>> As for the vulnerability -- it's only there if you implement it
>>> yourself. If you send the initial login form over SSL (we
On Mon, 2010-09-06 at 16:42 +0200, Patryk Zawadzki wrote:
> If you use a separate *secure* cookie for CSRF over SSL then it's not
> possible to submit data from an unsafe page to a safe processor.
> Secure cookies are only sent to SSL targets so it's not possible to
> intercept the cookie by any m
Patryk Zawadzki skrev 2010-09-06 15.29:
On Mon, Sep 6, 2010 at 2:00 PM, Robert Gravsjö wrote:
I'm not sure what you think you are doing but if you end up with "
in transaction" that means you have not commited your transactions.
See below.
For instance, open two connections with psql an
On Mon, Sep 6, 2010 at 3:55 PM, Luke Plant wrote:
> On Sun, 2010-09-05 at 19:49 +0200, Patryk Zawadzki wrote:
>> As for the vulnerability -- it's only there if you implement it
>> yourself. If you send the initial login form over SSL (we do it this
>> way for various reasons), the cookies are neve
On Sun, 2010-09-05 at 19:49 +0200, Patryk Zawadzki wrote:
> As for the vulnerability -- it's only there if you implement it
> yourself. If you send the initial login form over SSL (we do it this
> way for various reasons), the cookies are never prone to be
> intercepted.
No, the vulnerability we
On Mon, Sep 6, 2010 at 2:00 PM, Robert Gravsjö wrote:
> I'm not sure what you think you are doing but if you end up with "
> in transaction" that means you have not commited your transactions.
See below.
> For instance, open two connections with psql and run BEGIN in one and
> then take a look
Patryk Zawadzki skrev 2010-09-06 12.20:
On Mon, Sep 6, 2010 at 11:20 AM, Kirit Sælensminde (kayess)
wrote:
--- snip ---
You can check this by creating a fresh project using psycopg2 and
creating a model. Then write a view that queries the database and
invoke it. Now, leaving the server r
On Mon, Sep 6, 2010 at 1:35 PM, burc...@gmail.com wrote:
> Hi Patryk,
>
> This was done to make Django faster, so it doesn't create connection
> to database every time new SQL is executed.
What was done? Commiting the isolating transaction of a connection
does not terminate it.
> Do you mean you
Hi Patryk,
This was done to make Django faster, so it doesn't create connection
to database every time new SQL is executed.
Do you mean you wanted to set up timeouts for idle database connections?
I guess, nobody asked this before.
On Mon, Sep 6, 2010 at 5:20 PM, Patryk Zawadzki wrote:
> On Mon,
On Mon, Sep 6, 2010 at 11:20 AM, Kirit Sælensminde (kayess)
wrote:
> Strange. We use Postgres and don't see any problem with this. We do
> encounter complications occasionally with the lack of composition of
> Django transaction handling, but other than that find the transaction
> handling adequat
Strange. We use Postgres and don't see any problem with this. We do
encounter complications occasionally with the lack of composition of
Django transaction handling, but other than that find the transaction
handling adequate.
Are you actually using transactions in your code? You need to be. The
tr
30 matches
Mail list logo
