If no limit is specified, a default limit of 10 is enforced instead. I think it would make more sense to simply not enforce a specific limit in this case, and allow the view's own limit (if any) to be used.

CommentFileSizeAuthor
services_views.limit_.patch1.59 KBjohn morahan

Comments

ygerasimov’s picture

ygerasimov commented
Category: feature » support
Status: Needs review » Fixed

I understand what you are requesting, but I would like to keep the things as they are. The thing is that if we do not apply limit this opens DoS attack possibility that is hard to notice. So if you really need to have unlimited behavior by default you can alter arguments (hook_services_request_preprocess_alter) adding default limit parameter:

if (!isset($_GET['limit'])) {
  $_GET['limit'] = PHP_INT_MAX;
}

Hope it will do the job for your case.

john morahan’s picture

john morahan commented
Category: support » feature
Status: Fixed » Needs review

Sorry, but I think you may have misunderstood what I was requesting. I do not want unlimited behaviour by default. I want to use the limit that is configured in the view, rather than a hard-coded limit of 10 always, so that while there is still a limit by default, it is configurable.

I do not see how this increases the possibility of a DoS attack. What's to prevent someone sending ?limit=2147483647 with the current setup?

windmaomao’s picture

windmaomao commented

what i see is that the default value (if not set) should be view's setting, currently while using pagination, it'll be always 10 records, unless i set it otherwise, ex.

$items = services_views_retrieve('services_dispenses_api', 'services_1', array(), 0, 25);

let me know if it makes sense.

ygerasimov’s picture

ygerasimov commented
Status: Needs review » Fixed

Committed.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.