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

[Petr Vobornik]

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)

Thanks
-- 
Petr Vobornik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wip-freeipa-pvoborni-0739-webui-tests-support-direct-IPA-API-calls.patch
Type: text/x-patch
Size: 5523 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20150108/30e2da83/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wip-freeipa-pvoborni-0738-rpc-client-add-forms-based-auth-support.patch
Type: text/x-patch
Size: 17972 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20150108/30e2da83/attachment-0001.bin>