I removed the object scope from the user lookup - it's worth another try. Care to synch up an run again?
Karl On Tue, May 3, 2011 at 12:36 PM, Karl Wright <daddy...@gmail.com> wrote: > As I feared, the new user-exists-check code is not correct in some > way. Apparently we can't retrieve the attribute I'm looking for by > this kind of query. > > The following website seems to have some suggestions as to how to do > better, with downloadable samples, but I'm not going to be able to > look at it in any detail until this evening. > > http://www.techtalkz.com/windows-server-2003/424352-get-samaccountnames-all-users-active-directory-group.html > > Karl > > On Tue, May 3, 2011 at 12:12 PM, Kadri Atalay <atalay.ka...@gmail.com> wrote: >> Karl, >> >> Here is the first round of tests with CONNECTORS-195t: Now we are getting >> all responses as TEQA-DC:DEAD_AUTHORITY.. even with valid users. >> >> Please take a look at the 2 bitmap files I have attached. (they have the >> screen shots from debug screens) >> >> invalid user and invalid domain >> C:\OPT>curl >> "http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser@fakedomain"; >> USERNOTFOUND:TEQA-DC >> TOKEN:TEQA-DC:DEAD_AUTHORITY >> >> invalid user and valid (full domain name) >> C:\OPT>curl >> "http://localhost:8345/mcf-authority-service/UserACLs?username=fakeu...@teqa.filetek.com"; >> USERNOTFOUND:TEQA-DC >> TOKEN:TEQA-DC:DEAD_AUTHORITY >> >> valid user and valid domain (please see bitmap file katalay_ad...@teqa.bmp) >> This name gets the similar error as the first fakeuser eventhough it's a >> valid user. >> C:\OPT>curl >> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa"; >> USERNOTFOUND:TEQA-DC >> TOKEN:TEQA-DC:DEAD_AUTHORITY >> >> valid user and valid domain (full domain name) (please see bitmap file >> katalay_ad...@teqa.filetek.com.bmp) This name gets a namenotfound exception >> when full domain name is used. >> C:\OPT>curl >> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_ad...@teqa.filetek.com"; >> USERNOTFOUND:TEQA-DC >> TOKEN:TEQA-DC:DEAD_AUTHORITY >> >> valid user and valid domain (full domain name) >> C:\OPT>curl >> "http://localhost:8345/mcf-authority-service/UserACLs?username=kata...@teqa.filetek.com"; >> USERNOTFOUND:TEQA-DC >> TOKEN:TEQA-DC:DEAD_AUTHORITY >> >> Thanks >> >> Kadri >> >> On Tue, May 3, 2011 at 3:55 AM, Karl Wright <daddy...@gmail.com> wrote: >>> >>> Because this looks like it might involve some experimentation, I >>> decided to create a branch for working on the CONNECTORS-195 ticket. >>> The branch has what I believe is the correct code checked into it. >>> The branch svn root is: >>> >>> http://svn.apache.org/repos/asf/incubator/lcf/branches/CONNECTORS-195 >>> >>> If you check this branch out and build it, I'd dearly love to know if >>> it properly detects non-existent users on your system. In theory it >>> should. If it is wrong, it might well decide that ALL users are >>> invalid, so your feedback is essential before I consider committing >>> this patch. >>> >>> Thanks, >>> Karl >>> >>> On Mon, May 2, 2011 at 5:52 PM, Karl Wright <daddy...@gmail.com> wrote: >>> > I opened a ticket, CONNECTORS-195, and added what I think is an >>> > explicit check for existence of the user as a patch. Can you apply >>> > the patch and let me know if it seems to fix the problem? >>> > >>> > Thanks, >>> > Karl >>> > >>> > >>> > On Mon, May 2, 2011 at 3:51 PM, Kadri Atalay <atalay.ka...@gmail.com> >>> > wrote: >>> >> I see, thanks for the response. >>> >> I'll look into it little deeper, before making a suggestion how to >>> >> check for >>> >> this internal exception.. If JDK 1.6 behavior is different than JDK 1.5 >>> >> for >>> >> LDAP, this may not be the only problem we may encounter.. >>> >> Maybe any exception generated by JDK during this request should be >>> >> evaluated.. We'll see. >>> >> Thanks. >>> >> Kadri >>> >> >>> >> On Mon, May 2, 2011 at 3:44 PM, Karl Wright <daddy...@gmail.com> wrote: >>> >>> >>> >>> "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=7962) " >>> >>> from NamingEnumeration answer? >>> >>> >>> >>> Karl >>> >>> >>> >>> >>> >>> >>> >>> On Mon, May 2, 2011 at 3:31 PM, Kadri Atalay <atalay.ka...@gmail.com> >>> >>> wrote: >>> >>> > Hi Karl, >>> >>> > >>> >>> > I noticed in the code that NameNotFound exception is never being >>> >>> > reached >>> >>> > 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 >>> >>> > ? >>> >>> > theGroups.add("S-1-1-0"); >>> >>> > >>> >>> > When there is no groups or SID's returned, following return code is >>> >>> > still >>> >>> > used.. >>> >>> > 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 >>> >>> > parameter >>> >>> > is entered. (see below) >>> >>> > For example, in the following code, DIGEST-MD5 GSSAPI is used for >>> >>> > security >>> >>> > authentication, but user name and password is passed as a clear >>> >>> > text.. >>> >>> > and >>> >>> > not in the format they suggest in their documentation. >>> >>> > >>> >>> > Thanks >>> >>> > >>> >>> > Kadri >>> >>> > >>> >>> > >>> >>> > >>> >>> > http://download.oracle.com/javase/jndi/tutorial/ldap/security/gssapi.html >>> >>> > >>> >>> > >>> >>> > if (ctx == null) >>> >>> > { >>> >>> > // Calculate the ldap url first >>> >>> > String ldapURL = "ldap://"; + domainControllerName + ":389"; >>> >>> > >>> >>> > Hashtable env = new Hashtable(); >>> >>> > >>> >>> > >>> >>> > >>> >>> > env.put(Context.INITIAL_CONTEXT_FACTORY,"com.sun.jndi.ldap.LdapCtxFactory"); >>> >>> > env.put(Context.SECURITY_AUTHENTICATION,"DIGEST-MD5 GSSAPI"); >>> >>> > env.put(Context.SECURITY_PRINCIPAL,userName); >>> >>> > env.put(Context.SECURITY_CREDENTIALS,password); >>> >>> > >>> >>> > //connect to my domain controller >>> >>> > env.put(Context.PROVIDER_URL,ldapURL); >>> >>> > >>> >>> > //specify attributes to be returned in binary format >>> >>> > env.put("java.naming.ldap.attributes.binary","tokenGroups >>> >>> > objectSid"); >>> >>> > >>> >>> > >>> >>> > >>> >>> > fakeuser@teqa >>> >>> > >>> >>> > //Search for objects using the filter >>> >>> > NamingEnumeration answer = ctx.search(searchBase, >>> >>> > searchFilter, >>> >>> > searchCtls); >>> >>> > >>> >>> > answer LdapSearchEnumeration (id=6635) >>> >>> > cleaned false >>> >>> > cont Continuation (id=6674) >>> >>> > entries Vector<E> (id=6675) >>> >>> > enumClnt LdapClient (id=6676) >>> >>> > authenticateCalled true >>> >>> > conn Connection (id=6906) >>> >>> > isLdapv3 true >>> >>> > pcb null >>> >>> > pooled false >>> >>> > referenceCount 1 >>> >>> > unsolicited Vector<E> (id=6907) >>> >>> > errEx PartialResultException (id=6677) >>> >>> > cause PartialResultException (id=6677) >>> >>> > detailMessage "[LDAP: error code 10 - 0000202B: RefErr: >>> >>> > DSID-031006E0, data 0, 1 access points\n\tref 1: 'teqa'\n >>> >>> > >>> >>> > >>> >>> > ArrayList theGroups = new ArrayList(); >>> >>> > // All users get certain well-known groups >>> >>> > theGroups.add("S-1-1-0"); >>> >>> > >>> >>> > >>> >>> > answer LdapSearchEnumeration (id=7940) >>> >>> > cleaned false >>> >>> > cont Continuation (id=7959) >>> >>> > entries Vector<E> (id=7960) >>> >>> > enumClnt LdapClient (id=7961) >>> >>> > errEx PartialResultException (id=7962) >>> >>> > cause PartialResultException (id=7962) >>> >>> > detailMessage "[LDAP: error code 10 - 0000202B: RefErr: >>> >>> > DSID-031006E0, data 0, 1 access points\n\tref 1: 'teqa'\n >>> >>> > >>> >>> > return new >>> >>> > AuthorizationResponse(tokens,AuthorizationResponse.RESPONSE_OK); >>> >>> > >>> >>> > >>> >>> > On Tue, Apr 26, 2011 at 12:54 PM, Karl Wright <daddy...@gmail.com> >>> >>> > 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? What >>> >>> >> version >>> >>> >> of Windows is this? >>> >>> >> >>> >>> >> The way LDAP tells you a user does not exist in Java is by an >>> >>> >> exception. So this statement: >>> >>> >> >>> >>> >> NamingEnumeration answer = ctx.search(searchBase, >>> >>> >> searchFilter, >>> >>> >> searchCtls); >>> >>> >> >>> >>> >> will throw the NameNotFoundException if the name doesn't exist, >>> >>> >> which >>> >>> >> the Active Directory connector then catches: >>> >>> >> >>> >>> >> catch (NameNotFoundException e) >>> >>> >> { >>> >>> >> // This means that the user doesn't exist >>> >>> >> return userNotFoundResponse; >>> >>> >> } >>> >>> >> >>> >>> >> Clearly this is not working at all for your setup. Maybe you can >>> >>> >> look >>> >>> >> at the DC's event logs, and see what kinds of decisions it is >>> >>> >> making >>> >>> >> here? It's not making much sense to me at this point. >>> >>> >> >>> >>> >> Karl >>> >>> >> >>> >>> >> On Tue, Apr 26, 2011 at 12:45 PM, Kadri Atalay >>> >>> >> <atalay.ka...@gmail.com> >>> >>> >> wrote: >>> >>> >> > Get the same result with user doesn't exist >>> >>> >> > C:\OPT\security_example>curl >>> >>> >> > >>> >>> >> > >>> >>> >> > >>> >>> >> > "http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser@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 >>> >>> >> > any >>> >>> >> > other settings need to be tweaked ? >>> >>> >> > >>> >>> >> > Thanks >>> >>> >> > >>> >>> >> > Kadri >>> >>> >> > >>> >>> >> > On Tue, Apr 26, 2011 at 12:38 PM, Karl Wright >>> >>> >> > <daddy...@gmail.com> >>> >>> >> > wrote: >>> >>> >> >> >>> >>> >> >> One other quick note. You might want to try a user that doesn't >>> >>> >> >> exist >>> >>> >> >> and see what you get. It should be a USERNOTFOUND response. >>> >>> >> >> >>> >>> >> >> If that's indeed what you get back, then this is a relatively >>> >>> >> >> minor >>> >>> >> >> issue with Active Directory. Basically 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. It >>> >>> >> >> *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. Perhaps 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 >>> >>> >> >> <daddy...@gmail.com> >>> >>> >> >> wrote: >>> >>> >> >> > The method code from the Active Directory authority that >>> >>> >> >> > handles >>> >>> >> >> > the >>> >>> >> >> > LDAP query construction is below. It looks perfectly >>> >>> >> >> > reasonable >>> >>> >> >> > to >>> >>> >> >> > me: >>> >>> >> >> > >>> >>> >> >> > /** Parse a user name into an ldap search base. */ >>> >>> >> >> > protected static String parseUser(String userName) >>> >>> >> >> > throws ManifoldCFException >>> >>> >> >> > { >>> >>> >> >> > //String searchBase = >>> >>> >> >> > "CN=Administrator,CN=Users,DC=qa-ad-76,DC=metacarta,DC=com"; >>> >>> >> >> > int index = userName.indexOf("@"); >>> >>> >> >> > if (index == -1) >>> >>> >> >> > throw new ManifoldCFException("Username is in unexpected >>> >>> >> >> > form >>> >>> >> >> > (no @): '"+userName+"'"); >>> >>> >> >> > String userPart = userName.substring(0,index); >>> >>> >> >> > String domainPart = userName.substring(index+1); >>> >>> >> >> > // Start the search base assembly >>> >>> >> >> > StringBuffer sb = new StringBuffer(); >>> >>> >> >> > sb.append("CN=").append(userPart).append(",CN=Users"); >>> >>> >> >> > int j = 0; >>> >>> >> >> > while (true) >>> >>> >> >> > { >>> >>> >> >> > int k = domainPart.indexOf(".",j); >>> >>> >> >> > if (k == -1) >>> >>> >> >> > { >>> >>> >> >> > sb.append(",DC=").append(domainPart.substring(j)); >>> >>> >> >> > break; >>> >>> >> >> > } >>> >>> >> >> > sb.append(",DC=").append(domainPart.substring(j,k)); >>> >>> >> >> > j = k+1; >>> >>> >> >> > } >>> >>> >> >> > return sb.toString(); >>> >>> >> >> > } >>> >>> >> >> > >>> >>> >> >> > So I have to conclude that your Active Directory domain >>> >>> >> >> > controller >>> >>> >> >> > is >>> >>> >> >> > simply not caring what the DC= fields are, for some reason. >>> >>> >> >> > No >>> >>> >> >> > idea >>> >>> >> >> > why. >>> >>> >> >> > >>> >>> >> >> > If you want to confirm this picture, you might want to create >>> >>> >> >> > a >>> >>> >> >> > patch >>> >>> >> >> > to add some Logging.authorityConnectors.debug statements at >>> >>> >> >> > appropriate places so we can see the actual query it's sending >>> >>> >> >> > to >>> >>> >> >> > LDAP. I'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 >>> >>> >> >> > <atalay.ka...@gmail.com> >>> >>> >> >> > 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=joe"; >>> >>> >> >> >> 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=joe@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=katalay_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 >>> >>> >> >> >> <daddy...@gmail.com> >>> >>> >> >> >> wrote: >>> >>> >> >> >>> >>> >>> >> >> >>> So you are trying to extend the example in the book, >>> >>> >> >> >>> correct, to >>> >>> >> >> >>> run >>> >>> >> >> >>> against active directory and the JCIFS connector? And this >>> >>> >> >> >>> is >>> >>> >> >> >>> with >>> >>> >> >> >>> Solr 3.1? >>> >>> >> >> >>> >>> >>> >> >> >>> The book was written for Solr 1.4.1, so it's entirely >>> >>> >> >> >>> possible >>> >>> >> >> >>> that >>> >>> >> >> >>> something in Solr changed in relation to the way search >>> >>> >> >> >>> components >>> >>> >> >> >>> are >>> >>> >> >> >>> used. So I think we're going to need to do some debugging. >>> >>> >> >> >>> >>> >>> >> >> >>> (1) First, to confirm sanity, try using curl against the mcf >>> >>> >> >> >>> authority >>> >>> >> >> >>> service. Try some combination of users to see how that >>> >>> >> >> >>> works, >>> >>> >> >> >>> e.g.: >>> >>> >> >> >>> >>> >>> >> >> >>> curl >>> >>> >> >> >>> >>> >>> >> >> >>> >>> >>> >> >> >>> "http://localhost:8345/mcf-authority-service/UserACLs?username=joe"; >>> >>> >> >> >>> >>> >>> >> >> >>> ...and >>> >>> >> >> >>> >>> >>> >> >> >>> curl >>> >>> >> >> >>> >>> >>> >> >> >>> >>> >>> >> >> >>> >>> >>> >> >> >>> >>> >>> >> >> >>> "http://localhost:8345/mcf-authority-service/UserACLs?username=joe@fakedomain"; >>> >>> >> >> >>> >>> >>> >> >> >>> ...and also the real domain name, whatever that is. See if >>> >>> >> >> >>> the >>> >>> >> >> >>> access >>> >>> >> >> >>> tokens that come back look correct. If 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 >>> >>> >> >> >>> <atalay.ka...@gmail.com> >>> >>> >> >> >>> wrote: >>> >>> >> >> >>> > Hi Karl, >>> >>> >> >> >>> > >>> >>> >> >> >>> > I followed the instructions, and for testing purposes set >>> >>> >> >> >>> > "stored=true" >>> >>> >> >> >>> > 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=*%3A*&AuthenticatedUserName=username >>> >>> >> >> >>> > >>> >>> >> >> >>> > Any user name without a domain name ie >>> >>> >> >> >>> > AuthenticatedUserName=joe >>> >>> >> >> >>> > does >>> >>> >> >> >>> > not >>> >>> >> >> >>> > return any results (which is correct) >>> >>> >> >> >>> > But any user name with ANY domain name returns all the >>> >>> >> >> >>> > indexes >>> >>> >> >> >>> > ie >>> >>> >> >> >>> > AuthenticatedUserName=joe@fakedomain (which is not >>> >>> >> >> >>> > correct) >>> >>> >> >> >>> > >>> >>> >> >> >>> > Any thoughts ? >>> >>> >> >> >>> > >>> >>> >> >> >>> > Thanks >>> >>> >> >> >>> > >>> >>> >> >> >>> > Kadri >>> >>> >> >> >>> > >>> >>> >> >> >>> > On Sun, Apr 24, 2011 at 7:08 PM, Karl Wright >>> >>> >> >> >>> > <daddy...@gmail.com> >>> >>> >> >> >>> > 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. So when the schema is unmodified, >>> >>> >> >> >>> >> you >>> >>> >> >> >>> >> see >>> >>> >> >> >>> >> these >>> >>> >> >> >>> >> fields that Solr creates for you, with the attr_ prefix. >>> >>> >> >> >>> >> They >>> >>> >> >> >>> >> are >>> >>> >> >> >>> >> created as being "stored", which is not good for access >>> >>> >> >> >>> >> tokens >>> >>> >> >> >>> >> since >>> >>> >> >> >>> >> then you will see them in the response. I don't know if >>> >>> >> >> >>> >> they >>> >>> >> >> >>> >> 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 >>> >>> >> >> >>> >> <atalay.ka...@gmail.com> >>> >>> >> >> >>> >> 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: >>> >>> >> >> >>> >> > >>> >>> >> >> >>> >> > <doc> >>> >>> >> >> >>> >> > - >>> >>> >> >> >>> >> > <arr name="attr_allow_token_document"> >>> >>> >> >> >>> >> > <str>TEQA-DC:S-1-3-0</str> >>> >>> >> >> >>> >> > <str>TEQA-DC:S-1-5-13</str> >>> >>> >> >> >>> >> > <str>TEQA-DC:S-1-5-18</str> >>> >>> >> >> >>> >> > <str>TEQA-DC:S-1-5-32-544</str> >>> >>> >> >> >>> >> > <str>TEQA-DC:S-1-5-32-545</str> >>> >>> >> >> >>> >> > <str>TEQA-DC:S-1-5-32-547</str> >>> >>> >> >> >>> >> > </arr> >>> >>> >> >> >>> >> > - >>> >>> >> >> >>> >> > <arr name="attr_allow_token_share"> >>> >>> >> >> >>> >> > <str>TEQA-DC:S-1-1-0</str> >>> >>> >> >> >>> >> > <str>TEQA-DC:S-1-5-2</str> >>> >>> >> >> >>> >> > - >>> >>> >> >> >>> >> > <str> >>> >>> >> >> >>> >> > TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1480 >>> >>> >> >> >>> >> > </str> >>> >>> >> >> >>> >> > </arr> >>> >>> >> >> >>> >> > - >>> >>> >> >> >>> >> > <arr name="attr_content"> >>> >>> >> >> >>> >> > - >>> >>> >> >> >>> >> > <str> >>> >>> >> >> >>> >> > Autonomy ODBC Fetch >>> >>> >> >> >>> >> > Technical >>> >>> >> >> >>> >> > Brief >>> >>> >> >> >>> >> > 0506 >>> >>> >> >> >>> >> > Technical Brief >>> >>> >> >> >>> >> > >>> >>> >> >> >>> >> > >>> >>> >> >> >>> >> > But, after I modified the schema/xml, and added the >>> >>> >> >> >>> >> > following >>> >>> >> >> >>> >> > fields, >>> >>> >> >> >>> >> > <!-- Security fields --> >>> >>> >> >> >>> >> > <field name="allow_token_document" type="string" >>> >>> >> >> >>> >> > indexed="true" >>> >>> >> >> >>> >> > stored="false" multiValued="true"/> >>> >>> >> >> >>> >> > <field name="deny_token_document" type="string" >>> >>> >> >> >>> >> > indexed="true" >>> >>> >> >> >>> >> > stored="false" multiValued="true"/> >>> >>> >> >> >>> >> > <field name="allow_token_share" type="string" >>> >>> >> >> >>> >> > indexed="true" >>> >>> >> >> >>> >> > stored="false" multiValued="true"/> >>> >>> >> >> >>> >> > <field name="deny_token_share" type="string" >>> >>> >> >> >>> >> > indexed="true" >>> >>> >> >> >>> >> > stored="false" multiValued="true"/> >>> >>> >> >> >>> >> > >>> >>> >> >> >>> >> > I longer see neither the attr_allow_token_document or >>> >>> >> >> >>> >> > the >>> >>> >> >> >>> >> > allow_token_document fields.. >>> >>> >> >> >>> >> > >>> >>> >> >> >>> >> > Since same fields exist with attr_ prefix, 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 >>> >>> >> >> >>> >> > <daddy...@gmail.com> >>> >>> >> >> >>> >> > 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 >>> >>> >> >> >>> >> >> has >>> >>> >> >> >>> >> >> an >>> >>> >> >> >>> >> >> implementation based on this ticket. You can get the >>> >>> >> >> >>> >> >> code >>> >>> >> >> >>> >> >> 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 >>> >>> >> >> >>> >> >> <atalay.ka...@gmail.com> >>> >>> >> >> >>> >> >> wrote: >>> >>> >> >> >>> >> >> > Hello, >>> >>> >> >> >>> >> >> > >>> >>> >> >> >>> >> >> > Does anyone know which version of Solr have >>> >>> >> >> >>> >> >> > implements >>> >>> >> >> >>> >> >> > the >>> >>> >> >> >>> >> >> > Document >>> >>> >> >> >>> >> >> > Level >>> >>> >> >> >>> >> >> > Access Control, or has it implemented (partially or >>> >>> >> >> >>> >> >> > fully) >>> >>> >> >> >>> >> >> > ? >>> >>> >> >> >>> >> >> > Particularly issue #s 1834, 1872, 1895 >>> >>> >> >> >>> >> >> > >>> >>> >> >> >>> >> >> > Thanks >>> >>> >> >> >>> >> >> > >>> >>> >> >> >>> >> >> > Kadri >>> >>> >> >> >>> >> >> > >>> >>> >> >> >>> >> > >>> >>> >> >> >>> >> > >>> >>> >> >> >>> > >>> >>> >> >> >>> > >>> >>> >> >> >> >>> >>> >> >> >> >>> >>> >> >> > >>> >>> >> > >>> >>> >> > >>> >>> > >>> >>> > >>> >> >>> >> >>> > >> >> >
