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 Mon, 02 May 2011 21:52:14 GMT
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