I have an OpenLDAP installation and I need to find an entry, from my custom schema extension, based on a DN value.
To be more specific I have an attribute (certSubjectDN) added to one of my custom classes that contains a DN which is used for certificate based authentication on a web server using smart cards (PKI auth). From what I understand a filtered search with substring matching against Active Directory, e.g. (certSubjectDN=CN=lastname.firstname*), will match against any entry where the value of certSubjectDN begins with 'CN=lastname.firstname'. This does not work with OpenLDAP.
I have attempted to add a matching rule to the attribute, SUBSTR caseIgnoreSubstringsMatch, but OpenLDAP refuses to accept that change, presumably because it is strictly following the LDAP specifications.
Can someone think of a way that I can perform such a substring match against an attribute of the DN type within OpenLDAP? Or should I just change that attribute to be a Directory String?
Thanks,
Chris
I am not an OpenLDAP expert, but I think you are on the right path. The DN syntax does not allow substring matching. The string syntax does.
If this fails, I would try to define a custom attribute with string syntax and the appropriate substring matching rule.
I hope this helps.
Related
If I may have missed this in some other area of SO please redirect me but I don't think this is a duped question.
I am using Azure Search with an index field called Title which is searchable and filterable using a Standard Lucerne Analyzer.
When using the built-in explorer, if I want to return all Job Titles that are explicitly named Full Stack Developer I can achieve it this way:
$filter=Title eq 'Full Stack Developer'&$count=true
But if I want to retrieve all the Job Titles using a wildcard to return all records having Full Stack in the name this way:
$filter=Title eq 'Full Stack*'&$count=true
The first 20 or so records returned are spot on, but after that point I get a mix of records that have absolutely nothing in common with the Title I specified in the query. My initial assumption was that perhaps Azure was including my specified Title performing an inclusive keyword search on the text as well.
Though I found a few instances where that hypothesis seemed to prove out, so many more of the records returned invalidated that altogether.
Maybe I don't understand fully the mechanics under the hood of Azure Search and so though my query appears to be valid; my expectation of the result is way off.
So how should my query look to perform a wildcard resulting to guarantee the words specified in the search to be included in the Titles returned, if this should be possible? And what would be the correct syntax to condition the return to accommodate for OR operators to be inclusive?
Azure Cognitive Search allows you to perform wildcard searches limited to specific fields only. To do so, you will need to specify the name of the fields in which you want to perform the search in searchFields parameter.
Your search URL in this case would be something like:
https://accountname.search.windows.net/indexes/indexname/docs?api-version=2020-06-30&searchFields=Title&search=Full Stack*
From the link here:
Does anyone know how to ensure we can return normal result as well as accented result set via the azure search filter. For e.g the below filter query in Azure search returns a name called unicorn when i check for record with name unicorn.
var result= searchServiceClient.Documents.SearchAsync<myDto>("*",new SearchParameters
{
SearchFields = new List<string> {"Name"},
Filter = "Name eq 'unicorn'"
});
This is all good but what i want is i want to write a filter such that it returns record named unicorn as well as record named únicorn (please note the first accented character) provided that both record exist.
This can be achieved when searching for such name via the search query using language or Standard ASCII folding search analyzer as mentioned in this link. What i am struggling to find out is how can we implement the same with azure filters?
Please let me know if anyone has got any solutions around this.
Filters are applied on the non-analyzed representation of the data, so I don’t think there’s any way to do any type of linguistic analysis on filters. One way to work around this is to manually create a field which only do lowercasing + asciifloding (no tokenization) and then search lucene queries that look like this:
"normal search query terms" AND customFilterColumn:"filtérValuèWithÄccents"
Basically the document would both need to match the search terms in any field AND also match the filter term in the “customFilterColumn”. This may not be sufficient for your needs, but at least you understand the art of the possible.
Using filters it won't work unless you specify in advance all the possibilities:
for example:
$filter=name eq 'unicorn' or name eq 'únicorn'
You'd better work with a different analyzer that will change accents to it's root form. As another possibility, you can try fuzzy search:
search=unicorn~&highlight=Name
Is there a way I can do a wildcard search for MRN numbers in FHIR?
ex. I want to search for all MRN numbers starting with 12345.
thanks,
Suresh
I think this is actually a bit trickier than it may seem within the fhir standard.
For general text/string searching, your best bet would be the :contains modifier in your query parameters. For example:
[base]/Patient?given:contains=ada
should return a Bundle containing all Patient resources with the string 'ada' (case and accent insensitive) in the given name. However, MRN's are typically stored as Patient.identifier, which is a token parameter. The specification states:
"A token type is a parameter that provides an exact match search, either on a string of characters, potentially scoped by a URI. It is mostly used against a code or identifier data type where the value may have a URI that scopes its meaning, where the search is performed against the pair from a Coding or an Identifier. Tokens are also used against other fields where exact matches are required"
https://www.hl7.org/fhir/search.html#token
However, the specification also provides the :text modifier for token parameters, of which it states:
"For token: :text (the match does a partial searches on the text portion of a CodeableConcept or the display portion of a Coding), instead of the default search which uses codes."
This seems to suggest that you could perform your search with something like:
[base]/Patient?identifier:text=12345
...however the standard ALSO states that "only a few servers are expected to offer this facility." So you may be out of luck unless the server you are querying against has implemented this functionality.
I am using Solr 6.0.0
I am using data-driven-configuration for my configuration related purpose. Most of the configuration is standard.
I have a document in Solr with
name:"aquickbrownfox"
Now if I do a fuzzy search like:
name:aquickbrownfo~0.7
OR
name:aquickbrownf~0.7
It lists out the record in the results.
But if I do a search like:
name:aquickbrown~0.7
It does not list the record.
Does it have to do something with the maxEdits in solrconfig.xml which is set to 2 ?
I tried increasing it. But I could not create a collection with this configuration. It gave an error:
ERROR: Error CREATEing SolrCore 'my-search': Unable to create core
[my-search] Caused by: Invalid maxEdits
Max 2 Edits seems to be a serious limitation. I wonder what is the use of passing the fractional value after the ~ operator.
My Usecase:
I have a contact database. I am supposed to detect the duplicates based on three parameters : Name, Email and Phone. So I rely on Solr for Fuzzy search. Email and Phone are relatively easy to work with simple assumptions. Name seems to be a bit tricky. For each word in the Name, I plan to do a fuzzy search. I expected the optional parameter after ~ to work without the maxEdit distance limitation.
The documentation no longer suggests using a fractional value after the tilde - see http://lucene.apache.org/core/4_6_0/queryparser/org/apache/lucene/queryparser/classic/package-summary.html#Fuzzy_Searches for more information.
However, you are correct that only 2 changes are allowed to be made to the search string in order to carry out a fuzzy search. I would guess this limitation strikes a balance between efficiency and usefulness.
The maxEdits parameter in solrconfig.xml applies to the DirectSpellChecker configuration, and doesn't affect your searching, unless you're using the spell checker.
For your use case, your best approach may be to index the name field twice, using different field configurations: one using a simple set of analyzers and filters (ie. StandardTokenizerFactory, StandardFilterFactory, LowerCaseFilterFactory), and the other using a phonetic matcher such as the Beider-Morse filter. You can use the first field to carry out fuzzy searches, and the second version to look for names which may be spelled differently but sound the same as the name being checked.
Name of the column in document library is :
Column name => Keywords (Sub-Processes, Methodology, Servicing Model, etc)
Column Type=> Multiple lines of text
We are using the above column name in the caml query as below
query.Query = "<Where><Eq><FieldRef Name='Keywords(Sub-Processes,Methodology,Servicing Model, etc)'/><Value Type='Text'>Merchant Services,Merchant Set Up</Value></Eq></Where>";
but when we run the code we get the exception:
Microsoft.SharePoint.SPException: One or more field types are not
installed properly. Go to the list settings page to delete these
fields.
Is this exception because of special characters used in the column name if yes then how can I correct it.
We can't change the column name because it is requirement.
Internal names and display names are quite different from each other. They can be the same in some cases but not all. There is generally an escape sequence in between two words with a space.
It is often a good practice to retrieve the internal name at runtime rather than hardcoding it.
Here's how to do it:
var internalName=list.Fields.GetFieldByInternalName(column.ColumnName).Title;
I can tell you for sure (given the special characters) that that's not the internal name of the field. It might be the display name, but it's not the internal name.
The error is because there is no field with an internal name of what you have provided.
Personally, when I want to find the internal name of a field I go to the list settings for the list and edit the column. When doing so there will be a query parameter with 'field=' followed by the internal name. There are other places that it can be found, and other sharepoint tools (SharePoint Manager was mentioned by another poster) that can be used to get such information.
I used "Keywords_x0020_x002f_x0020_Folksnomy" and it worked for me.
I fetched all the columns of the Document library and bind it to the GridView,in GridView I found this name.
Display Column name => Keywords (Sub-Processes, Methodology, Servicing Model, etc)
Wrong one is =>
Keywords_x0020_(Sub-Processes,_x0020_Methodology,_x0020_Servicing_x0020_Model,_x0020_etc)
Newly found correct name is => Keywords_x0020_x002f_x0020_Folksnomy