On Aug 14, 2010, at 10:53 AM, mdipierro wrote:
> perhaps app level regex validation config?
We need to first do standards-based URL parsing and decoding, and then apply
validation as a subsequent step.
One option would be to accept anything that's legal in a URL; the app would do
its own validation. This would be useful for a query string that needed
different validation for different args/vars.
We could automate that, too, or at least provide helpers. Perhaps a list of
var-key patterns and corresponding validation patterns for the arguments.
>
> On Aug 14, 11:04 am, Jonathan Lundell <jlund...@pobox.com> wrote:
>> On Aug 14, 2010, at 6:10 AM, mdipierro wrote:
>>
>>
>>
>>> On Aug 14, 5:55 am, Jurgis Pralgauskis <jurgis.pralgaus...@gmail.com>
>>> wrote:
>>>> On Aug 5, 3:41 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
>>
>>>>> the problem is not the escaping (which is correct, + must be escaped)
>>>>> the problem is thta web2py urls do not allow non-alphanumeric chars.
>>
>>>> but for arguments there seems to be no need for such restriction, or
>>>> is there?
>>
>>> It is our policy that arguments should be alphanumeric. This is
>>> because they can be used to id records or access the file system and
>>> we do not worry you to have to worry about validating then. This does
>>> not mean you cannot have "c++" in a URL. It just means you must use
>>> routes to map an arg into a var.:
>>
>>> routes_in =[('/app/c/f/$anything','/app/c/f/data=$anything')]
>>
>> Down the road, I hope to introduce a URL validation & rewrite subsystem that
>> will allow the user a little more flexibility in this respect; the current
>> restriction doesn't make sense in all cases (or could be enforced more
>> locally).
