[
https://issues.apache.org/jira/browse/SOLR-1687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12836930#action_12836930
]
Hoss Man commented on SOLR-1687:
--------------------------------
bq. Traditionally, this type of stuff is delegated to the front-end clients to
restrict.
True, but my suggestion wasn't so much along the lines of "end users" entering
really big numbers as much as that "client developers" might make mistakes, and
this would allow a solr admin to lock things down in a sane way.
bq. Would it make more sense to add an optional component to check
restrictions? The restrictions could optionally be in the config for the
component and thus wouldn't have to be looked up and parsed for every request.
I like this idea, but given the way local versions of start/rows are treated
special wouldn't we still need special like what i added in the patch to deal
with them? (a generic component added to the front of the list could check
validate a list of global params, but it wouldn't have anyway of knowing for
certain what other params later components might parse with a QParser.
> add param for limiting start and rows params
> --------------------------------------------
>
> Key: SOLR-1687
> URL: https://issues.apache.org/jira/browse/SOLR-1687
> Project: Solr
> Issue Type: Improvement
> Reporter: Hoss Man
> Attachments: SOLR-1687.patch
>
>
> conventional wisdom is that it doesn't make sense to paginate with "huge"
> pages, or to drill down "deep" into high numbered pages -- features like
> faceting tend to be a better UI experience, and less intensive on solr.
> At the moment, Sold adminstrators can use "invariant" params to hardcode the
> "rows" param to something reasonable, but unless they only want to allow
> users to look at page one, the can't do much to lock down the "start" param
> expect inforce these rules in the client code
> we should add new params that set an upper bound on both of these, which can
> then be specified as default/invarient params in solrconfig.xml
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
