I am on a bus :) your suggestion are things I have already tried. I know the command line works.
My question is “what is the correct REST API query parameter that duplicates the —all command line parameter?” Get Outlook for iOS<https://aka.ms/o0ukef> ________________________________ From: Alexander Bokovoy <aboko...@redhat.com> Sent: Tuesday, November 7, 2017 8:51:59 AM To: Aaron Hicks Cc: Rob Crittenden; FreeIPA users list Subject: Re: [Freeipa-users] Re: Searching for user by extended attribute On ma, 06 marras 2017, Aaron Hicks wrote: >I am querying the REST API and it does not respond the same as the >command line. So I know that command works and it gives the information >I want. I need the REST API (which I'm querying via a python module >using plain ordinary HTTP requests) to give the same information. > >I'd like to know the correct REST query or figure if the REST API has a >bug. So, did you try to use exactly same JSON request as 'ipa -vvv user-find --all' shows? >From your terse responses it is unclear at what state you are since my morning's answers. You seem to ignore suggestions we made -- at least, you are not showing what's different for you. > >Get Outlook for iOS<https://aka.ms/o0ukef> >________________________________ >From: Rob Crittenden <rcrit...@redhat.com> >Sent: Tuesday, November 7, 2017 8:31:31 AM >To: FreeIPA users list; Alexander Bokovoy >Cc: Aaron Hicks >Subject: Re: [Freeipa-users] Re: Searching for user by extended attribute > >Aaron Hicks via FreeIPA-users wrote: >> Sorry, this does not address that the REST API is giving a different >> response than the command line or built in Python API. >> >> This behaviour is unexpected and not described in the documentation. > >What difference is that? I ran your command and user-find and got >identical output. > >rob > >> >> Get Outlook for iOS <https://aka.ms/o0ukef> >> ------------------------------------------------------------------------ >> *From:* Alexander Bokovoy <aboko...@redhat.com> >> *Sent:* Monday, November 6, 2017 8:14:29 PM >> *To:* FreeIPA users list >> *Cc:* Aaron Hicks >> *Subject:* Re: [Freeipa-users] Re: Searching for user by extended attribute >> >> On ma, 06 marras 2017, Aaron Hicks via FreeIPA-users wrote: >>>Hi everyon, >>> >>>This seems to be a flaw in the FreeIPA API itself. >>> >>>Using curl and the session method Alexander wrote up here: >>>https://vda.li/en/posts/2015/05/28/talking-to-freeipa-api-with-sessions/ >>> >>>There is no combination of the 'all':somevalue that seem to trigger a proper >>>all response. This is either broken or improperly documented. I've tried >>>'all':True 'all':1 all:'True' >>> >>>This is the curl request I'm making at the end: >>> >>>curl -v \ >>> -H referer:https://$IPAHOSTNAME/ipa \ >>> -H "Content-Type:application/json" \ >>> -H "Accept:applicaton/json" \ >>> -c $COOKIEJAR -b $COOKIEJAR \ >>> --cacert /etc/ipa/ca.crt \ >>> -d '{"method":"user_find","params":[[""],{"all":"true"}],"id":0}' \ >>> -X POST https://$IPAHOSTNAME/ipa/session/json >> See my other answer. >> >> I think what you are confused about as well is the fact that 'user_find' >> is not the command that returns _everything_ from the user entries it >> finds. Instead, it returns a curated list of attributes -- there are two >> lists, actually, -- one for a normal (without --all) and one for >> extended operation. The reason for that is because in all >> '<object>-find' calls we don't want to resolve potential membership >> information for an object to be returned. The list of members/membership >> would be too involving in case of a large database which would slow down >> find operations a lot. As result, we tuned find operation to provide a >> smaller subset (still, --all produces a bit larger one too). If you need >> all attributes, use '<object>-show' instead, once you found the name for >> an object. >> >> >> >>> >>>-----Original Message----- >>>From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] >>>Sent: Monday, 6 November 2017 3:20 PM >>>To: 'Alexander Bokovoy' <aboko...@redhat.com>; 'FreeIPA users list' >>><freeipa-users@lists.fedorahosted.org> >>>Subject: RE: [Freeipa-users] Searching for user by extended attribute >>> >>>Ah, another point of difference is that I'm using this module to communicate >>>with the API https://github.com/opennode/python-freeipa >>> >>>I've not found any documentation for using any Python modules provided by >>>FreeAPI itself in standalone python scripts, rather than via the ipa >>>console... >>> >>>-----Original Message----- >>>From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] >>>Sent: Monday, 6 November 2017 10:20 AM >>>To: 'Alexander Bokovoy' <aboko...@redhat.com>; 'FreeIPA users list' >>><freeipa-users@lists.fedorahosted.org> >>>Subject: RE: [Freeipa-users] Searching for user by extended attribute >>> >>>Ugh, on further testing; the ipa python console is giving different >>>responses that the code I'm using in a python script. >>> >>>In the ipa console, the additional attributes are listed. >>> >>>In the script I'm setting up a python-freeipa.Client object (called >>>client)and passing the following call: >>> >>>client.user_find(all=True) >>> >>>and the user records that are returned are still only the 'default' >>>attributes, even though the attributes are set and have values. >>> >>>This is the code I'm testing, it's loading all the variables from a >>>configuration file provided by the config object. >>> >>># First two lines import the project's configuration and logging objects >>>from this.configuration import config, args from this.log import base_logger >>>from python_freeipa import Client >>> >>>logger = base_logger.getChild(__name__) >>> >>>if config['freeipa'].getboolean('enabled') is True: >>> if config['freeipa'].getboolean('verify_ssl') is not True: >>> logger.warning( >>> 'Verifying TLS connection to %s disabled.' % >>> config['freeipa']['server'] >>> ) >>> logger.info('freeIPA startup') >>> client = Client( >>> config['freeipa']['server'], >>> version=config['freeipa']['version'], >>> verify_ssl=config['freeipa'].getboolean('verify_ssl') >>> ) >>> client.login( >>> config['freeipa']['user'], >>> config['freeipa']['password'] >>> ) >>>else: >>> logger.info('freeIPA disabled') >>> >>>def ipa_query(*dargs, **kwargs): >>> if config['freeipa'].getboolean('enabled') is True: >>> return client.user_find(*dargs, **kwargs) >>> else: >>> logger.info('freeIPA disabled') >>> return None >>> >>>ipa_query(all=True) >>> >>>Regards, >>> >>>Aaron >>> >>> >>>-----Original Message----- >>>From: Alexander Bokovoy [mailto:aboko...@redhat.com] >>>Sent: Friday, 3 November 2017 7:10 PM >>>To: FreeIPA users list <freeipa-users@lists.fedorahosted.org> >>>Cc: Aaron Hicks <aaron.hi...@nesi.org.nz> >>>Subject: Re: [Freeipa-users] Searching for user by extended attribute >>> >>>On pe, 03 marras 2017, Aaron Hicks via FreeIPA-users wrote: >>>>Hi all, >>>> >>>> >>>> >>>>We've added two objectclasses to the default user in our FreeIPA instance. >>>>We're able to set and modify them fine, however we need two additional >>>>functions. >>>> >>>> >>>> >>>>We need two additional attributes auedupersonsharedtoken and >>>>edupersonprinciplename to be included in the user attributes when >>>>executing user-find with the python-freeipa module. It works fine from >>>>the command line by adding the --all argument, but there's no >>>>equivalent to --all the python-freeipa module. >>>It is all there. >>> >>>$ ipa console >>>(Custom IPA interactive Python console) >>>>>> len(api.Command.user_find()['result'][0]) >>>11 >>>>>> len(api.Command.user_find(all=True)['result'][0]) >>>24 >>> >>>>We need to be able to user-find to search for users by these >>>>attributes, both from the command line and the python-freeipa module. >>>>There does not seem to be an equivalent of the --setattr command on the >>>>find function to search by attributes provided by additional >>>>objectclass >>>schema. >>>This is a bit different. You need to make sure you injected those attributes >>>into existing object definitions if you want to see them used by the >>>baseldap.py machinery. >>> >>>Can you show a code you use to extend IPA classes? >>> >>>-- >>>/ Alexander Bokovoy >>> >>> >>>_______________________________________________ >>>FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org >>>To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org >> >> -- >> / Alexander Bokovoy >> >> >> _______________________________________________ >> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org >> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org >> > -- / Alexander Bokovoy
_______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org