Re: BasicAuth help

[Jan Høydahl]

That github patch is interesting.
My initial proposal for how to plug LDAP into Solr was to make the 
AuthenticationProvider pluggable in BasicAuthPlugin, so you could plug in an 
LDAPAuthProvider. See https://issues.apache.org/jira/browse/SOLR-8951 
. No need to replace the whole 
BasicAuth class I think. Anyone who wants to give it a shot, borrowing some 
code from the ldap_solr repo, feel free :)

Jan

> 4. sep. 2020 kl. 09:43 skrev Aroop Ganguly :
> 
> Try looking at a simple ldap authentication suggested here: 
> https://github.com/itzmestar/ldap_solr 
> 
> You can combine this for authentication and couple it with rule based 
> authorization.
> 
> 
> 
>> On Aug 28, 2020, at 12:26 PM, Vanalli, Ali A - DOT > > wrote:
>> 
>> Hello,
>> 
>> Solr is running on windows machine and wondering if it possible to setup 
>> BasicAuth with the LDAP?
>> 
>> Also, tried the example of Basic-Authentication that is published 
>> here>  
>> >
>>  but this did not work too.
>> 
>> Thanks...Ali
>> 
>> 
> 

Re: Solr client

[Konstantinos Koukouvis]

Had no idea about this! Thanks a lot Eric!!

> On 4 Sep 2020, at 12:14, Eric Pugh  wrote:
> 
> Konstantinos, have you seen https://solr.cool/?  It’s an aggregation site for 
> all the extensions to Solr.   You can add your project there, and that should 
> get some more awareness!
> 
> 
>> On Sep 2, 2020, at 2:21 AM, Konstantinos Koukouvis 
>>  wrote:
>> 
>> Hi everybody, sorry in advance if I’m using the mailing list wrong, this is 
>> the first time I’m attempting such a thing.
>> 
>> To all you gophers out there we at Mecenat, have been working at a new solr 
>> client wrapper with focus on single solr instance usage, that supports the 
>> search API, schema API and core admin API. With this email I’m trying to 
>> raise awareness to the community, get some feedback by having more people to 
>> test every nook and cranny of it, so that we can improve our solution and 
>> hopefully help you find that client that makes using solr in go more 
>> intuitive and simple.
>> 
>> Here’s the link, and thank you all for your time:
>> https://github.com/mecenat/solr
>> 
>> With regards,
>> Konstantinos
>> 
> 
> ___
> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | 
> http://www.opensourceconnections.com  
> | My Free/Busy   
> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed 
> 
>   
> This e-mail and all contents, including attachments, is considered to be 
> Company Confidential unless explicitly stated otherwise, regardless of 
> whether attachments are marked as such.
> 

Inverse English an digits in Arabic Text

[adeq8]

Hi,

Could please help to resolve an issue. I upload/index several documents in 
English and in Arabic languages to SOLR, in addition I use handler for Arabic 
language:
  
   
    
    
     
     
    
    

  
  
    
    
    
     
      
    
    

  

There are two environments:
Local machine:     - SOLR version: 4,2
    - Windows version: 10

DEV env:     - SOLR version 4.1 as part of the cloudera suit
    - Linux core version: 3.10.0-862

Issue appears when uploading documents:
Local machine:     - Doc in English with English words only - ok 
(for example, "www.apache.org")
    - Doc in Arabic with some English words - ok (for example, 
"www.apache.org")

DEV env:     - Doc in English with English words only - ok (for 
example, "www.apache.org")
    - Doc in Arabic with some English - English text is inverted 
(for example, "gro.echapa.www"), what makes search by key words impossible.

Please advise whether this fixable and how?

Thank you in advance!

Re: Inverse English an digits in Arabic Text

[Alexandre Rafalovitch]

> Doc in Arabic with some English - English text is inverted (for example,
"gro.echapa.www"), what makes search by key words impossible.

What very specifically do you mean by that. How do you see the inversion?

If that's within some sort of web ui, then you are probably seeing the HTML
bidi (bidirectional LTR/RTL) presentation issues.

And if you are seeing in in Cloudera UI, then the question may be for their
forum.

One way to test is to have English text in brackets "(www.apache.org)"
within Arabic flow. If you see again your issue but the brackets get weird
"((gro.", this is most likely a bidi presentation issue with algorithm
or HTML attribute set to RTL.

Could be something else though, but that would be a start point.

Regards,
Alex


On Mon., Sep. 7, 2020, 5:54 a.m. ,  wrote:

> Hi,
>
> Could please help to resolve an issue. I upload/index several documents in
> English and in Arabic languages to SOLR, in addition I use handler for
> Arabic language:
>   
>
> 
>  words="stopwords.txt" enablePositionIncrements="true" />
>   class="solr.RemoveDuplicatesTokenFilterFactory"/>
>   class="solr.ArabicNormalizationFilterFactory"/>
> 
> 
>
>   
>   
> 
>  words="stopwords.txt" enablePositionIncrements="true" />
>  ignoreCase="true" expand="true"/>
>   class="solr.RemoveDuplicatesTokenFilterFactory"/>
>class="solr.ArabicNormalizationFilterFactory"/>
> 
> 
>
>   
>
> There are two environments:
> Local machine: - SOLR version: 4,2
> - Windows version: 10
>
> DEV env: - SOLR version 4.1 as part of the cloudera suit
> - Linux core version: 3.10.0-862
>
> Issue appears when uploading documents:
> Local machine: - Doc in English with English words only -
> ok (for example, "www.apache.org")
> - Doc in Arabic with some English words - ok (for example,
> "www.apache.org")
>
> DEV env: - Doc in English with English words only - ok
> (for example, "www.apache.org")
> - Doc in Arabic with some English - English text is
> inverted (for example, "gro.echapa.www"), what makes search by key words
> impossible.
>
> Please advise whether this fixable and how?
>
> Thank you in advance!
>

Re: Inverse English an digits in Arabic Text

[Erick Erickson]

A quick test would be to send some simple queries by curl
rather than the browser, that’ll avoid any rendering issues.

Second, take a look at the admin 
UI>>pick_a_collection_from_the_dropdown>>analysis 
page and look at the terms in the field in question. Do they look “ok”?l You’re
looking at what’s actually indexed at that point. The Terms Component let’s
you look at the indexed terms more powerfully too:
https://lucene.apache.org/solr/guide/7_3/the-terms-component.html

Finally, since it’s OK in one environment and not in another, it’s very likely 
not
an issue with Solr itself, but something different about the environments, 
especially
the indexing process. I doubt it’s a difference between Solr 4.1 and 4.2…

Best,
Erick

> On Sep 7, 2020, at 7:10 AM, Alexandre Rafalovitch  wrote:
> 
>> Doc in Arabic with some English - English text is inverted (for example,
> "gro.echapa.www"), what makes search by key words impossible.
> 
> What very specifically do you mean by that. How do you see the inversion?
> 
> If that's within some sort of web ui, then you are probably seeing the HTML
> bidi (bidirectional LTR/RTL) presentation issues.
> 
> And if you are seeing in in Cloudera UI, then the question may be for their
> forum.
> 
> One way to test is to have English text in brackets "(www.apache.org)"
> within Arabic flow. If you see again your issue but the brackets get weird
> "((gro.", this is most likely a bidi presentation issue with algorithm
> or HTML attribute set to RTL.
> 
> Could be something else though, but that would be a start point.
> 
> Regards,
>Alex
> 
> 
> On Mon., Sep. 7, 2020, 5:54 a.m. ,  wrote:
> 
>> Hi,
>> 
>> Could please help to resolve an issue. I upload/index several documents in
>> English and in Arabic languages to SOLR, in addition I use handler for
>> Arabic language:
>>  
>>   
>>
>>> words="stopwords.txt" enablePositionIncrements="true" />
>> > class="solr.RemoveDuplicatesTokenFilterFactory"/>
>> > class="solr.ArabicNormalizationFilterFactory"/>
>>
>>
>> 
>>  
>>  
>>
>>> words="stopwords.txt" enablePositionIncrements="true" />
>>> ignoreCase="true" expand="true"/>
>> > class="solr.RemoveDuplicatesTokenFilterFactory"/>
>>  > class="solr.ArabicNormalizationFilterFactory"/>
>>
>>
>> 
>>  
>> 
>> There are two environments:
>> Local machine: - SOLR version: 4,2
>>- Windows version: 10
>> 
>> DEV env: - SOLR version 4.1 as part of the cloudera suit
>>- Linux core version: 3.10.0-862
>> 
>> Issue appears when uploading documents:
>> Local machine: - Doc in English with English words only -
>> ok (for example, "www.apache.org")
>>- Doc in Arabic with some English words - ok (for example,
>> "www.apache.org")
>> 
>> DEV env: - Doc in English with English words only - ok
>> (for example, "www.apache.org")
>>- Doc in Arabic with some English - English text is
>> inverted (for example, "gro.echapa.www"), what makes search by key words
>> impossible.
>> 
>> Please advise whether this fixable and how?
>> 
>> Thank you in advance!
>> 

Re: Must specify either 'defaultFieldType' or declare one typeMapping as default

[Ronald R.]

Hi Alex,
Thanks for your detailed explanation, it's much appreciated. I think
you're right though and I need to take a step back.
I really want to learn but for some reason it seems like something I
just can't get any control over.
I'll give your presentation a go and look for something that covers
the included examples after.

Kind regards,
Ronald.

On Sun, Sep 6, 2020 at 3:52 AM Alexandre Rafalovitch  wrote:
>
> That's a really hard way to get introduced to Solr. What about
> downloading Solr and running one of the built-in examples? Because you
> are figuring out so many variables at once.
>
> Either way, your specific issue is not in schema.xml (which should be
> converted to managed-schema on first run, btw, don't have both in the
> same directory).
>
> Your issue is in the solrconfig.xml and it is complaining about
> schemaless mode missing the default type mapping for when no other
> rules match. As explained at:
> https://lucene.apache.org/solr/8_6_0/solr-core/org/apache/solr/update/processor/AddSchemaFieldsUpdateProcessorFactory.html
>
> In your linked example, that's the line:
> strings
>
> In latest Solr, it is using the default flag instead, so maybe you
> ended up not having either. I think the example basically skips all
> the mapping and creates all fields automatically of type strings. So,
> you can probably remove all processors apart from add-schema-field in
> updateRequestProcessorChain definition and reintroduce the
> defaultFieldType from original example.
>
> Hope that gets you where you want. If it does not, don't give up on
> Solr, just step back a bit and get it working by itself first. Maybe
> try following my presentation from a while ago:
> https://www.slideshare.net/arafalov/from-content-to-search-speeddating-apache-solr-apachecon-2018-116330553
> , the associated Github repo is at:
> https://github.com/arafalov/solr-apachecon2018-presentation
>
> Regards,
>Alex.
>
>
> On Sat, 5 Sep 2020 at 20:32, Ronald Roeleveld
>  wrote:
> >
> > Hi there,
> > I'm a totally newb when it comes to Solr, I'm just trying to learn and
> > teach myself new skills so please bear with me.
> >
> > I'm following a tutorial online:
> > https://lobster1234.github.io/2017/08/14/search-with-nutch-mongodb-solr/
> >
> > Since this tutorial is somewhat outdated I've changed some things to
> > use current versions which is why I'm now running into issues.
> > In order to solve any issues I've searched online and mostly solved
> > everything with bits and pieces here and there. This part I can't seem
> > to solve though.
> >
> > I've added a schema.xml and changed the solrconfig.xml as described in
> > the tutorial and while Solr does start it gives me the following error
> > message:
> >
> > mycol1: 
> > org.apache.solr.common.SolrException:org.apache.solr.common.SolrException:
> > Must specify either 'defaultFieldType' or declare one typeMapping as
> > default.
> >
> > I've had errors before related to outdated lines in schema.xml but I
> > was able to fix those (I think).
> >
> > This is my current schema.xml
> >
> > -
> > 
> > 
> >  > required="true" multiValued="false" />
> > 
> >  > multiValued="true"/>
> > 
> > 
> > 
> >  > docValues="false" />
> >  > stored="false" multiValued="true"/>
> > id
> >  > docValues="true" />
> > 
> >  > positionIncrementGap="100" multiValued="true">
> >   
> > 
> >  > words="stopwords.txt" />
> > 
> > 
> >   
> >   
> > 
> >  > words="stopwords.txt" />
> >  > synonyms="synonyms.txt" ignoreCase="true" expand="true"/>
> > 
> >   
> > 
> >  > sortMissingLast="true" multiValued="true"/>
> >  > docValues="true" multiValued="true"/>
> >  > docValues="true" multiValued="true"/>
> >  > docValues="true" multiValued="true"/>
> > 
> >
> > --
> >
> > I hope someone is able to get me started with this. I'd like to learn
> > but it feels like a really steep hill to climb.
> >
> > Kind regards,
> > Ronald.

Re: Error on searches containing specific character pattern

[Andy @ BlueFusion]

Thanks David, I'll set up  the techproducts schema and see what happens.

Kind regards,

Andy

On 4/09/20 4:09 pm, David Smiley wrote:

Hi,

I looked at the code at those line numbers and it seems simply impossible
that an ArrayIndexOutOfBoundsException could be thrown there because it's
guarded by a condition ensuring the array is of length 1.
https://github.com/apache/lucene-solr/blob/2752d50dd1dcf758a32dc573d02967612a2cf1ff/lucene/core/src/java/org/apache/lucene/util/QueryBuilder.java#L653

If you can reproduce this with the "techproducts" schema, please share the
complete query.  If there's a problem here, I suspect the synonyms you have
may be pertinent.

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Tue, Sep 1, 2020 at 11:50 PM Andy @ BlueFusion 
wrote:


Hi All,

I have an 8.6.0 instance that is working well with one exception.

It returns an error when the search term follows a pattern of numbers &
alpha characters such as:

   * 1a1 aa
   * 1a1 1aa
   * 1a1 11

Similar patterns that don't error

   * 1a1 a
   * 1a1 1
   * 1a11 aa
   * 11a1 aa
   * 1a1aa
   * 11a11 aa

The error is:

|"trace":"java.lang.ArrayIndexOutOfBoundsException: 0\n\t at
org.apache.lucene.util.QueryBuilder.newSynonymQuery(QueryBuilder.java:653)\n\t

at
org.apache.solr.parser.SolrQueryParserBase.newSynonymQuery(SolrQueryParserBase.java:617)\n\t

at
org.apache.lucene.util.QueryBuilder.analyzeGraphBoolean(QueryBuilder.java:533)\n\t

at
org.apache.lucene.util.QueryBuilder.createFieldQuery(QueryBuilder.java:320)\n\t

at
org.apache.lucene.util.QueryBuilder.createFieldQuery(QueryBuilder.java:240)\n\t

at
org.apache.solr.parser.SolrQueryParserBase.newFieldQuery(SolrQueryParserBase.java:524)\n\t

at
org.apache.solr.parser.QueryParser.newFieldQuery(QueryParser.java:62)\n\t
at
org.apache.solr.parser.SolrQueryParserBase.getFieldQuery(SolrQueryParserBase.java:1122)\n\t

at
org.apache.solr.parser.QueryParser.MultiTerm(QueryParser.java:593)\n\t
at org.apache.solr.parser.QueryParser.Query(QueryParser.java:142)\n\t at
org.apache.solr.parser.QueryParser.Clause(QueryParser.java:282)\n\t at
org.apache.solr.parser.QueryParser.Query(QueryParser.java:162)\n\t at
org.apache.solr.parser.QueryParser.Clause(QueryParser.java:282)\n\t at
org.apache.solr.parser.QueryParser.Query(QueryParser.java:162)\n\t at
org.apache.solr.parser.QueryParser.Clause(QueryParser.java:282)\n\t at
org.apache.solr.parser.QueryParser.Query(QueryParser.java:162)\n\t at
org.apache.solr.parser.QueryParser.TopLevelQuery(QueryParser.java:131)\n\t
at
org.apache.solr.parser.SolrQueryParserBase.parse(SolrQueryParserBase.java:260)\n\t

at org.apache.solr.search.LuceneQParser.parse(LuceneQParser.java:49)\n\t
at org.apache.solr.search.QParser.getQuery(QParser.java:174)\n\t at
org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:160)\n\t

at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:302)\n\t

at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:211)\n\t

at org.apache.solr.core.SolrCore.execute(SolrCore.java:2596)\n\t at
org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:799)\n\t
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:578)\n\t
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:419)\n\t

at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:351)\n\t

at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)\n\t

at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)\n\t

at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\t

at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\t

at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\t

at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\t

at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1711)\n\t

at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\t

at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1347)\n\t

at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\t

at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)\n\t

at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1678)\n\t

at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\t

at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1249)\n\t

at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\t

at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)\n\t

at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:152)\n\t

at
org.ec