Return-Path: X-Original-To: apmail-incubator-connectors-user-archive@minotaur.apache.org Delivered-To: apmail-incubator-connectors-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 98E553EAB for ; Mon, 2 May 2011 19:44:54 +0000 (UTC) Received: (qmail 75931 invoked by uid 500); 2 May 2011 19:44:54 -0000 Delivered-To: apmail-incubator-connectors-user-archive@incubator.apache.org Received: (qmail 75892 invoked by uid 500); 2 May 2011 19:44:54 -0000 Mailing-List: contact connectors-user-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: connectors-user@incubator.apache.org Delivered-To: mailing list connectors-user@incubator.apache.org Received: (qmail 75883 invoked by uid 99); 2 May 2011 19:44:54 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 May 2011 19:44:54 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,NORMAL_HTTP_TO_IP,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of daddywri@gmail.com designates 209.85.216.182 as permitted sender) Received: from [209.85.216.182] (HELO mail-qy0-f182.google.com) (209.85.216.182) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 May 2011 19:44:47 +0000 Received: by qyk27 with SMTP id 27so3955571qyk.6 for ; Mon, 02 May 2011 12:44:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=pCrU6dohDdohfKL4ORN3kB2A8OVPyD1Fl5h65xZIHy8=; b=MnPiwdlaK/FzTSP6cjhapOFFVGIDzTyma7DktAedv6tWQr1BRd9cI+gCH8VqyZPg4a PL+LeeOq+x8lkCkep7q99/pUH9NZweRgTarlyBZEJ3xwx6uWRzDzQHnXwn3ZQDX2ZcsV tDeYtxpXBOejuEMEByT8DTfHMyATE9MR+bxwU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=YehQ434NqucsEIP4hXewryGiw9V/QCi0WJtY3sdKtXr6Dr3tBGa6wzVJthpJXYh4Mm vdZA4glTLSS/fVyfdH8CKsWtWE5hW1wF+WyYg2dMBXbBTY+IA001VzxVUhenjJi/s/vz AC8h8LHnumIyvFzA4v9+Ai9vTFYWFgvtcVVdg= MIME-Version: 1.0 Received: by 10.229.49.140 with SMTP id v12mr6612949qcf.80.1304365466562; Mon, 02 May 2011 12:44:26 -0700 (PDT) Received: by 10.229.79.75 with HTTP; Mon, 2 May 2011 12:44:26 -0700 (PDT) In-Reply-To: References: Date: Mon, 2 May 2011 15:44:26 -0400 Message-ID: Subject: Re: Which version of Solr have implements the Document Level Access Control From: Karl Wright To: connectors-user@incubator.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org "NameNotFound exception is never being reached because process is throwing internal exception, and this is never checked." I see the logging trace; it looks like the ldap code is eating the exception and returning a blank list. This is explicitly NOT what is supposed to happen, nor did it happen on JDK 1.5, I am certain. You might find that this behavior has changed between Java releases. "Also, what is the reason for adding everyone group for each response ?" I added this in because the standard treatment of Active Directory 2000 and 2003 was to exclude the public ACL. Since all users have it, if the user exists (which was the case if NameNotFound exception was not being thrown), it was always safe to add it in. If JDK xxx, which is eating the internal exception, gives back SOME signal that the user does not exist, we can certainly check for that. What signal do you recommend looking for, based on the trace? Is there any way to get at "errEx PartialResultException (id=3D7962) " from NamingEnumeration answer? Karl On Mon, May 2, 2011 at 3:31 PM, Kadri Atalay wrote= : > Hi Karl, > > I noticed in the code that =A0 NameNotFound exception is never being reac= hed > because process is throwing internal exception, and this is never checked= . > (see below) > Also, what is the reason for adding everyone group for each response ? > =A0=A0=A0=A0=A0 theGroups.add("S-1-1-0"); > > When there is no groups or SID's returned, following return code is still > used.. > =A0=A0=A0=A0=A0 return new > AuthorizationResponse(tokens,AuthorizationResponse.RESPONSE_OK); > > Should I assume this code was tested against an Active Directory, and > working, and or should I start checking from the beginning every paramete= r > is entered. (see below) > For example, in the following code, DIGEST-MD5 GSSAPI is used for securit= y > authentication, but user name and password is passed as a clear text.. an= d > not in the format they suggest in their documentation. > > Thanks > > Kadri > > http://download.oracle.com/javase/jndi/tutorial/ldap/security/gssapi.html > > > =A0=A0=A0 if (ctx =3D=3D null) > =A0=A0=A0 { > =A0=A0=A0=A0=A0 // Calculate the ldap url first > =A0=A0=A0=A0=A0 String ldapURL =3D "ldap://" + domainControllerName + ":3= 89"; > > =A0=A0=A0=A0=A0 Hashtable env =3D new Hashtable(); > > env.put(Context.INITIAL_CONTEXT_FACTORY,"com.sun.jndi.ldap.LdapCtxFactory= "); > =A0=A0=A0=A0=A0 env.put(Context.SECURITY_AUTHENTICATION,"DIGEST-MD5 GSSAP= I"); > =A0=A0=A0=A0=A0 env.put(Context.SECURITY_PRINCIPAL,userName); > =A0=A0=A0=A0=A0 env.put(Context.SECURITY_CREDENTIALS,password); > > =A0=A0=A0=A0=A0 //connect to my domain controller > =A0=A0=A0=A0=A0 env.put(Context.PROVIDER_URL,ldapURL); > > =A0=A0=A0=A0=A0 //specify attributes to be returned in binary format > =A0=A0=A0=A0=A0 env.put("java.naming.ldap.attributes.binary","tokenGroups= objectSid"); > > > > fakeuser@teqa > > =A0=A0=A0 //Search for objects using the filter > =A0=A0=A0=A0=A0 NamingEnumeration answer =3D ctx.search(searchBase, searc= hFilter, > searchCtls); > > answer=A0=A0=A0 LdapSearchEnumeration=A0 (id=3D6635) > =A0=A0=A0 cleaned=A0=A0=A0 false > =A0=A0=A0 cont=A0=A0=A0 Continuation=A0 (id=3D6674) > =A0=A0=A0 entries=A0=A0=A0 Vector=A0 (id=3D6675) > =A0=A0=A0 enumClnt=A0=A0=A0 LdapClient=A0 (id=3D6676) > =A0=A0=A0 =A0=A0=A0 authenticateCalled=A0=A0=A0 true > =A0=A0=A0 =A0=A0=A0 conn=A0=A0=A0 Connection=A0 (id=3D6906) > =A0=A0=A0 =A0=A0=A0 isLdapv3=A0=A0=A0 true > =A0=A0=A0 =A0=A0=A0 pcb=A0=A0=A0 null > =A0=A0=A0 =A0=A0=A0 pooled=A0=A0=A0 false > =A0=A0=A0 =A0=A0=A0 referenceCount=A0=A0=A0 1 > =A0=A0=A0 =A0=A0=A0 unsolicited=A0=A0=A0 Vector=A0 (id=3D6907) > =A0=A0=A0 errEx=A0=A0=A0 PartialResultException=A0 (id=3D6677) > =A0=A0=A0 =A0=A0=A0 cause=A0=A0=A0 PartialResultException=A0 (id=3D6677) > =A0=A0=A0 =A0=A0=A0 detailMessage=A0=A0=A0 "[LDAP: error code 10 - 000020= 2B: RefErr: > DSID-031006E0, data 0, 1 access points\n\tref 1: 'teqa'\n > > > =A0=A0=A0=A0=A0 ArrayList theGroups =3D new ArrayList(); > =A0=A0=A0=A0=A0 // All users get certain well-known groups > =A0=A0=A0=A0=A0 theGroups.add("S-1-1-0"); > > > answer=A0=A0=A0 LdapSearchEnumeration=A0 (id=3D7940) > =A0=A0=A0 cleaned=A0=A0=A0 false > =A0=A0=A0 cont=A0=A0=A0 Continuation=A0 (id=3D7959) > =A0=A0=A0 entries=A0=A0=A0 Vector=A0 (id=3D7960) > =A0=A0=A0 enumClnt=A0=A0=A0 LdapClient=A0 (id=3D7961) > =A0=A0=A0 errEx=A0=A0=A0 PartialResultException=A0 (id=3D7962) > =A0=A0=A0 =A0=A0=A0 cause=A0=A0=A0 PartialResultException=A0 (id=3D7962) > =A0=A0=A0 =A0=A0=A0 detailMessage=A0=A0=A0 "[LDAP: error code 10 - 000020= 2B: RefErr: > DSID-031006E0, data 0, 1 access points\n\tref 1: 'teqa'\n > > =A0=A0=A0=A0=A0 return new > AuthorizationResponse(tokens,AuthorizationResponse.RESPONSE_OK); > > > On Tue, Apr 26, 2011 at 12:54 PM, Karl Wright wrote: >> >> If a completely unknown user still comes back as existing, then it's >> time to look at how your domain controller is configured. >> Specifically, what do you have it configured to trust? =A0What version >> of Windows is this? >> >> The way LDAP tells you a user does not exist in Java is by an >> exception. =A0So this statement: >> >> =A0 =A0 =A0NamingEnumeration answer =3D ctx.search(searchBase, searchFil= ter, >> searchCtls); >> >> will throw the NameNotFoundException if the name doesn't exist, which >> the Active Directory connector then catches: >> >> =A0 =A0catch (NameNotFoundException e) >> =A0 =A0{ >> =A0 =A0 =A0// This means that the user doesn't exist >> =A0 =A0 =A0return userNotFoundResponse; >> =A0 =A0} >> >> Clearly this is not working at all for your setup. =A0Maybe you can look >> at the DC's event logs, and see what kinds of decisions it is making >> here? =A0It's not making much sense to me at this point. >> >> Karl >> >> On Tue, Apr 26, 2011 at 12:45 PM, Kadri Atalay >> wrote: >> > Get the same result with user doesn't exist >> > C:\OPT\security_example>curl >> > >> > "http://localhost:8345/mcf-authority-service/UserACLs?username=3Dfakeu= ser@fakedomain" >> > AUTHORIZED:TEQA-DC >> > TOKEN:TEQA-DC:S-1-1-0 >> > >> > BTW, is there a command to get all users available in Active Directory= , >> > from >> > mcf-authority service, or other test commands to see if it's working >> > correctly ? >> > >> > Also, I set the logging level to finest from Solr Admin for >> > ManifoldCFSecurityFilter,but I don't see any logs created.. Is there a= ny >> > other settings need to be tweaked ? >> > >> > Thanks >> > >> > Kadri >> > >> > On Tue, Apr 26, 2011 at 12:38 PM, Karl Wright >> > wrote: >> >> >> >> One other quick note. =A0You might want to try a user that doesn't ex= ist >> >> and see what you get. =A0It should be a USERNOTFOUND response. >> >> >> >> If that's indeed what you get back, then this is a relatively minor >> >> issue with Active Directory. =A0Basically the S-1-1-0 SID is added by >> >> the active directory authority, so the DC is actually returning an >> >> empty list of SIDs for the user with an unknown domain. =A0It *should= * >> >> tell us the user doesn't exist, I agree, but that's clearly a problem >> >> only Active Directory can solve; we can't make that decision in the >> >> active directory connector because the DC may be just one node in a >> >> hierarchy. =A0Perhaps there's a Microsoft knowledge-base article that >> >> would clarify things further. >> >> >> >> Please let me know what you find. >> >> Karl >> >> >> >> On Tue, Apr 26, 2011 at 12:27 PM, Karl Wright >> >> wrote: >> >> > The method code from the Active Directory authority that handles th= e >> >> > LDAP query construction is below. =A0It looks perfectly reasonable = to >> >> > me: >> >> > >> >> > =A0/** Parse a user name into an ldap search base. */ >> >> > =A0protected static String parseUser(String userName) >> >> > =A0 =A0throws ManifoldCFException >> >> > =A0{ >> >> > =A0 =A0//String searchBase =3D >> >> > "CN=3DAdministrator,CN=3DUsers,DC=3Dqa-ad-76,DC=3Dmetacarta,DC=3Dco= m"; >> >> > =A0 =A0int index =3D userName.indexOf("@"); >> >> > =A0 =A0if (index =3D=3D -1) >> >> > =A0 =A0 =A0throw new ManifoldCFException("Username is in unexpected= form >> >> > (no @): '"+userName+"'"); >> >> > =A0 =A0String userPart =3D userName.substring(0,index); >> >> > =A0 =A0String domainPart =3D userName.substring(index+1); >> >> > =A0 =A0// Start the search base assembly >> >> > =A0 =A0StringBuffer sb =3D new StringBuffer(); >> >> > =A0 =A0sb.append("CN=3D").append(userPart).append(",CN=3DUsers"); >> >> > =A0 =A0int j =3D 0; >> >> > =A0 =A0while (true) >> >> > =A0 =A0{ >> >> > =A0 =A0 =A0int k =3D domainPart.indexOf(".",j); >> >> > =A0 =A0 =A0if (k =3D=3D -1) >> >> > =A0 =A0 =A0{ >> >> > =A0 =A0 =A0 =A0sb.append(",DC=3D").append(domainPart.substring(j)); >> >> > =A0 =A0 =A0 =A0break; >> >> > =A0 =A0 =A0} >> >> > =A0 =A0 =A0sb.append(",DC=3D").append(domainPart.substring(j,k)); >> >> > =A0 =A0 =A0j =3D k+1; >> >> > =A0 =A0} >> >> > =A0 =A0return sb.toString(); >> >> > =A0} >> >> > >> >> > So I have to conclude that your Active Directory domain controller = is >> >> > simply not caring what the DC=3D fields are, for some reason. =A0No= idea >> >> > why. >> >> > >> >> > If you want to confirm this picture, you might want to create a pat= ch >> >> > to add some Logging.authorityConnectors.debug statements at >> >> > appropriate places so we can see the actual query it's sending to >> >> > LDAP. =A0I'm happy to commit this debug output patch eventually if = you >> >> > also want to create a ticket. >> >> > >> >> > Thanks, >> >> > Karl >> >> > >> >> > On Tue, Apr 26, 2011 at 12:17 PM, Kadri Atalay >> >> > >> >> > wrote: >> >> >> Yes, ManifoldCF is running with JCIFS connector, and using Solr 3.= 1 >> >> >> >> >> >> response to first call: >> >> >> C:\OPT\security_example>curl >> >> >> "http://localhost:8345/mcf-authority-service/UserACLs?username=3Dj= oe" >> >> >> UNREACHABLEAUTHORITY:TEQA-DC >> >> >> TOKEN:TEQA-DC:DEAD_AUTHORITY >> >> >> >> >> >> response to fake domain call: >> >> >> C:\OPT\security_example>curl >> >> >> >> >> >> >> >> >> "http://localhost:8345/mcf-authority-service/UserACLs?username=3Dj= oe@fakedomain" >> >> >> AUTHORIZED:TEQA-DC >> >> >> TOKEN:TEQA-DC:S-1-1-0 >> >> >> >> >> >> response to actual domain account call: >> >> >> C:\OPT\security_example>curl >> >> >> >> >> >> >> >> >> "http://localhost:8345/mcf-authority-service/UserACLs?username=3Dk= atalay_admin@teqa" >> >> >> AUTHORIZED:TEQA-DC >> >> >> TOKEN:TEQA-DC:S-1-1-0 >> >> >> >> >> >> Looks like as long as there is a domain suffix, return is positive= .. >> >> >> >> >> >> Thanks >> >> >> >> >> >> Kadri >> >> >> >> >> >> >> >> >> On Tue, Apr 26, 2011 at 12:10 PM, Karl Wright >> >> >> wrote: >> >> >>> >> >> >>> So you are trying to extend the example in the book, correct, to >> >> >>> run >> >> >>> against active directory and the JCIFS connector? =A0And this is = with >> >> >>> Solr 3.1? >> >> >>> >> >> >>> The book was written for Solr 1.4.1, so it's entirely possible th= at >> >> >>> something in Solr changed in relation to the way search component= s >> >> >>> are >> >> >>> used. =A0So I think we're going to need to do some debugging. >> >> >>> >> >> >>> (1) First, to confirm sanity, try using curl against the mcf >> >> >>> authority >> >> >>> service. =A0Try some combination of users to see how that works, >> >> >>> e.g.: >> >> >>> >> >> >>> curl >> >> >>> "http://localhost:8345/mcf-authority-service/UserACLs?username=3D= joe" >> >> >>> >> >> >>> ...and >> >> >>> >> >> >>> curl >> >> >>> >> >> >>> >> >> >>> "http://localhost:8345/mcf-authority-service/UserACLs?username=3D= joe@fakedomain" >> >> >>> >> >> >>> ...and also the real domain name, whatever that is. =A0See if the >> >> >>> access >> >> >>> tokens that come back look correct. =A0If they don't then we know >> >> >>> where >> >> >>> there's an issue. >> >> >>> >> >> >>> If they *are* correct, let me know and we'll go to the next stage= , >> >> >>> which would be to make sure the authority service is actually >> >> >>> getting >> >> >>> called and the proper query is being built and run under Solr 3.1= . >> >> >>> >> >> >>> Thanks, >> >> >>> Karl >> >> >>> >> >> >>> On Tue, Apr 26, 2011 at 11:59 AM, Kadri Atalay >> >> >>> >> >> >>> wrote: >> >> >>> > Hi Karl, >> >> >>> > >> >> >>> > I followed the instructions, and for testing purposes set >> >> >>> > "stored=3Dtrue" >> >> >>> > to >> >> >>> > be able to see the ACL values stored in Solr. >> >> >>> > >> >> >>> > But, when I run the search in following format I get peculiar >> >> >>> > results.. >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> > :http://10.1.200.155:8080/solr/select/?q=3D*%3A*&AuthenticatedU= serName=3Dusername >> >> >>> > >> >> >>> > Any user name without a domain name=A0 ie AuthenticatedUserName= =3Djoe >> >> >>> > does >> >> >>> > not >> >> >>> > return any results (which is correct) >> >> >>> > But any user name with ANY domain name returns all the indexes >> >> >>> > ie >> >> >>> > AuthenticatedUserName=3Djoe@fakedomain=A0=A0 (which is not corr= ect) >> >> >>> > >> >> >>> > Any thoughts ? >> >> >>> > >> >> >>> > Thanks >> >> >>> > >> >> >>> > Kadri >> >> >>> > >> >> >>> > On Sun, Apr 24, 2011 at 7:08 PM, Karl Wright >> >> >>> > wrote: >> >> >>> >> >> >> >>> >> Solr 3.1 is being clever here; it's seeing arguments coming in >> >> >>> >> that >> >> >>> >> do >> >> >>> >> not correspond to known schema fields, and presuming they are >> >> >>> >> "automatic" fields. =A0So when the schema is unmodified, you s= ee >> >> >>> >> these >> >> >>> >> fields that Solr creates for you, with the attr_ prefix. =A0Th= ey >> >> >>> >> are >> >> >>> >> created as being "stored", which is not good for access tokens >> >> >>> >> since >> >> >>> >> then you will see them in the response. =A0I don't know if the= y >> >> >>> >> are >> >> >>> >> indexed or not, but I imagine not, which is also not good. >> >> >>> >> >> >> >>> >> So following the instructions is still the right thing to do, = I >> >> >>> >> would >> >> >>> >> say. >> >> >>> >> >> >> >>> >> Karl >> >> >>> >> >> >> >>> >> On Fri, Apr 22, 2011 at 3:24 PM, Kadri Atalay >> >> >>> >> >> >> >>> >> wrote: >> >> >>> >> > Hi Karl, >> >> >>> >> > >> >> >>> >> > There is one thing I noticed while following the example in >> >> >>> >> > chapter >> >> >>> >> > 4.: >> >> >>> >> > Prior to making any changes into the schema.xml, I was able = to >> >> >>> >> > see >> >> >>> >> > the >> >> >>> >> > following security information in query responses: >> >> >>> >> > ie: >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > - >> >> >>> >> > >> >> >>> >> > TEQA-DC:S-1-3-0 >> >> >>> >> > TEQA-DC:S-1-5-13 >> >> >>> >> > TEQA-DC:S-1-5-18 >> >> >>> >> > TEQA-DC:S-1-5-32-544 >> >> >>> >> > TEQA-DC:S-1-5-32-545 >> >> >>> >> > TEQA-DC:S-1-5-32-547 >> >> >>> >> > >> >> >>> >> > - >> >> >>> >> > >> >> >>> >> > TEQA-DC:S-1-1-0 >> >> >>> >> > TEQA-DC:S-1-5-2 >> >> >>> >> > - >> >> >>> >> > >> >> >>> >> > TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1480 >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > - >> >> >>> >> > >> >> >>> >> > - >> >> >>> >> > >> >> >>> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0A= utonomy ODBC Fetch Technical >> >> >>> >> > Brief >> >> >>> >> > 0506 >> >> >>> >> > Technical Brief >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > But, after I modified the schema/xml, and added the followin= g >> >> >>> >> > fields, >> >> >>> >> > =A0 =A0 >> >> >>> >> > =A0 =A0 > >> >>> >> > indexed=3D"true" >> >> >>> >> > stored=3D"false" multiValued=3D"true"/> >> >> >>> >> > =A0 =A0 > >> >>> >> > indexed=3D"true" >> >> >>> >> > stored=3D"false" multiValued=3D"true"/> >> >> >>> >> > =A0 =A0 > >> >>> >> > indexed=3D"true" >> >> >>> >> > stored=3D"false" multiValued=3D"true"/> >> >> >>> >> > =A0 =A0 > >> >>> >> > indexed=3D"true" >> >> >>> >> > stored=3D"false" multiValued=3D"true"/> >> >> >>> >> > >> >> >>> >> > I longer see neither the attr_allow_token_document =A0 or th= e >> >> >>> >> > allow_token_document fields.. >> >> >>> >> > >> >> >>> >> > Since same fields exist with attr_ =A0prefix, should we need= to >> >> >>> >> > add >> >> >>> >> > these >> >> >>> >> > new >> >> >>> >> > field names into the schema file, or can we simply change >> >> >>> >> > ManifoldSecurity >> >> >>> >> > to use attr_ fields ? >> >> >>> >> > >> >> >>> >> > Also, when Solr is running under Tomcat, I have to re-start >> >> >>> >> > the >> >> >>> >> > Solr >> >> >>> >> > App, or >> >> >>> >> > re-start Tomcat to see the newly added indexes.. >> >> >>> >> > >> >> >>> >> > Any thoughts ? >> >> >>> >> > >> >> >>> >> > Thanks >> >> >>> >> > >> >> >>> >> > Kadri >> >> >>> >> > >> >> >>> >> > On Fri, Apr 22, 2011 at 12:53 PM, Karl Wright >> >> >>> >> > >> >> >>> >> > wrote: >> >> >>> >> >> >> >> >>> >> >> I don't believe Solr has yet officially released document >> >> >>> >> >> access >> >> >>> >> >> control, so you will need to use the patch for ticket 1895. >> >> >>> >> >> Alternatively, the ManifoldCF in Action chapter 4 example h= as >> >> >>> >> >> an >> >> >>> >> >> implementation based on this ticket. =A0You can get the cod= e >> >> >>> >> >> for >> >> >>> >> >> it at >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> >> https://manifoldcfinaction.googlecode.com/svn/trunk/edition= _1/security_example. >> >> >>> >> >> >> >> >>> >> >> Thanks, >> >> >>> >> >> Karl >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> >> On Fri, Apr 22, 2011 at 11:45 AM, Kadri Atalay >> >> >>> >> >> >> >> >>> >> >> wrote: >> >> >>> >> >> > Hello, >> >> >>> >> >> > >> >> >>> >> >> > Does anyone know which version of Solr have implements th= e >> >> >>> >> >> > Document >> >> >>> >> >> > Level >> >> >>> >> >> > Access Control, or has it implemented (partially or fully= ) >> >> >>> >> >> > ? >> >> >>> >> >> > Particularly issue #s 1834, 1872, 1895 >> >> >>> >> >> > >> >> >>> >> >> > Thanks >> >> >>> >> >> > >> >> >>> >> >> > Kadri >> >> >>> >> >> > >> >> >>> >> > >> >> >>> >> > >> >> >>> > >> >> >>> > >> >> >> >> >> >> >> >> > >> > >> > > >