[jira] [Created] (SOLR-12916) Fail to parse queries for listeners added via Config API
Konstantin Gribov created SOLR-12916:
Summary: Fail to parse queries for listeners added via Config API
Key: SOLR-12916
URL: https://issues.apache.org/jira/browse/SOLR-12916
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: config-api
Affects Versions: 7.5
Reporter: Konstantin Gribov
{{//listener/queries}} should be array of {{NamedList}} but it can't be added
via Config API (or configoverlay.json) since things like {{"queries": [ ["q",
"*:*", "rows", 1] ]}} are deserialized into {{List}} and not into
{{List}} required in {{QuerySenderListener:51}} (as of Solr 7.5.0).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7896) Solr Administrative Interface Lacks Password Protection
[
https://issues.apache.org/jira/browse/SOLR-7896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709254#comment-14709254
]
Konstantin Gribov commented on SOLR-7896:
-
My point on enabling/disabling SSL by default is that Solr is often behind
firewall and _near_ to back-end which use it, they are both in some kind of
private network, so TLS will be cpu, network and management overhead for such
cases. I believe that it's primary use case and exposed Solr installations are
rare.
Also, requiring admin UI auth seems to be a good idea only at first glance.
Under the cover it will require non-trivial role model to separate user actions
and admin actions on all available handlers (like discussed in SOLR-7838) which
heavy depends on configured handlers and use case: sometimes {{update}} is
normal action for user and {{delete by id}} is not, sometimes {{delete by id}}
should be allowed, but {{delete by query}} shouldn't etc.
Another potential issue with self-made security framework is creating high
quality security modules. If some of them may be created and distributed with
Solr, so pass some QA by Solr committers, third party modules can have lesser
quality and affect overall Solr experience. Buggy or just slow third party
security filter will lead to bad user experience. Credentials and authN/authZ
rules caching and synchronization are other hard-to-implement-correctly part,
especially in distributed environment.
Since role to user mapping is non-trivial and authN/authZ is hard to configure,
security setup as standard Solr installation step would be frightening for many
users. I think, it should be optional for users, who want or have to use such
security model.
Solr Administrative Interface Lacks Password Protection
---
Key: SOLR-7896
URL: https://issues.apache.org/jira/browse/SOLR-7896
Project: Solr
Issue Type: Bug
Components: security, web gui
Affects Versions: 5.2.1
Reporter: Aaron Greenspan
Priority: Critical
Out of the box, the Solr interface should require an administrative password
that the user is required to set. Apparently there are ways of configuring
Jetty to do this with HTTP AUTH or whatever. I'm a moderately experienced
Linux admin and a programmer; I've tried, numerous times, and I've not once
been able to get it to work. The point is this, though:
*No one should have to try to get their Solr instance to support password
authentication and preferably SSL (even if it's just with a self-signed
certificate). Solr is designed to store huge amounts of data and is therefore
a likely target for malicious users.*
This needs to be addressed! It's 2015 and Solr is on version 5!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-7835) solr.schema.FieldType#createFields has incorrect check for absent docValues
Konstantin Gribov created SOLR-7835:
---
Summary: solr.schema.FieldType#createFields has incorrect check
for absent docValues
Key: SOLR-7835
URL: https://issues.apache.org/jira/browse/SOLR-7835
Project: Solr
Issue Type: Bug
Components: Schema and Analysis
Affects Versions: 5.2.1
Reporter: Konstantin Gribov
Priority: Minor
{{lucene.document.FieldType#docValuesType()}} call always return non-null
result which is protected by setter and copy constructor.
This method is used in {{solr.schema.FieldType#createFields(...)}} to enforce
valid docValues type for field with {{docValues=true}} in schema.
Current check is incorrect since it compares {{docValuesType}} to {{null}}
which is always false.
In case of incorrectly implemented Solr FieldType which overrides
{{checkSchemaField(...)}} to allow docValues and doesn't override
{{createFields(...)}} it leads to buggy behavior: user thinks that field use
docValues (since it's set in schema.xml and solr doesn't indicates any error),
but really {{UninvertingReader}} with {{fieldValuesCache}} is used for
faceting, grouping etc.
This issue is only present when user creates his own {{solr.schema.FieldType}}
implementation because Solr FieldTypes which don't support docValues do not
override {{checkSchemaField(...)}} method.
I will push pull request with patch and test case in several minutes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7765) TokenizerChain methods may return null depending on how constructor is called -- causes NPE in luke request handler
[
https://issues.apache.org/jira/browse/SOLR-7765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14637291#comment-14637291
]
Konstantin Gribov commented on SOLR-7765:
-
I understand you point, I write in C time to time. My point is that it leads to
inconsistency in code style without any profit (like eliminating error-prone
constructs in C). It makes no sense in java, since for types other than boolean
it will produce compile-time error (because type incompatibility) and for
boolean ifs will look like {{if (val)}} or {{if (!val)}}. It seems that there's
no place to make this types of error in java.
TokenizerChain methods may return null depending on how constructor is called
-- causes NPE in luke request handler
---
Key: SOLR-7765
URL: https://issues.apache.org/jira/browse/SOLR-7765
Project: Solr
Issue Type: Bug
Affects Versions: 5.2.1
Reporter: Konstantin Gribov
Assignee: Hoss Man
Priority: Minor
Fix For: 5.3, Trunk
Attachments: SOLR-7765.patch, SOLR-7765.patch, SOLR-7765.patch
{{TokenizerChain}} created using 2-arg constructor has {{null}} in
{{charFilters}}, so {{LukeRequestHandler}} throws NPE on iterating it.
{{TokenizerChain}} constructor's should be hardened to do explicit null
checks, throwing early NPE where appropriate (tokenizer factory), or
initializing internal arrays to have 0 length when optional (factories for
char filters and token filters)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7765) TokenizerChain without char filters cause NPE in luke request handler
[
https://issues.apache.org/jira/browse/SOLR-7765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14635043#comment-14635043
]
Konstantin Gribov commented on SOLR-7765:
-
Fixing this in {{TokenizerChain}} itself seems better to me.
Is there any reason to use reversed order in ifs (like {{if (0
cfiltfacs.length)}})? It looks quite strange since most of lucene solr code
use more usual {{if (var 0)}} style.
TokenizerChain without char filters cause NPE in luke request handler
-
Key: SOLR-7765
URL: https://issues.apache.org/jira/browse/SOLR-7765
Project: Solr
Issue Type: Bug
Affects Versions: 5.2.1
Reporter: Konstantin Gribov
Assignee: Hoss Man
Priority: Minor
Attachments: SOLR-7765.patch, SOLR-7765.patch, SOLR-7765.patch
{{TokenizerChain}} created using 2-arg constructor has {{null}} in
{{charFilters}}, so {{LukeRequestHandler}} throws NPE on iterating it.
Will create PR in a couple of minutes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7765) TokenizerChain without char filters cause NPE in luke request handler
[
https://issues.apache.org/jira/browse/SOLR-7765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14628258#comment-14628258
]
Konstantin Gribov commented on SOLR-7765:
-
Updated PR with test case
TokenizerChain without char filters cause NPE in luke request handler
-
Key: SOLR-7765
URL: https://issues.apache.org/jira/browse/SOLR-7765
Project: Solr
Issue Type: Bug
Affects Versions: 5.2.1
Reporter: Konstantin Gribov
Assignee: Hoss Man
Priority: Minor
Attachments: SOLR-7765.patch
{{TokenizerChain}} created using 2-arg constructor has {{null}} in
{{charFilters}}, so {{LukeRequestHandler}} throws NPE on iterating it.
Will create PR in a couple of minutes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7765) TokenizerChain without char filters cause NPE in luke request handler
[
https://issues.apache.org/jira/browse/SOLR-7765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14628046#comment-14628046
]
Konstantin Gribov commented on SOLR-7765:
-
I am not familiar with lucene-solr test suite. It seems that {{TokenizerChain}}
was created standard way from schema (via {{FieldTypePluginLoader}}, line
403@lucene_solr_5_2_1), so it was created with
{code:java}
new TokenizerChain(charFilters.toArray(new
CharFilterFactory[charFilters.size()]), tokenizers.get(0), filters.toArray(new
TokenFilterFactory[filters.size()]));
{code}
which is three-arg constructor with non-null first argument (it will be empty
array when {{charFilters}} is empty).
I'll add a test to my PR.
TokenizerChain without char filters cause NPE in luke request handler
-
Key: SOLR-7765
URL: https://issues.apache.org/jira/browse/SOLR-7765
Project: Solr
Issue Type: Bug
Affects Versions: 5.2.1
Reporter: Konstantin Gribov
Assignee: Hoss Man
Priority: Minor
Attachments: SOLR-7765.patch
{{TokenizerChain}} created using 2-arg constructor has {{null}} in
{{charFilters}}, so {{LukeRequestHandler}} throws NPE on iterating it.
Will create PR in a couple of minutes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-7765) TokenizerChain without char filters cause NPE in luke request handler
Konstantin Gribov created SOLR-7765:
---
Summary: TokenizerChain without char filters cause NPE in luke
request handler
Key: SOLR-7765
URL: https://issues.apache.org/jira/browse/SOLR-7765
Project: Solr
Issue Type: Bug
Affects Versions: 5.2.1
Reporter: Konstantin Gribov
Priority: Minor
{{TokenizerChain}} created using 2-arg constructor has {{null}} in
{{charFilters}}, so {{LukeRequestHandler}} throws NPE on iterating it.
Will create PR in a couple of minutes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7763) Solr website: In the Docs section of the Resource page, invisible release docs text and missing link
[
https://issues.apache.org/jira/browse/SOLR-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14617256#comment-14617256
]
Konstantin Gribov commented on SOLR-7763:
-
Thanks for fixing this, Steve
Solr website: In the Docs section of the Resource page, invisible release
docs text and missing link
Key: SOLR-7763
URL: https://issues.apache.org/jira/browse/SOLR-7763
Project: Solr
Issue Type: Bug
Components: website
Reporter: Steve Rowe
Priority: Minor
From Konstantin Gribov on the dev list:
{quote}
Currently API docs for Lucene can be found in 2 clicks from lucene.apache.org
(lucene core link, then 5.2.1 in release docs).
But it isn't so easy for Solr. I haven't found it on lucene.apache.org/solr/
site anywhere (maybe it can be found somewhere in cwiki, but not on front
page of reference guide there). Only google helped me with it.
[...]
I think, link to lucene.apache.org/solr/api/ should be added to
resources/docs on Solr site.
{quote}
The text “Latest Release” directly under the “Documentation” heading at
http://lucene.apache.org/solr/resources.html#documentation is supposed to
link to the Solr equivalent of the Lucene release docs - if you look at the
source for the page it’s:
{code:html}
h2 id=documentationDocumentation/h2
h3 class=offset id=release-documentationRelease Documentation/h3
pIn each Solr binary release artifact, you can find a copy of the Solr
tutorial, a detailed list of changes, and JavaDocs for all included code.
Copies of this documentation for the most recent release of each major branch
under active development can also be found online:/p
ul
lia href=/solr/5_2_0/index.htmlLatest Release/a/li
/ul
{code}
But for me on Safari on OS X, most of this text is invisible (including the
Release Documentation header and the paragraph starting In each Solr
binary release artifact), and the “Latest Release” text does not link to the
release docs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5377) the Core Selector in the Admin UI should pre-select a core
[
https://issues.apache.org/jira/browse/SOLR-5377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14188231#comment-14188231
]
Konstantin Gribov commented on SOLR-5377:
-
Maybe, parameter {{/solr/cores\[@defaultCoreName]}} (in xpath notation) from
old {{solr.xml}} should be somehow added to the new {{solr.xml}} parameters.
the Core Selector in the Admin UI should pre-select a core
Key: SOLR-5377
URL: https://issues.apache.org/jira/browse/SOLR-5377
Project: Solr
Issue Type: Improvement
Reporter: Michael McCandless
Priority: Minor
I was trying to use the admin UI, to understand how text was analyzed, but it
was confusing (I couldn't find the Analysis page) until I realized I had to
use the Core Selector to select my core.
I had only one core ... it seems like the Core Selector could easily just
pre-select a core (the one in my case...).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
