Severity: High
Vendor: The Apache Software Foundation
Versions Affected:
6.6.0 to 6.6.5
7.0.0 to 7.7.3
8.0.0 to 8.6.2
Description:
Solr prevents some features considered dangerous (which could be used for
remote code execution) to be configured in a ConfigSet that's uploaded via
API without auth
Severity: Medium
Vendor: The Apache Software Foundation
Versions Affected:
1.3.0 to 1.4.1
3.1.0 to 3.6.2
4.0.0 to 4.10.4
Description: Solr versions prior to 5.0.0 are vulnerable to an XML resource
consumption attack (a.k.a. Lol Bomb) via it’s update handler. By leveraging
XML DOCTYPE and ENTITY
Severity: High
Vendor: The Apache Software Foundation
Versions Affected:
5.0.0 to 5.5.5
6.0.0 to 6.6.5
Description:
ConfigAPI allows to configure Solr's JMX server via an HTTP POST request.
By pointing it to a malicious RMI server, an attacker could take advantage
of Solr's unsafe deserializatio
CVE-2017-3164 SSRF issue in Apache Solr
Severity: High
Vendor: The Apache Software Foundation
Versions Affected:
Apache Solr versions from 1.3 to 7.6.0
Description:
The "shards" parameter does not have a corresponding whitelist mechanism,
so it can request any URL.
Mitigation:
Upgrade to Apach
I Daphne,
the “possible analysis error” is a misleading error message (to be addressed in
SOLR-12477). The important piece is the
“java.lang.ArrayIndexOutOfBoundsException”, it looks like your index may be
corrupted in some way.
Tomás
> On Jul 11, 2018, at 3:01 PM, Liu, Daphne wrote:
>
> He
I'd never noticed this before, but I believe it happens because, once you say
`facet=true`, Solr will need the full docset (the set of all matching docs, not
just the top matches) and does so by using the filter cache.
> On May 3, 2018, at 7:10 AM, Markus Jelsma wrote:
>
> By the way, the quer
This shouldn’t be happening. Did you see anything related in the logs? Does the
new NRT replica ever becomes active? Is there a new core created or do you just
see the replica in the clusterstate?
Tomas
Sent from my iPhone
> On Mar 7, 2018, at 8:18 PM, Greg Roodt wrote:
>
> Hi
>
> I am run
this implicit request handler is configured correctly Any
> thoughts, what I might be missing?
>
>
>
> On Sun, Feb 18, 2018 at 11:18 PM, Tomas Fernandez Lobbe
> wrote:
>
>> I think real-time get should be directed to the correct shard. Try:
>> [COLLECTION]/ge
I think real-time get should be directed to the correct shard. Try:
[COLLECTION]/get?id=[YOUR_ID]
Sent from my iPhone
> On Feb 18, 2018, at 3:17 PM, Ganesh Sethuraman
> wrote:
>
> Hi
>
> I am using Solr 7.2.1. I have 8 shards in two nodes (two different m/c)
> using Solr Cloud. The data was
t;>> Is my understanding correct?
>>>
>>> Is this sensible to do, or is it not worth it due to the smart proxying
>>> that SolrCloud can do anyway?
>>>
>>> If the TLOG and PULL replicas are so similar, is there any real advantage
>>>
On the last question:
For Writes: Yes. Writes are going to be sent to the shard leader, and since
PULL replicas can’t be leaders, it’s going to be a TLOG replica. If you are
using CloudSolrClient, then this routing will be done directly from the client
(since it will send the update to the lead
Hi Markus,
If the same code that runs OK in 7.1 breaks 7.2.1, it is clear to me that there
is some bug in Solr introduced between those releases (maybe an increase in
memory utilization? or maybe some decrease in query throughput making threads
to pile up?). I’d hate to have this issue lost in
This seems pretty serious. Please create a Jira issue
Sent from my iPhone
> On Feb 1, 2018, at 12:15 AM, dennis nalog
> wrote:
>
> Hi,
> We are using Solr 7.1 and are solr setup is master-slave replication.
> We encounter this issue that when we disable the replication in master via UI
> or U
I believe the problem is that:
* BlockJoin queries do not know about your “types”, in the BlockJoin query
world, everything that’s not a parent (matches the parentFilter) is a child.
* All docs indexed before a parent are considered childs of that doc.
That’s why in your first case it considers “f
This feature is not currently supported. I was thinking in implementing it by
extending the work done in SOLR-10880. I still didn’t have time to work on it
though. There is a patch for SOLR-10880 that doesn’t implement support for
replica types, but could be used as base.
Tomás
> On Jan 8, 2
By default Solr uses the “TieredMergePolicy”[1], but it can be configured in
solrconfig, see [2]. Merges can be triggered for different reasons, but most
commonly by segment flushes (commits) or other merges finishing.
Here is a nice visual demo of segment merging (a bit old but still mostly
a
I just added you to the wiki.
Note that the official documentation is now in the "solr-ref-guide" directory
of the code base, and you can create patches/PRs to it.
Tomás
> On Aug 23, 2017, at 10:58 AM, Kevin Grimes wrote:
>
> Hi there,
>
> I would like to contribute to the Solr wiki. My user
The query field:* doesn't work with point fields (numerics or dates), only
exact or range queries are supported, so an equivalent query would be field:[*
TO *]
Sent from my iPhone
> On Jun 15, 2017, at 5:24 PM, Saurabh Sethi wrote:
>
> Hi,
>
> We have a fieldType specified for date. Earlier
Hi,
To respond your first question: “How do I get SortedSetDocValues from index by
field name?”, DocValues.getSortedSet(LeafReader reader, String field) (which is
what you want to use to assert the existence and type of the DV) will give you
the dv instance for a single leaf reader. In general,
I think you are missing the collection name in the path.
Tomás
Sent from my iPhone
> On Jun 5, 2017, at 9:08 PM, Phil Scadden wrote:
>
> Simple piece of code. Had been working earlier (though against a 6.4.2
> instance).
>
> ConcurrentUpdateSolrClient solr = new
> ConcurrentUpdateSolrC
Hi Jon, for the first query:
title:"Call of Duty" OR subhead:"Call of Duty"
If you are sure that you have documents with the same phrase, make sure you
don't have a problem with stop words and with token positions. I recommend you
to check the analysis page at the Solr admin. pay special attent
For a field type the anslysis applied at index time (when you are adding
documents to Solr) can be a slightly different than the analysis applied at
query time (when a user executes a query). For example, if you know you are
going to be indexing html pages, you might need to use the
HTMLStripCh
eady working by default?
Is this something to config on my schema.xml?
Tks!!
On Wed, Nov 10, 2010 at 6:40 PM, Tomas Fernandez Lobbe <
tomasflo...@yahoo.com.ar> wrote:
> That's what the ASCIIFoldingFilter does, it removes the accents, that's why
> you
> have to add it to t
e same
way you should be able to find all documents as you require.
On 10 November 2010 20:25, Tomas Fernandez Lobbe
wrote:
> It looks like ISOLatin1AccentFilter is deprecated on Solr 1.4.1, If you are
> on
> that version, you should use the ASCIIFoldingFilter instead.
>
> Like with
hese words are the same, and when I do some search for perequê
or pereque, it should show me 10 results.
About the ISOLatin you told, do you know how can I enable it?
tks,
Claudio
On Wed, Nov 10, 2010 at 5:00 PM, Tomas Fernandez Lobbe <
tomasflo...@yahoo.com.ar> wrote:
> I don't u
I don't understand, when the user search for perequê you want the results for
perequê and pereque?
If thats the case, any field type with ISOLatin1AccentFilterFactory should
work.
The accent should be removed at index time and at query time (Make sure the
filter is being applied on both cases)
26 matches
Mail list logo