[Freeipa-devel] ipalib as RPC client in Web UI CI tests, forms-based auth in ipalib

[Petr Viktorin]

On 01/08/2015 03:39 PM, Petr Vobornik wrote:
> Hello,
>
> tl;dr; I want to add forms based auth in ipalib's rpc client and use
> method 2.e) for API configuration. Will be used in otp tests (ipa-4-1
> upstream). Want to know if you are OK with it. PoC implementation attached.
>
> == Background ==
> I want to call FreeIPA API from our Web UI CI tests.
>
> Uses case are:
> * speed up data preparation (the biggest time consumer in Web UI tests)
> * prepare data or do stuff which could not be done in Web UI (little bit
> part of https://fedorahosted.org/freeipa/ticket/4772)
>
> For this task I want to reuse ipalib's rpcclient to avoid yet another
> RPC client implementation.
>
> Plan is to use it in OTP web ui tests.
>
> == ipalib limitations  ==
> Please note that web ui tests could be run as a normal user on a machine
> which is not a FreeIPA client, i.e. on developers machine with local
> browser to observe the progress.
>
> === 1 Forms based authentication ===
> ipalib doesn't support forms-based auth and kerberos might not be
> available. I have investigated the option to add forms auth and managed
> to write a PoC patch(attached) which enables it. Question is whether we
> want to allow it in ipalib even for non-test uses cases. I think it
> could be beneficial for some users.
>
> === 2 API/environment finalization in ipalib/__init__.py for tests ===
> Tests which are run by make-test are initialized with
> os.environ['IPA_UNIT_TEST_MODE'] = 'cli_test'
>
> in such case, ipalib automatically finalizes API. Unfortunately the
> default configuration is unusable if run on a machine without IPA
> configuration files (~/.ipa/default.conf, /etc/ipa/default.conf, ...).
> We can't even supply the values afterwards because api.env is 'set-once'
> object.
>
> There are several approaches which could be taken:
> Proper fixes:
> a) Finish the idea, mentioned in Registry, of storing plugin
> registrations to allow multiple API creation with all plugins and
> therefore custom instances of API. Would be probably quite a lot of work
> because of wide use of global api object. I.e., various test can use
> their own instance of api.
>
> b) Remove the API initialization in ipalib/__init__.py. Initialize API
> only in tests which use it. Without a) It might suffer from the same
> issue as d)
>
> c) Remove 'set-once' constraint from Env object to allow config change
> after API initialization
>
> Workarounds:
> d) Change the os.env variable to a different than 'cli_test' value
> before api import in uidriver.py to prevent the automatic
> initialization. Init api in Web UI tests. Might cause issues if other
> tests were run and initialized api before Web ui tests.
>
> e) override values in Env object by a hack:
>    object.__setattr__(api.env, key, val)
>    api.env._Env__d[key] = val
> Advantage is that it's self-contained in Web UI tests. Must be changed
> back at the end of test not to interfere with other tests.
>
> f) require IPA configuration file even on non-ipa client machines. Easy,
> but not very pleasant for user - all required configuration values are
> already present in webui test config file or in env variables ->
> multiple files has to be changed when switching between testing
> instances(frequent use case).
>
> g) other
>
>  From longer perspective I would like to see a) and b), maybe c). But I
> would like to use this feature in otptests which should land in 4.1 ->
> a) is not an option because of its complexity. Therefore, atm, I would
> like to go with e) or c)

Yes, a) is the proper solution, and when it's done b) can be started 
gradually, in tests that need a different API.

If there's no time to do that, go with e), which is a localized change. 
For c) you'd want to think through carefully – and at that point you 
could just do a) first.

-- 
Petr³