mirror of
https://salsa.debian.org/freeipa-team/freeipa.git
synced 2025-02-25 18:55:28 -06:00
The extension should replace signed code (configure.jar) used for Firefox configuration. Using privileged code is not possible since Firefox 15 [1] [2]. Extension is bootstrapped which means it can be used without browser restart on Firefox 4 and later. How it works: Extension listens on each page's document element for event 'kerberos-auth-config' which should be raised on custom data element. Communication data is transferred through data element's attributes [3]. The only required attribute is 'method'. Currently there are two possible values: 'configure' and 'can_configure'. 'can_configure' method serves for detecting if the extension is installed. 'configure' method does the actual configuration. Possible optional options for 'configure' can be found in kerberosauth.js:kerberosauth.config_options. Currently they are: 'referer', 'native_gss_lib', 'trusted_uris', 'allow_proxies'. Result of a method is stored in data element's 'answer' attribute. When 'configure' method is used, the extension asks the user if he wants to configure the browser, it should prevent silent configuration by malicious pages. Possible enhancement: * add UI for manual edit * more configurations ie. for gss_lib, sspi (good with UI or with enhanced config page) * introspection of client (read ipa client install config and such) Ticket: https://fedorahosted.org/freeipa/ticket/3094 [1] https://bugzilla.mozilla.org/show_bug.cgi?id=546848 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=757046 [3] https://developer.mozilla.org/en-US/docs/Code_snippets/Interaction_between_privileged_and_non-privileged_pages
Ground rules on adding new schema Brand new schema, particularly when written specifically for IPA, should be added in share/*.ldif. Any new files need to be explicitly loaded in ipaserver/install/dsinstance.py. These simply get copied directly into the new instance schema directory. Existing schema (e.g. in an LDAP draft) may either be added as a separate ldif in share or as an update in the updates directory. The advantage of adding the schema as an update is if 389-ds ever adds the schema then the installation won't fail due to existing schema failing to load during bootstrap. If the new schema requires a new container then this should be added to install/bootstrap-template.ldif.