mirror of
https://salsa.debian.org/freeipa-team/freeipa.git
synced 2025-02-25 18:55:28 -06:00
b4fc6f4ba8
Issue: * There was no caching policy specified. * -> Browsers use their own default policy. * -> After upgrade, some Web UI files might have been actualized some not. * -> With schema change may result into weird bugs in Web UI Solution considerations: 1. Detect server version change and hard-reload at runtime Detection is easy. Problem is the reload. Obvious candidate 'window.location.reload(true)' works in Firefox but not in Chrome because expected behavior when parameter is used is not in standard and therefore Chromium/WebKit authors did not implement it. 2. Application Cache HTML 5 technology which lets web apps to run offline. Besides weird issues with event handlers which I encountered, this would be an ideal candidate. Simple change of manifest file would lead to reload of all files (requires reload of page to used the new files). Showstopper was usage with untrusted certificate. If user did not add exception for the cert or its CA and would visit the page for a second time, all AJAX calls would fail. 3. Set Expires to now() for everything Web UI rarely changes so this is an overkill. Setting it to different value is not a solution either. We can't predict when the upgrade will happen and when new Web UI will be needed. Solution: * Implemented a mini loader which loads basic resources. Dojo loader takes action after Dojo is loaded. * The loader adds a version parameter (?v=__NUM_VERSION__) to all requests. * Version is defined in the loader. It's set to current in `make version-update`. * All static pages use this loader to fetch their resources. * Version is also passed to dojo loader as cache-bust for the same effect. * Expire header was set to 'access time plus 1 year' for /ui folder. Exceptions are HTML files and loader (set to immediate expiration). Possible issues: * Images are cached but not requested with version param. * Images with version and without are considered different * -> We would have to attach version to all URIs - in CSS and in JS. But we should avoid changing jQuery UI CSS. * Proposed solution is to change image name when changing image. Image change is done rarely. * Version is set by build and therefore updated just on server update. It might cause trouble with different update schedule of plugins. * No action taken to address this issue yet. * We might leave it on plugin devs (own .conf in /etc/httpd/conf.d/) * or set expires to now for all plugins * running `make version-update` is required in order to use static version of UI for testing https://fedorahosted.org/freeipa/ticket/3798 |
||
|---|---|---|
| .tx | ||
| checks | ||
| contrib | ||
| daemons | ||
| doc | ||
| init | ||
| install | ||
| ipa-client | ||
| ipalib | ||
| ipapython | ||
| ipaserver | ||
| ipatests | ||
| util | ||
| .bzrignore | ||
| .gitignore | ||
| API.txt | ||
| autogen.sh | ||
| BUILD.txt | ||
| Contributors.txt | ||
| COPYING | ||
| freeipa.spec.in | ||
| ipa | ||
| ipa.1 | ||
| lite-server.py | ||
| make-doc | ||
| make-lint | ||
| make-test | ||
| make-testcert | ||
| makeapi | ||
| Makefile | ||
| MANIFEST.in | ||
| README | ||
| setup-client.py | ||
| setup.py | ||
| TODO | ||
| VERSION | ||
| version.m4.in | ||
IPA Server
What is it?
-----------
For efficiency, compliance and risk mitigation, organizations need to
centrally manage and correlate vital security information including:
* Identity (machine, user, virtual machines, groups, authentication
credentials)
* Policy (configuration settings, access control information)
* Audit (events, logs, analysis thereof)
Since these are not new problems. there exist many approaches and
products focused on addressing them. However, these tend to have the
following weaknesses:
* Focus on solving identity management across the enterprise has meant
less focus on policy and audit.
* Vendor focus on Web identity management problems has meant less well
developed solutions for central management of the Linux and Unix
world's vital security info. Organizations are forced to maintain
a hodgepodge of internal and proprietary solutions at high TCO.
* Proprietary security products don't easily provide access to the
vital security information they collect or manage. This makes it
difficult to synchronize and analyze effectively.
The Latest Version
------------------
Details of the latest version can be found on the IPA server project
page under <http://www.freeipa.org/>.
Documentation
-------------
The most up-to-date documentation can be found at
<http://freeipa.org/page/Documentation/>.
Quick Start
-----------
To get started quickly, start here:
<https://fedorahosted.org/freeipa/wiki/QuickStartGuide>
Licensing
---------
Please see the file called COPYING.
Contacts
--------
* If you want to be informed about new code releases, bug fixes,
security fixes, general news and information about the IPA server
subscribe to the freeipa-announce mailing list at
<https://www.redhat.com/mailman/listinfo/freeipa-interest/>.
* If you have a bug report please submit it at:
<https://bugzilla.redhat.com>
* If you want to participate in actively developing IPA please
subscribe to the freeipa-devel mailing list at
<https://www.redhat.com/mailman/listinfo/freeipa-devel/> or join
us in IRC at irc://irc.freenode.net/freeipa