manifoldcf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Wright <daddy...@gmail.com>
Subject Re: Which version of Solr have implements the Document Level Access Control
Date Tue, 03 May 2011 16:36:23 GMT
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.kadri@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=fakeuser@teqa.filetek.com"
> USERNOTFOUND:TEQA-DC
> TOKEN:TEQA-DC:DEAD_AUTHORITY
>
> valid user and valid domain  (please see bitmap file katalay_admin@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_admin@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_admin@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=katalay@teqa.filetek.com"
> USERNOTFOUND:TEQA-DC
> TOKEN:TEQA-DC:DEAD_AUTHORITY
>
> 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