IntenseWebs/freeipa
3
0
Fork 0
mirror of https://salsa.debian.org/freeipa-team/freeipa.git synced 2024-12-24 16:10:02 -06:00
Code Issues Packages Projects Releases Wiki Activity
6518a600b4
freeipa/install/ui/reset_password.html

71 lines
2.0 KiB
HTML
Raw Normal View History

Separate reset password page This patch adds separate reset password page. It is a complement to separate login page. It differentiate from reset password capabilities in Web UI's anauthorized dialog by not performing login. This is useful for users who wants only to reset the password and not to use Web UI. And also for users who are using the separate login page. https://fedorahosted.org/freeipa/ticket/2755
2012-06-08 09:38:17 -05:00
<!DOCTYPE html>
Use "login" plugin instead of standalone JS file Plugin "login" already has the same functionality as a JS code in separated javascript file. There is no need to duplicate it. Fixes: https://pagure.io/freeipa/issue/7619 Reviewed-By: Petr Vobornik <pvoborni@redhat.com> Reviewed-By: Serhii Tsymbaliuk <stsymbal@redhat.com>
2018-07-06 03:38:01 -05:00
<html>
Separate reset password page This patch adds separate reset password page. It is a complement to separate login page. It differentiate from reset password capabilities in Web UI's anauthorized dialog by not performing login. This is useful for users who wants only to reset the password and not to use Web UI. And also for users who are using the separate login page. https://fedorahosted.org/freeipa/ticket/2755
2012-06-08 09:38:17 -05:00
<head>
<meta charset="utf-8">
Change FreeIPA references to IPA and Identity Management In order to simplify the build process between upstream FreeIPA and downstream builds (such as CentOS Stream) we are changing some file references from FreeIPA to IPA (and Identity Management). https://pagure.io/freeipa/issue/8669 Signed-off-by: Rob Crittenden <rcritten@redhat.com> Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
2021-01-19 14:35:41 -06:00
<title>Identity Management</title>
Use "login" plugin instead of standalone JS file Plugin "login" already has the same functionality as a JS code in separated javascript file. There is no need to duplicate it. Fixes: https://pagure.io/freeipa/issue/7619 Reviewed-By: Petr Vobornik <pvoborni@redhat.com> Reviewed-By: Serhii Tsymbaliuk <stsymbal@redhat.com>
2018-07-06 03:38:01 -05:00
<!--[if IE]>
<meta id="ie-detector">
<![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
Load updated Web UI files after server upgrade 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
2013-08-29 08:19:02 -05:00
<script type="text/javascript" src="js/libs/loader.js"></script>
<script type="text/javascript">
Use "login" plugin instead of standalone JS file Plugin "login" already has the same functionality as a JS code in separated javascript file. There is no need to duplicate it. Fixes: https://pagure.io/freeipa/issue/7619 Reviewed-By: Petr Vobornik <pvoborni@redhat.com> Reviewed-By: Serhii Tsymbaliuk <stsymbal@redhat.com>
2018-07-06 03:38:01 -05:00
var dojoConfig = {
baseUrl: "js",
has: {
'dojo-firebug': false,
'dojo-debug-messages': true
},
parseOnLoad: false,
async: true,
packages: [
{
name:'dojo',
location:'dojo'
},
{
name: 'freeipa',
location: 'freeipa'
}
],
cacheBust: ipa_loader.num_version || ""
};
Load updated Web UI files after server upgrade 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
2013-08-29 08:19:02 -05:00
(function() {
Use "login" plugin instead of standalone JS file Plugin "login" already has the same functionality as a JS code in separated javascript file. There is no need to duplicate it. Fixes: https://pagure.io/freeipa/issue/7619 Reviewed-By: Petr Vobornik <pvoborni@redhat.com> Reviewed-By: Serhii Tsymbaliuk <stsymbal@redhat.com>
2018-07-06 03:38:01 -05:00
var ie = !!document.getElementById('ie-detector');
webui: apply PatternFly login theme on reset_password.html https://fedorahosted.org/freeipa/ticket/4282 Reviewed-By: Endi Sukma Dewata <edewata@redhat.com>
2014-03-28 10:03:26 -05:00
var styles = [
Use "login" plugin instead of standalone JS file Plugin "login" already has the same functionality as a JS code in separated javascript file. There is no need to duplicate it. Fixes: https://pagure.io/freeipa/issue/7619 Reviewed-By: Petr Vobornik <pvoborni@redhat.com> Reviewed-By: Serhii Tsymbaliuk <stsymbal@redhat.com>
2018-07-06 03:38:01 -05:00
'css/patternfly.css',
'css/ipa.css',
'ipa.css'
webui: apply PatternFly login theme on reset_password.html https://fedorahosted.org/freeipa/ticket/4282 Reviewed-By: Endi Sukma Dewata <edewata@redhat.com>
2014-03-28 10:03:26 -05:00
];
Use "login" plugin instead of standalone JS file Plugin "login" already has the same functionality as a JS code in separated javascript file. There is no need to duplicate it. Fixes: https://pagure.io/freeipa/issue/7619 Reviewed-By: Petr Vobornik <pvoborni@redhat.com> Reviewed-By: Serhii Tsymbaliuk <stsymbal@redhat.com>
2018-07-06 03:38:01 -05:00
if (ie) styles.push('ie.css');
var icons = ['favicon.ico'];
var scripts = [
'js/libs/json2.js',
Load updated Web UI files after server upgrade 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
2013-08-29 08:19:02 -05:00
'js/libs/jquery.js',
Use "login" plugin instead of standalone JS file Plugin "login" already has the same functionality as a JS code in separated javascript file. There is no need to duplicate it. Fixes: https://pagure.io/freeipa/issue/7619 Reviewed-By: Petr Vobornik <pvoborni@redhat.com> Reviewed-By: Serhii Tsymbaliuk <stsymbal@redhat.com>
2018-07-06 03:38:01 -05:00
'js/libs/bootstrap.js',
'js/libs/jquery.ordered-map.js',
'js/libs/browser.js',
'js/dojo/dojo.js'
];
ipa_loader.scripts(scripts, function() {
require(['freeipa/core', 'dojo/domReady!'], function(app) {
var reset_pass = require('freeipa/plugins/login');
reset_pass.facet_spec.widgets[1].view = "reset";
app.run_simple('login');
});
});
ipa_loader.styles(styles);
ipa_loader.icons(icons);
Load updated Web UI files after server upgrade 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
2013-08-29 08:19:02 -05:00
})();
</script>
Separate reset password page This patch adds separate reset password page. It is a complement to separate login page. It differentiate from reset password capabilities in Web UI's anauthorized dialog by not performing login. This is useful for users who wants only to reset the password and not to use Web UI. And also for users who are using the separate login page. https://fedorahosted.org/freeipa/ticket/2755
2012-06-08 09:38:17 -05:00
</head>
webui: apply PatternFly login theme on reset_password.html https://fedorahosted.org/freeipa/ticket/4282 Reviewed-By: Endi Sukma Dewata <edewata@redhat.com>
2014-03-28 10:03:26 -05:00
<body>
Use "login" plugin instead of standalone JS file Plugin "login" already has the same functionality as a JS code in separated javascript file. There is no need to duplicate it. Fixes: https://pagure.io/freeipa/issue/7619 Reviewed-By: Petr Vobornik <pvoborni@redhat.com> Reviewed-By: Serhii Tsymbaliuk <stsymbal@redhat.com>
2018-07-06 03:38:01 -05:00
<noscript>This application requires JavaScript enabled.</noscript>
Separate reset password page This patch adds separate reset password page. It is a complement to separate login page. It differentiate from reset password capabilities in Web UI's anauthorized dialog by not performing login. This is useful for users who wants only to reset the password and not to use Web UI. And also for users who are using the separate login page. https://fedorahosted.org/freeipa/ticket/2755
2012-06-08 09:38:17 -05:00
</body>
</html>
Reference in New Issue Copy Permalink