manifoldcf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kadri Atalay <atalay.ka...@gmail.com>
Subject Re: Which version of Solr have implements the Document Level Access Control
Date Tue, 03 May 2011 14:24:51 GMT
Karl, it sounds good !
I'll let you know, with the results.
Thanks!
Kadri

On Tue, May 3, 2011 at 3:55 AM, Karl Wright <daddywri@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 <daddywri@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.kadri@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 <daddywri@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.kadri@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 <daddywri@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.kadri@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 <daddywri@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 <
> daddywri@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.kadri@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
> >>> >> >> >> <daddywri@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.kadri@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
> >>> >> >> >>> > <daddywri@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.kadri@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
> >>> >> >> >>> >> > <daddywri@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.kadri@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
> >>> >> >> >>> >> >> >
> >>> >> >> >>> >> >
> >>> >> >> >>> >> >
> >>> >> >> >>> >
> >>> >> >> >>> >
> >>> >> >> >>
> >>> >> >> >>
> >>> >> >> >
> >>> >> >
> >>> >> >
> >>> >
> >>> >
> >>
> >>
> >
>

Mime
View raw message