Hi,
Ref Merging Centralized Tokenization.
I found out that some tests for sessions are failing with it. Stupidly,
I didn't have sessions in my test subset for tokenization. Anyway,
I'll try to get it fixed and write some tests for tokens in next few
days.
--
Thanks
Rohan
On 10:50 +0100 / 21 Aug,
Hi,
Thanks for the reply.
On 10:50 +0100 / 21 Aug, Andrew Godwin wrote:
> Thanks for your work during the GSOC, Rohan - don't worry about not
> achieving everything, it looks like there's still some useful code there!
>
> Hopefully we can get some of the code merged, especially centralised
> tok
Thanks for your work during the GSOC, Rohan - don't worry about not
achieving everything, it looks like there's still some useful code there!
Hopefully we can get some of the code merged, especially centralised
tokenisation if it's so near completion, as it looks like a nice bit of
cleanup code!
Hi,
Today is the 'pencils down' date for this GSoC project. Past 4 months
have been a great learning experience from me. Just being in the
context of security side of the web has been really beneficial. Moving
around in a very well written code base is also delightful.
Meanwhile, I did get to work
Hi,
Sorry for the delay in getting back. I was meanwhile working on
centralized tokenization for few days, while still trying to figure
something better for CSRF.
On 03:52 -0400 / 25 Jul, Alex Ogier wrote:
> On Tue, Jul 24, 2012 at 11:37 PM, Rohan Jain wrote:
> >
> > I had one more idea, "Plugga
On Tue, Jul 24, 2012 at 11:37 PM, Rohan Jain wrote:
>
> I had one more idea, "Pluggable CSRF checkers".
>
> Currently, the CSRF middleware has two kinds of checks, referer (for
> https) and secret validation token (common). These with origin header
> based checker (if we add it) come in conditiona
On 19:46 +0100 / 23 Jul, Luke Plant wrote:
> On 23/07/12 14:24, Rohan Jain wrote:
> > With this, attacker won't be able to directly set arbitrary tokens on
> > other sub domains through cookies, they will need a signature of the
> > token with the form which is to be verified against the cookie.
>
On 23/07/12 14:24, Rohan Jain wrote:
> With this, attacker won't be able to directly set arbitrary tokens on
> other sub domains through cookies, they will need a signature of the
> token with the form which is to be verified against the cookie.
> Plus it also puts a limit on the duration a token s
On 11:06 +0100 / 23 Jul, Luke Plant wrote:
> On 23/07/12 08:07, Rohan Jain wrote:
> > ###CSRF Cookies (Time signed):
> >
> > - A random token generated by the server stored in the browser cookies. For
> >verification, every non get request will need to provide a signed
> > version of
> >
On 23/07/12 08:07, Rohan Jain wrote:
> ###CSRF Cookies (Time signed):
>
> - A random token generated by the server stored in the browser cookies. For
>verification, every non get request will need to provide a signed version
> of
>the same token. This can then be verified on the browser
Hi,
Centralized Tokenization:
I have merged the work already done for centralized-tokenization in
last djangocon at [yarko/django][0]. Since it there have been
significant amount of changes since then, merging and resolving
conflicts took a little more time then expected. As of now the tests
are
Hi,
This check-in is a little delayed. Meanwhile, I continued working on
CSRF and started a on centralized tokenization.
As I had posted, I implemented the permitted domains system, as
`CSRF_PERMITTED_DOMAINS`. I did some minor cleanups and tests, the
behaviour is mostly the same. Since with the
I have done some work on CSRF revolving around origin header checking.
The origin header is fairly new and is not yet implemented in a
uniform fashion in the major browsers, so it cannot be solely relied
upon for CSRF checks. Instead we check if the header exists and use it
only for rejection of re
Hi,
Since my last check in I worked on improvements to
contrib.sessions:
- Introduction of signing framework
- Session expiry checks (for Ticket [#18194][0]
- And some other trivial patches.
The tests (existing and the one which I added) are passing.
These changes are in my [Pull Request #78
Hi,
Last week I looked into the Ticket [#18194][0]:
- Trivial attempts to handle the issue.
- Wrote a minor initial patch.
- The test fails for Cache and Cookie backend.
Also, I looked at the talks from Paul regarding advanced security
topics at py/django cons. Realised that why I should not
Hi,
I am Rohan Jain, a student from Indian Institute of Technology,
Kharagpur. I'll be doing a Google Summer of Code project with django
this year under the title "Security Enhancements". As the title
suggests, it has something to do with Security Enhancements: like
improvements in CSRF protection
16 matches
Mail list logo