Looking at it again, I think you might be right - any default filter is
going to miss stuff, and cause unexpected data loss. Also, the more we
do catch, the greater the runtime penalty. (If you think about it,
filtering input to be 'safe' for a computation almost canonically maps
to the halting pr
On 22/11/05, Robert Wittams <[EMAIL PROTECTED]> wrote:
> No. The developer finds out that if he wants to create an XSS attack
> catalog, he needs to be explicit about it. If a developer fails to read
> the documentation, he is not going to get the most out of the framework.
We are both wanting t
On 22 Nov 2005, at 09:03, Simon wrote:
PHP does (try) to do something similar - with the magic_quotes_gpc
setting ( gpc = "Get, Post, Cookie" ), it automatically adds
slashes to
strings - for those who don't do PHP:
I think the web development world has pretty much universally agreed
th
Hi all,
PHP does (try) to do something similar - with the magic_quotes_gpc
setting ( gpc = "Get, Post, Cookie" ), it automatically adds slashes to
strings - for those who don't do PHP:
1) the user enters: O'reilly
2) this data is slashed to O\'reilly and placed into the superglobal
array ( i.e.
On 11/22/05, Robert Wittams <[EMAIL PROTECTED]> wrote:
> Why are you ignoring the whole aim of this thread? The point is to do
> the *safest* thing possible *when* the developer doesn't specify
> anything else. The point is when the developer wants to do something
> potentially *stupid and dangero
Kevin wrote:
> What about placing this suggested functionality in middleware? The
> middleware would replace request.[GET|POST] with a wrapper class that
> provides these filtering/conversion methods?
>
>
That would be techically possible, but I can't see the point.
Luke Plant wrote:
>
> On Mon, 21 Nov 2005 23:44:27 + Robert Wittams wrote:
>
>
>>> In ASP.NET (my
>>>
>>
>>We have all used crap implementations of many ideas - a large
>>proportion of which are made by the same company as your example. The
>>existance of a crap implementation does not prec
On Mon, 21 Nov 2005 23:44:27 + Robert Wittams wrote:
> > In ASP.NET (my
> >
>
> We have all used crap implementations of many ideas - a large
> proportion of which are made by the same company as your example. The
> existance of a crap implementation does not preclude a good
> implementat
What about placing this suggested functionality in middleware? The
middleware would replace request.[GET|POST] with a wrapper class that
provides these filtering/conversion methods?
Luke Plant wrote:
> On Sun, 20 Nov 2005 20:21:54 -0600 Jacob Kaplan-Moss wrote:
>
>
> This highlights the problem with this approach - what is "safe"? Safe
> for output in HTML? Safe against SQL injection attacks (assume for a
> second someone isn't using Django's DB backend)? Safe for inserti
On Sun, 20 Nov 2005 20:21:54 -0600 Jacob Kaplan-Moss wrote:
> I think this is a brilliant idea. As far as I know no other
> frameworks take input security quite as seriously as they should,
> and I'd love nothing more than to become the OpenBSD of web
> frameworks.
>
> That said, I'm less tha
Simon Willison wrote:
a = request.GET.as_int('a')
Looks like I will be the one breaking the party :-)
I don't like this idea for two reasons.
The first is simple: it makes code ugly and much less readable. I had
this experience with Delphi where you have always do something like
Table.Fie
Simon Willison wrote:
>
>
> On 21 Nov 2005, at 02:08, Robert Wittams wrote:
>
>> from django.core import input
>>
>> a = request.GET.get('a', 0).as(input.int)
>> a_list = request.GET.get_list('a', 0).as(input.int)
>
>
> That syntax looks pretty smart to me. It's definitely extensible - it
>
On 21 Nov 2005, at 02:08, Robert Wittams wrote:
from django.core import input
a = request.GET.get('a', 0).as(input.int)
a_list = request.GET.get_list('a', 0).as(input.int)
That syntax looks pretty smart to me. It's definitely extensible - it
would be trivial to define your own input filte
>me. I *really* like having the default request.GET['foo'] return a
>"safe" object... but the as_* methods kinda weird me out. I'd have
>to play with it, but perhaps GET.__getitem__ could return a string
>subclass that acted "safe" unless cast to an "unsafe" object explicitly?
Should be easily
On 11/21/05, Simon Willison <[EMAIL PROTECTED]> wrote:
> a = request.GET.as_email('email')
> a = request.GET.as_float('f')
> a = request.GET.as_safe_html('body')
I had the same idea for an old (now very dead) web-framework I
was working on. If anyone wants to see how it can be done,
the code is a
On Nov 20, 2005, at 6:11 PM, Simon Willison wrote:
The idea is to make developers have to go out of their way to avoid
input filtering. This is certainly something that would greatly
benefit the world of PHP. Developers who use Django may like to
think themselves above such mistakes, but mi
Simon Willison wrote:
>
>
> On 21 Nov 2005, at 01:05, Robert Wittams wrote:
>
>> Also, do we just pick a bunch of things this works for, or is it
>> extensible?
>
>
> Definitely extensible. Ideally developers will add new filters to fit
> any type that their application deals with that isn't
On 21 Nov 2005, at 00:57, Ian Holsman wrote:
I think it should raise an exception, and you should pass a default
key in there if it isn't present.
so the function might be written as
a = request.GET.as_int('a', 0)
I like this. If a default argument is given, return that. Otherwise,
raise
On 21 Nov 2005, at 01:05, Robert Wittams wrote:
Also, do we just pick a bunch of things this works for, or is it
extensible?
Definitely extensible. Ideally developers will add new filters to fit
any type that their application deals with that isn't already
covered. As such, my initial pr
nt to get an integer that someone
> has entered. In current Django, you might do this:
>
> a = int(request.GET['a'])
>
> With smart input filtering, you would do something like this instead:
>
> a = request.GET.as_int('a')
>
> Functions like this can be c
my 2c's
I think it should raise an exception, and you should pass a default
key in there if it isn't present.
so the function might be written as
a = request.GET.as_int('a', 0)
as to why it should raise an exception on invalid input?
because somewhere your not getting valid input, and raising
On 21 Nov 2005, at 00:41, Adrian Holovaty wrote:
That's quite an interesting idea! The immediate question I have is:
What would it do if "a" is empty or not an integer? Raise an
exception? Return an empty string?
Hmm... good question. Since you asked for an integer it could return
0, but t
On 11/20/05, Simon Willison <[EMAIL PROTECTED]> wrote:
> In current Django, you might do this:
>
> a = int(request.GET['a'])
>
> With smart input filtering, you would do something like this instead:
>
> a = request.GET.as_int('a')
That's quit
u might do this:
a = int(request.GET['a'])
With smart input filtering, you would do something like this instead:
a = request.GET.as_int('a')
Functions like this can be created for all kinds of data. Here are a
few examples off the top of my head:
a = r
25 matches
Mail list logo
