Hi,

On 11.01.2010 21:48, Ian Boston wrote:
> 
> On 11 Jan 2010, at 19:50, Felix Meschberger wrote:
> 
>> Hi Simon,
>>
>> On 11.01.2010 19:01, Simon Gaeremynck wrote:
>>> Yes, I guess that could work.
>>>
>>> But then you can still do node.1000000.json which results in the same
>>> thing.
>>>
>>> I took the liberty to write a patch which checks the amount of resources
>>> will be in the result.
>>> If the result is bigger than a pre-defined OSGi property (ex: 200
>>> resources) it will send a 206
>>> partial content with the dump of 200 resources and will ignore the rest.
>>>
>>> It can be found at http://codereview.appspot.com/186072
>>
>> This looks interesting. Tough instead of limiting the number of
>> reosources to return, I would limit the number of levels to return.
>>
>> WDYT ?
> 
> with 4 levels its quite easy to get to 4E9 files (255^^4) which would take 
> quite a lot of time to send. Simon works in the same office and we chatted 
> about this when we thought it might be possible to solve in Sakai, but I 
> think its probably important for Sling as well.
> Ian

Correct and yes, such a limitation would suit Sling very well (in Day we
also have been thinking of such limitations - but along the lines of
depths limit rather than a number limit)

Regards
Felix

> 
> 
> 
>>
>> Regards
>> Felix
>>
>>>
>>> Simon
>>>
>>>
>>> On 10 Jan 2010, at 16:43, Eric Norman wrote:
>>>
>>>> One option would be to register your own script (or servlet) that also
>>>> matches the same selector [+extension].  Since your script would be a
>>>> closer
>>>> match than the default get servlet, it should use your script instead.
>>>>
>>>> For example, create an esp script @
>>>> apps/sling/servlet/default/infinity.json.esp
>>>>
>>>> The content of the infinity.json.esp script could just send a 404
>>>> error to
>>>> the response.
>>>> <%
>>>>  response.sendError(404);
>>>> %>
>>>>
>>>>
>>>> On Fri, Jan 8, 2010 at 9:18 AM, Simon Gaeremynck
>>>> <[email protected]>wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Is there any way of disable or restricting the node.infinity.json
>>>>> selector.
>>>>> We have quite a bit of content and when we do a .infinity.json on our
>>>>> root
>>>>> node this causes the server to grind to a halt.
>>>>> It looks like it's internal to JsonRendererServlet but I might be
>>>>> overseeing something.
>>>>>
>>>>> This looks to me like a potential hole for a DOS attack.
>>>>>
>>>>>
>>>>> Kind regards,
>>>>>
>>>>> Simon
>>>>>
>>>
>>>
> 
> 

Reply via email to