Re: [Freeipa-devel] [PATCHES] 241-253 CA certificate renewal
On 04/24/2014 11:16 PM, Rob Crittenden wrote:
Jan Cholasta wrote:
On 10.4.2014 22:06, Rob Crittenden wrote:
Some in-line, a whole ton of data appended to end.
Jan Cholasta wrote:
On 7.4.2014 20:09, Rob Crittenden wrote:
Rob Crittenden wrote:
[...]
$ ipa-cacert-manage -v renew
ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: File
/usr/lib/python2.7/site-packages/ipapython/admintool.py, line
168, in
execute
self.validate_options()
File
/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py,
line 62, in validate_options
super(CACertManage, self).validate_options(needs_root=True)
File /usr/lib/python2.7/site-packages/ipapython/admintool.py,
line
189, in validate_options
raise ScriptError('Must be root to run %s' %
self.command_name, 1)
ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: The
ipa-cacert-manage command failed, exception: ScriptError: Must be
root
to run ipa-cacert-manage
ipa.ipaserver.install.ipa_cacert_manage.CACertManage: ERROR: Must be
root to run ipa-cacert-manage
That's correct, you can run it only as root, because you can't resubmit
certmonger requests as a regular user.
Yes but one shouldn't get a traceback!
You get the traceback only in verbose mode. I did not invent this, it's
how ipapython.admintool does things.
Ok, I'll blame Petr.
In verbose mode you get all the debugging information that's written to
logs, and that includes the tracebacks. I stand by this decision.
If the command is normally so quiet that you need the -v flag for normal
operation, that's a problem. Log interesting messages at INFO.
http://www.freeipa.org/page/V3/Logging_and_output#Design
--
Petr³
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] First beta release of ConnID FreeIPA connector
On 04/24/2014 11:21 PM, Dmitri Pal wrote: On 04/24/2014 09:58 AM, Massimiliano Perrone (tirasa.net) wrote: Hi guys, this mail only to share with you that ConnID FreeIPA connector (beta version) is released. You can find more informations here [1] Massimiliano [1] http://blog.tirasa.net/unlock-full-freeipa-features.html Cool! It might make sense to put something on the IPA wiki to have a cross reference. +1. For starters, I at least added link to our HOW TOs: http://www.freeipa.org/page/HowTos#Interoperability_with_other_systems Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 241-253 CA certificate renewal
On 24.4.2014 23:16, Rob Crittenden wrote: Jan Cholasta wrote: On 10.4.2014 22:06, Rob Crittenden wrote: Some in-line, a whole ton of data appended to end. Jan Cholasta wrote: On 7.4.2014 20:09, Rob Crittenden wrote: Rob Crittenden wrote: 247 We've been burned by hardcoded timeouts in the past. Should this be configurable? This module doesn't currently do any logging but it might be worth spitting out a waiting message, at least for debugging. Added a timeout argument. Did you forget to send this one, I didn't see an update to 247. Are you sure you have 247.1 (now 247.2)? I can see at http://www.redhat.com/archives/freeipa-devel/2014-April/msg00225.html that I have sent the correct version of the patches. The call has a timeout, the callers don't use it. I guess it'll do for now, but these almost always come back to bite us. Well, I can add --certmonger-timeout option to ipa-cacert-manage, if that's what you want. 251 The tool should provide some feedback while it's running. For the impatient (me) it takes a really long time and it's hard to know what is going on, something in between nothing and full debug output. Added some messages about what's going on. I dpn't see an update to 251 either. Please make sure you have 251.1 (now 251.2). There is a little bit more output but there are still very long periods of waiting between any visual activity, particularly when doing it on an IPA self-signed CA. This stuff takes time :-) What would you like to see in the output, that's not already there? I think the ipa-cacert-manage man page is missing one really important piece: why would you ever need to run this? And when? Added a paragraph about this. It's better, couple of comments: Add the in between renew and CA in used to manually renew CA certificate of and When IPA CA OK. I haven't had any luck renewing the CA certificate yet. I see that it is tracked now. I started moving the system clock forward in order to get to renewal and about the 3rd iteration the requests started failing with an XML error. Did you see this? [Thu Apr 21 11:08:49.929486 2016] [:error] [pid 11692] Traceback (most recent call last): [Thu Apr 21 11:08:49.929489 2016] [:error] [pid 11692] File /usr/lib/python2.7/site-packages/ipaserver/rpcserver.py, line 344, in wsgi_execute [Thu Apr 21 11:08:49.929493 2016] [:error] [pid 11692] result = self.Command[name](*args, **options) [Thu Apr 21 11:08:49.929496 2016] [:error] [pid 11692] File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 436, in __call__ [Thu Apr 21 11:08:49.929499 2016] [:error] [pid 11692] ret = self.run(*args, **options) [Thu Apr 21 11:08:49.929503 2016] [:error] [pid 11692] File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 752, in run [Thu Apr 21 11:08:49.929506 2016] [:error] [pid 11692] result = self.execute(*args, **options) [Thu Apr 21 11:08:49.929509 2016] [:error] [pid 11692] File /usr/lib/python2.7/site-packages/ipalib/plugins/cert.py, line 382, in execute [Thu Apr 21 11:08:49.929512 2016] [:error] [pid 11692] result = api.Command['cert_show'](unicode(serial))['result'] [Thu Apr 21 11:08:49.929516 2016] [:error] [pid 11692] File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 436, in __call__ [Thu Apr 21 11:08:49.929519 2016] [:error] [pid 11692] ret = self.run(*args, **options) [Thu Apr 21 11:08:49.930559 2016] [:error] [pid 11692] File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 752, in run [Thu Apr 21 11:08:49.930567 2016] [:error] [pid 11692] result = self.execute(*args, **options) [Thu Apr 21 11:08:49.930570 2016] [:error] [pid 11692] File /usr/lib/python2.7/site-packages/ipalib/plugins/cert.py, line 514, in execute [Thu Apr 21 11:08:49.930573 2016] [:error] [pid 11692] result=self.Backend.ra.get_certificate(serial_number) [Thu Apr 21 11:08:49.930577 2016] [:error] [pid 11692] File /usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py, line 1502, in get_certificate [Thu Apr 21 11:08:49.930580 2016] [:error] [pid 11692] parse_result = self.get_parse_result_xml(http_body, parse_display_cert_xml) [Thu Apr 21 11:08:49.930591 2016] [:error] [pid 11692] File /usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py, line 1363, in get_parse_result_xml [Thu Apr 21 11:08:49.930594 2016] [:error] [pid 11692] doc = etree.fromstring(xml_text, parser) [Thu Apr 21 11:08:49.930598 2016] [:error] [pid 11692] File lxml.etree.pyx, line 3032, in lxml.etree.fromstring (src/lxml/lxml.etree.c:68129) [Thu Apr 21 11:08:49.930601 2016] [:error] [pid 11692] File parser.pxi, line 1785, in lxml.etree._parseMemoryDocument (src/lxml/lxml.etree.c:102493) [Thu Apr 21 11:08:49.930604 2016] [:error] [pid 11692] File parser.pxi, line 1673, in lxml.etree._parseDoc (src/lxml/lxml.etree.c:101322) [Thu Apr 21 11:08:49.930607 2016] [:error] [pid 11692] File parser.pxi, line 1074, in lxml.etree._BaseParser._parseDoc
Re: [Freeipa-devel] [PATCH 0137] ipalib: Add DateTime parameter
On 22.4.2014 13:32, Tomas Babej wrote:
Thank you for the suggestions. Updated, rebased patch is attached.
This API.txt change from the next patch belongs in this patch:
+capability: datetime_values 2.84
I think you should use the LDAP_GENERALIZED_TIME_FORMAT constant here:
+accepted_formats = ['%Y%m%d%H%M%SZ', # generalized time
This is not right:
+elif isinstance(val, datetime.datetime):
+return val
To actually decode LDAP generalized time attributes to datetime, you
need to do this:
'2.16.840.1.113719.1.301.4.41.1' : DN, # krbSubTrees
'2.16.840.1.113719.1.301.4.52.1' : DN, # krbObjectReferences
'2.16.840.1.113719.1.301.4.53.1' : DN, # krbPrincContainerRef
+
+'1.3.6.1.4.1.1466.115.121.1.24' : datetime.datetime,
}
# In most cases we lookup the syntax from the schema returned by
and this:
return val
elif target_type is unicode:
return val.decode('utf-8')
+elif target_type is datetime.datetime:
+return datetime.datetime.strptime(val,
LDAP_GENERALIZED_TIME_FORMAT)
else:
return target_type(val)
except Exception, e:
and add code for formatting datetime values to the textui backend.
--
Jan Cholasta
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 0538 aci-update: Trim the admin write blacklist
On 04/24/2014 05:15 PM, Simo Sorce wrote: On Thu, 2014-04-24 at 16:47 +0200, Martin Kosek wrote: On 04/24/2014 03:42 PM, Simo Sorce wrote: On Thu, 2014-04-24 at 15:18 +0200, Martin Kosek wrote: On 04/24/2014 02:28 PM, Simo Sorce wrote: On Thu, 2014-04-24 at 14:17 +0200, Martin Kosek wrote: On 04/24/2014 09:41 AM, Petr Viktorin wrote: On 04/23/2014 08:56 PM, Simo Sorce wrote: On Wed, 2014-04-23 at 20:37 +0200, Petr Viktorin wrote: Admin access to read-only attributes such as ipaUniqueId, memberOf, krbPrincipalName is provided by the anonymous read ACI, which will go away. This patch adds a blanket read ACI for these. I also moved some related ACIs to 20-aci.update. Previously krbPwdHistory was also readable by admins. I don't think we want to include that. Simo, should admins be allowed to read krbExtraData? Probably not necessary but there is nothing secret in it either. Simo. OK. I'm not a fan of hiding things from the admin, so no changes to the patch are necessary here. 536: As we are touching these ACIs, may it is a time to see the blacklist of attributes that admin cannot write and check if this is still wanted: ipaUniqueId - OK, generated by DS plugin memberOf - OK, generated by DS plugin serverHostName - I did not even find a place where we manipulate it, except host.py - remove from blacklist? What about this one? not sure, I did not work much on the hosts objects. Rob? Do you know? enrolledBy - OK, generated by DS plugin krbExtraData - OK, generated by DS plugin krbPrincipalName - why can't admin change it? It is filled by framework, I would not personally blacklist it It is changed by the ipa rename plugin when the user uid change, that's why we prevent the admin from explicitly change it. krbCanonicalName - same as krbPrincipalName Ok, in that case krbPrincipalName and krbCanonicalName should stay, right? They should be accessible by admin, yes. Note that we are now discussing write access. I.e. what attributes needs to stay in the admin's global write ACI blacklist and which can be removed - admin can write in them. IIUC, these should be only readable by admin, not writeable. krbPrincipalAliases - same as krbPrincipalName - we need this removed if we want to set aliases anyway Allow this one? This is one I wanted to eventually get rid of, Alexander seem to have introduced it, but we discussed in the past of a way to kill it. I forgot the details thouhg. Alexander did we open a ticket for this ? Ok, we may eventually get rid of it, but does it need to be blacklisted in admins global write ACI? krbPasswordExpiration - OK, generated by DS plugin krbLastPwdChange - OK, generated by DS plugin krbUPEnabled - not used, can we remove it? What about this one? We never use it. I read this as remove it from global admin write ACI blacklist. krbTicketPolicyReference - why cannot admin set it? Unclear why, probably should be able to. We may want to remove it from blacklist then. We never used it, but we should probably allow admin to modify Ok, let us remove it from global admin write ACI blacklist. krbPwdPolicyReference - why cannot admin set it? We assign password policy based on groups now, right ? Yup. I see no complains, i.e. I read it as remove it from global admin write ACI blacklist. krbPrincipalType - why cannot admin set it? Unused. So... allow this one? we never use it so we do not need to allow admins by default. My point was to limit admin write ACI blacklist to the bare minimum. Only to attributes that really needs to be blacklisted as they are operated by DS plugins - like memberOf and others. My proposal is to remove it from global admin write ACI blacklist given it is not used. Ack, I agree with your intent. Simo. If I understand correctly, we want to allow: - krbPrincipalAliases - krbPrincipalType - krbPwdPolicyReference - krbTicketPolicyReference - krbUPEnabled - serverHostName Here is the patch for that. Martin, just to make sure: 0536-0537 are good to push, right? -- Petr³ From 7a5deb8323348cca3475efd908dabe68466ffd19 Mon Sep 17 00:00:00 2001 From: Petr Viktorin pvikt...@redhat.com Date: Fri, 25 Apr 2014 10:42:05 +0200 Subject: [PATCH] aci-update: Trim the admin write blacklist These attributes are removed from the blacklist, which means high-level admins can now modify them: - krbPrincipalAliases - krbPrincipalType - krbPwdPolicyReference - krbTicketPolicyReference - krbUPEnabled - serverHostName The intention is to only blacklist password attributes and attributes that are managed by DS plugins. --- install/updates/20-aci.update | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/install/updates/20-aci.update b/install/updates/20-aci.update index c25fdcc92edd29f505c82959d8a70e4fd59e4c2f..b6012afea73d63a83a6791b63e43c7dd4abff9a8 100644 --- a/install/updates/20-aci.update +++ b/install/updates/20-aci.update @@ -38,7 +38,8 @@ dn: $SUFFIX remove:aci:'(targetattr
[Freeipa-devel] [PATCH] 16-17 Attribute box in permission UI is too small
Hi,
first patch redesigns attribute box in permission forms, making it
a bigger scrollable checkboxlist. Second one adds a filter field to it
for better user experience, if the checkboxlist would be too large.
Also, webui unit tests for rbac are updated to work properly with the
new widget.
Thanks
AdamFrom e12c8341b8ce10a32841cff8baca03c6b00b14d4 Mon Sep 17 00:00:00 2001
From: Adam Misnyovszki amisn...@redhat.com
Date: Fri, 25 Apr 2014 12:54:17 +0200
Subject: [PATCH 1/2] Attribute box in permission UI is too small
Attributes widget modified to display checkbox list
with a limited height scrollable div. Check all
attributes option is removed to keep the user read
through the attributes which he selects. Webui
integration tests modified according to new widget
layout.
https://fedorahosted.org/freeipa/ticket/4253
---
install/ui/ipa.css | 12 ++
install/ui/src/freeipa/aci.js| 51 ++--
ipatests/test_webui/test_rbac.py | 6 ++---
3 files changed, 27 insertions(+), 42 deletions(-)
diff --git a/install/ui/ipa.css b/install/ui/ipa.css
index 835ec1cc6c81f86e589f71e2d21450363c260850..d4c1c8c31878bddc77324e2d9e87e3ebb4ba2591 100644
--- a/install/ui/ipa.css
+++ b/install/ui/ipa.css
@@ -992,6 +992,18 @@ table.scrollable tbody {
max-width: 150px;
}
+.option_widget.columns.attribute_widget {
+overflow-y: auto;
+max-height: 36em;
+}
+
+.option_widget.columns.attribute_widget li {
+float: left;
+width: 50%;
+min-width: 90px;
+max-width: 200px;
+}
+
.combobox-widget-input {
display: inline-block;
position: relative;
diff --git a/install/ui/src/freeipa/aci.js b/install/ui/src/freeipa/aci.js
index e26ecd27d9987f629415c45f36cd8be410bf4c3b..2a0c669d1b90b3662e3b59fb00bb9b739296775c 100644
--- a/install/ui/src/freeipa/aci.js
+++ b/install/ui/src/freeipa/aci.js
@@ -556,36 +556,15 @@ aci.attributes_widget = function(spec) {
that.create = function(container) {
that.container = container;
-var attr_container = $('div/', {
-'class': 'aci-attribute-table-container'
+that.$node = that.attr_container = attr_container = $('div/', {
+'class': 'widget radio-widget'
}).appendTo(container);
-that.$node = that.table = $('table/', {
-id: id,
-name: that.name,
-'class': 'search-table aci-attribute-table scrollable'
-}).
-append('thead/').
-append('tbody/').
-appendTo(attr_container);
-
-var tr = $('tr/tr').appendTo($('thead', that.table));
-
-var th = $('th/').appendTo(tr);
-IPA.standalone_option({
-type: checkbox,
-click: function() {
-$('.aci-attribute', that.table).
-prop('checked', $(this).prop('checked'));
-that.value_changed.notify([], that);
-that.emit('value-change', { source: that });
-}
-}, th);
-
-tr.append($('th/', {
-'class': 'aci-attribute-column',
-html: text.get('@i18n:objects.aci.attribute')
-}));
+var ul = $('ul/',{
+'class' : 'option_widget columns attribute_widget',
+'id' : id,
+'name' : that.name
+}).appendTo(attr_container);
if (that.undo) {
that.create_undo(container);
@@ -599,14 +578,13 @@ aci.attributes_widget = function(spec) {
};
that.create_options = function(options) {
-var tbody = $('tbody', that.table);
+var ul = $('ul.attribute_widget', that.attr_container);
for (var i=0; ioptions.length ; i++){
var option = options[i];
var value = option.value.toLowerCase();
-var tr = $('tr/').appendTo(tbody);
+var li = $('li/').appendTo(ul);
-var td = $('td/').appendTo(tr);
var name = that.get_input_name();
var id = that._option_next_id + name;
var opt = IPA.standalone_option({
@@ -619,12 +597,7 @@ aci.attributes_widget = function(spec) {
that.value_changed.notify([], that);
that.emit('value-change', { source: that });
}
-}, td);
-td = $('td/').appendTo(tr);
-td.append($('label/',{
-text: value,
-'for': id
-}));
+}, li, value);
option.input_node = opt[0];
that.new_option_id();
}
@@ -653,7 +626,7 @@ aci.attributes_widget = function(spec) {
that.populate = function(object_type) {
-$('tbody tr', that.table).remove();
+$('ul.attribute_widget li', that.attr_container).remove();
if (!object_type || object_type === '') return;
@@ -1081,4 +1054,4 @@ aci.register = function() {
phases.on('registration', aci.register);
return aci;
-});
\ No newline at end of file
Re: [Freeipa-devel] [PATCH] 0538 aci-update: Trim the admin write blacklist
On 04/25/2014 01:01 PM, Petr Viktorin wrote: On 04/24/2014 05:15 PM, Simo Sorce wrote: On Thu, 2014-04-24 at 16:47 +0200, Martin Kosek wrote: On 04/24/2014 03:42 PM, Simo Sorce wrote: On Thu, 2014-04-24 at 15:18 +0200, Martin Kosek wrote: On 04/24/2014 02:28 PM, Simo Sorce wrote: On Thu, 2014-04-24 at 14:17 +0200, Martin Kosek wrote: On 04/24/2014 09:41 AM, Petr Viktorin wrote: On 04/23/2014 08:56 PM, Simo Sorce wrote: On Wed, 2014-04-23 at 20:37 +0200, Petr Viktorin wrote: Admin access to read-only attributes such as ipaUniqueId, memberOf, krbPrincipalName is provided by the anonymous read ACI, which will go away. This patch adds a blanket read ACI for these. I also moved some related ACIs to 20-aci.update. Previously krbPwdHistory was also readable by admins. I don't think we want to include that. Simo, should admins be allowed to read krbExtraData? Probably not necessary but there is nothing secret in it either. Simo. OK. I'm not a fan of hiding things from the admin, so no changes to the patch are necessary here. 536: As we are touching these ACIs, may it is a time to see the blacklist of attributes that admin cannot write and check if this is still wanted: ipaUniqueId - OK, generated by DS plugin memberOf - OK, generated by DS plugin serverHostName - I did not even find a place where we manipulate it, except host.py - remove from blacklist? What about this one? not sure, I did not work much on the hosts objects. Rob? Do you know? enrolledBy - OK, generated by DS plugin krbExtraData - OK, generated by DS plugin krbPrincipalName - why can't admin change it? It is filled by framework, I would not personally blacklist it It is changed by the ipa rename plugin when the user uid change, that's why we prevent the admin from explicitly change it. krbCanonicalName - same as krbPrincipalName Ok, in that case krbPrincipalName and krbCanonicalName should stay, right? They should be accessible by admin, yes. Note that we are now discussing write access. I.e. what attributes needs to stay in the admin's global write ACI blacklist and which can be removed - admin can write in them. IIUC, these should be only readable by admin, not writeable. krbPrincipalAliases - same as krbPrincipalName - we need this removed if we want to set aliases anyway Allow this one? This is one I wanted to eventually get rid of, Alexander seem to have introduced it, but we discussed in the past of a way to kill it. I forgot the details thouhg. Alexander did we open a ticket for this ? Ok, we may eventually get rid of it, but does it need to be blacklisted in admins global write ACI? krbPasswordExpiration - OK, generated by DS plugin krbLastPwdChange - OK, generated by DS plugin krbUPEnabled - not used, can we remove it? What about this one? We never use it. I read this as remove it from global admin write ACI blacklist. krbTicketPolicyReference - why cannot admin set it? Unclear why, probably should be able to. We may want to remove it from blacklist then. We never used it, but we should probably allow admin to modify Ok, let us remove it from global admin write ACI blacklist. krbPwdPolicyReference - why cannot admin set it? We assign password policy based on groups now, right ? Yup. I see no complains, i.e. I read it as remove it from global admin write ACI blacklist. krbPrincipalType - why cannot admin set it? Unused. So... allow this one? we never use it so we do not need to allow admins by default. My point was to limit admin write ACI blacklist to the bare minimum. Only to attributes that really needs to be blacklisted as they are operated by DS plugins - like memberOf and others. My proposal is to remove it from global admin write ACI blacklist given it is not used. Ack, I agree with your intent. Simo. If I understand correctly, we want to allow: - krbPrincipalAliases - krbPrincipalType - krbPwdPolicyReference - krbTicketPolicyReference - krbUPEnabled - serverHostName Here is the patch for that. The list looks good to me. Martin, just to make sure: 0536-0537 are good to push, right? One of the reasons why I wanted to prune the blacklist a bit was to make the Admin read ACI (Admin read-only attributes) simpler (read - shorter). So please also update this aci in 536. IMO, 536 and 538 can be squashed, but that's up to you. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0529 Add managed read permission to trusts
On 04/23/2014 02:46 PM, Martin Kosek wrote: On 04/22/2014 01:38 PM, Petr Viktorin wrote: On 04/16/2014 05:56 PM, Simo Sorce wrote: On Wed, 2014-04-16 at 18:34 +0300, Alexander Bokovoy wrote: On Wed, 16 Apr 2014, Martin Kosek wrote: In general I am not sure all authenticated users need access to all this info. Alexander ? SSSD needs to read some of this information for subdomains support. That would be at least host/*@REALM who needs to access it. Can you please list exactly which ones are needed ? SSSD subdomains support needs: - objectclasses ipaNTTrustedDomain/ipaNTDomainAttrs - ipaNTFlatName - ipaNTSecurityIdentifier - ipaNTTrustedDomainSID - cn Question is - is there any added value in hiding part of the trust information from authenticated users? I.e. attributes like ipanttrustdirection, ipaNTTrustAttributes (what is the purpose of this attribute anyway?), SID blacklists... Yes. Some of those attributes are needed as internal detail of ipasam -- part of how Samba stores this information taken from specific DCE RPC structures. If yes, we would need to split this permission in 2 and have one for authenticated users and one for Trust Adminitrators and Trust Readers. Yes. Authenticated users shouldn't get any access to those details: ipantsupportedencryptiontypes ipanttrustattributes ipanttrustauthincoming ipanttrustauthoutgoing Ok. I assume that cn=adtrust agents,cn=sysaccounts,SUFFIX system group should then have this permission assigned so that samba can operate the attributes. 'adtrust agents' and 'trust administrators' should have read, modify, delete, and search on cn=trusts. Right. We will probably want to turn most of ACIs in install/updates/60-trusts.update in managed permissions (i.e. defined in trust.py) and make adtrust agents and trust admins it's members. I agree. +1 Simo. All right. Now I'm replacing the global anonymous read ACI; converting the others will come later. The existing agents/admins ACIs grant the 'read' (or 'all') right already. ipaIDRange is covered in the range plugin, so what's left for this patch is the ipaNTTrustedDomain/ipaNTDomainAttrs attributes. Does that sound reasonable? This is all that's needed from SSSD side, I just verified in sssd git. sssd indeed only uses these attributes: #define IPA_CN cn #define IPA_FLATNAME ipaNTFlatName #define IPA_SID ipaNTSecurityIdentifier #define IPA_TRUSTED_DOMAIN_SID ipaNTTrustedDomainSID So I am OK with the patch as is. However, with this ACI, regular users will not be able to show Trusts with command line even though they have access to the basic information: # ipa trust-find 0 trusts matched Number of entries returned 0 IMO trust command should be able to return the information that the user is allowed to see. I prepared a patch to make the read part of trust.py more resilient to missing attributes. Attached. With this patch enabled, I have this output as regular user: # ipa trust-find --- 1 trust matched --- Realm name: tbad.example.com Domain NetBIOS name: TBAD Domain Security Identifier: S-1-5-21-2997650941-1802118864-3094776726 Number of entries returned 1 # ipa trust-show tbad.example.com Realm name: tbad.example.com Domain NetBIOS name: TBAD Domain Security Identifier: S-1-5-21-2997650941-1802118864-3094776726 # ipa trustdomain-find tbad.example.com Domain name: child.tbad.example.com Domain NetBIOS name: CHILD Domain Security Identifier: S-1-5-21-972585150-1048339146-1910910075 Domain name: tbad.example.com Domain NetBIOS name: TBAD Domain Security Identifier: S-1-5-21-2997650941-1802118864-3094776726 Number of entries returned 2 The only bigger change I did was to filter trust root domains by ipaNTSecurityIdentifier and not ipaNTSIDBlacklistIncoming which is not available to everyone. Martin The patch looks good to me, but I think Alexander is better qualified to review it. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0537-0539 aci-update: Trim the admin write blacklist Add ACI for read-only admin attributes
On 04/25/2014 01:08 PM, Martin Kosek wrote: On 04/25/2014 01:01 PM, Petr Viktorin wrote: On 04/24/2014 05:15 PM, Simo Sorce wrote: On Thu, 2014-04-24 at 16:47 +0200, Martin Kosek wrote: On 04/24/2014 03:42 PM, Simo Sorce wrote: On Thu, 2014-04-24 at 15:18 +0200, Martin Kosek wrote: On 04/24/2014 02:28 PM, Simo Sorce wrote: On Thu, 2014-04-24 at 14:17 +0200, Martin Kosek wrote: On 04/24/2014 09:41 AM, Petr Viktorin wrote: On 04/23/2014 08:56 PM, Simo Sorce wrote: On Wed, 2014-04-23 at 20:37 +0200, Petr Viktorin wrote: Admin access to read-only attributes such as ipaUniqueId, memberOf, krbPrincipalName is provided by the anonymous read ACI, which will go away. This patch adds a blanket read ACI for these. I also moved some related ACIs to 20-aci.update. Previously krbPwdHistory was also readable by admins. I don't think we want to include that. Simo, should admins be allowed to read krbExtraData? Probably not necessary but there is nothing secret in it either. Simo. OK. I'm not a fan of hiding things from the admin, so no changes to the patch are necessary here. 536: As we are touching these ACIs, may it is a time to see the blacklist of attributes that admin cannot write and check if this is still wanted: ipaUniqueId - OK, generated by DS plugin memberOf - OK, generated by DS plugin serverHostName - I did not even find a place where we manipulate it, except host.py - remove from blacklist? What about this one? not sure, I did not work much on the hosts objects. Rob? Do you know? enrolledBy - OK, generated by DS plugin krbExtraData - OK, generated by DS plugin krbPrincipalName - why can't admin change it? It is filled by framework, I would not personally blacklist it It is changed by the ipa rename plugin when the user uid change, that's why we prevent the admin from explicitly change it. krbCanonicalName - same as krbPrincipalName Ok, in that case krbPrincipalName and krbCanonicalName should stay, right? They should be accessible by admin, yes. Note that we are now discussing write access. I.e. what attributes needs to stay in the admin's global write ACI blacklist and which can be removed - admin can write in them. IIUC, these should be only readable by admin, not writeable. krbPrincipalAliases - same as krbPrincipalName - we need this removed if we want to set aliases anyway Allow this one? This is one I wanted to eventually get rid of, Alexander seem to have introduced it, but we discussed in the past of a way to kill it. I forgot the details thouhg. Alexander did we open a ticket for this ? Ok, we may eventually get rid of it, but does it need to be blacklisted in admins global write ACI? krbPasswordExpiration - OK, generated by DS plugin krbLastPwdChange - OK, generated by DS plugin krbUPEnabled - not used, can we remove it? What about this one? We never use it. I read this as remove it from global admin write ACI blacklist. krbTicketPolicyReference - why cannot admin set it? Unclear why, probably should be able to. We may want to remove it from blacklist then. We never used it, but we should probably allow admin to modify Ok, let us remove it from global admin write ACI blacklist. krbPwdPolicyReference - why cannot admin set it? We assign password policy based on groups now, right ? Yup. I see no complains, i.e. I read it as remove it from global admin write ACI blacklist. krbPrincipalType - why cannot admin set it? Unused. So... allow this one? we never use it so we do not need to allow admins by default. My point was to limit admin write ACI blacklist to the bare minimum. Only to attributes that really needs to be blacklisted as they are operated by DS plugins - like memberOf and others. My proposal is to remove it from global admin write ACI blacklist given it is not used. Ack, I agree with your intent. Simo. If I understand correctly, we want to allow: - krbPrincipalAliases - krbPrincipalType - krbPwdPolicyReference - krbTicketPolicyReference - krbUPEnabled - serverHostName Here is the patch for that. The list looks good to me. Martin, just to make sure: 0536-0537 are good to push, right? One of the reasons why I wanted to prune the blacklist a bit was to make the Admin read ACI (Admin read-only attributes) simpler (read - shorter). So please also update this aci in 536. Ah, right. IMO, 536 and 538 can be squashed, but that's up to you. I tried, but I couldn't get the commit message to not read like two unrelated changes, which to me is a clear sign they shouldn't be squashed. (I thought about also split moving the ACIs and the modifications, but maybe that'd be too purist.) I renumbered 0536 to 0538 to keep the order they should be applied in. Entire patchset attached. -- Petr³ From 92a510d599760d2d3d3e97905eb41050bc6f276f Mon Sep 17 00:00:00 2001 From: Petr Viktorin pvikt...@redhat.com Date: Wed, 23 Apr 2014 19:09:31 +0200 Subject: [PATCH] test_ldap: Read a publicly
Re: [Freeipa-devel] [PATCH] 0537-0539 aci-update: Trim the admin write blacklist Add ACI for read-only admin attributes
On 04/25/2014 01:29 PM, Petr Viktorin wrote: On 04/25/2014 01:08 PM, Martin Kosek wrote: On 04/25/2014 01:01 PM, Petr Viktorin wrote: On 04/24/2014 05:15 PM, Simo Sorce wrote: On Thu, 2014-04-24 at 16:47 +0200, Martin Kosek wrote: On 04/24/2014 03:42 PM, Simo Sorce wrote: On Thu, 2014-04-24 at 15:18 +0200, Martin Kosek wrote: On 04/24/2014 02:28 PM, Simo Sorce wrote: On Thu, 2014-04-24 at 14:17 +0200, Martin Kosek wrote: On 04/24/2014 09:41 AM, Petr Viktorin wrote: On 04/23/2014 08:56 PM, Simo Sorce wrote: On Wed, 2014-04-23 at 20:37 +0200, Petr Viktorin wrote: Admin access to read-only attributes such as ipaUniqueId, memberOf, krbPrincipalName is provided by the anonymous read ACI, which will go away. This patch adds a blanket read ACI for these. I also moved some related ACIs to 20-aci.update. Previously krbPwdHistory was also readable by admins. I don't think we want to include that. Simo, should admins be allowed to read krbExtraData? Probably not necessary but there is nothing secret in it either. Simo. OK. I'm not a fan of hiding things from the admin, so no changes to the patch are necessary here. 536: As we are touching these ACIs, may it is a time to see the blacklist of attributes that admin cannot write and check if this is still wanted: ipaUniqueId - OK, generated by DS plugin memberOf - OK, generated by DS plugin serverHostName - I did not even find a place where we manipulate it, except host.py - remove from blacklist? What about this one? not sure, I did not work much on the hosts objects. Rob? Do you know? enrolledBy - OK, generated by DS plugin krbExtraData - OK, generated by DS plugin krbPrincipalName - why can't admin change it? It is filled by framework, I would not personally blacklist it It is changed by the ipa rename plugin when the user uid change, that's why we prevent the admin from explicitly change it. krbCanonicalName - same as krbPrincipalName Ok, in that case krbPrincipalName and krbCanonicalName should stay, right? They should be accessible by admin, yes. Note that we are now discussing write access. I.e. what attributes needs to stay in the admin's global write ACI blacklist and which can be removed - admin can write in them. IIUC, these should be only readable by admin, not writeable. krbPrincipalAliases - same as krbPrincipalName - we need this removed if we want to set aliases anyway Allow this one? This is one I wanted to eventually get rid of, Alexander seem to have introduced it, but we discussed in the past of a way to kill it. I forgot the details thouhg. Alexander did we open a ticket for this ? Ok, we may eventually get rid of it, but does it need to be blacklisted in admins global write ACI? krbPasswordExpiration - OK, generated by DS plugin krbLastPwdChange - OK, generated by DS plugin krbUPEnabled - not used, can we remove it? What about this one? We never use it. I read this as remove it from global admin write ACI blacklist. krbTicketPolicyReference - why cannot admin set it? Unclear why, probably should be able to. We may want to remove it from blacklist then. We never used it, but we should probably allow admin to modify Ok, let us remove it from global admin write ACI blacklist. krbPwdPolicyReference - why cannot admin set it? We assign password policy based on groups now, right ? Yup. I see no complains, i.e. I read it as remove it from global admin write ACI blacklist. krbPrincipalType - why cannot admin set it? Unused. So... allow this one? we never use it so we do not need to allow admins by default. My point was to limit admin write ACI blacklist to the bare minimum. Only to attributes that really needs to be blacklisted as they are operated by DS plugins - like memberOf and others. My proposal is to remove it from global admin write ACI blacklist given it is not used. Ack, I agree with your intent. Simo. If I understand correctly, we want to allow: - krbPrincipalAliases - krbPrincipalType - krbPwdPolicyReference - krbTicketPolicyReference - krbUPEnabled - serverHostName Here is the patch for that. The list looks good to me. Martin, just to make sure: 0536-0537 are good to push, right? One of the reasons why I wanted to prune the blacklist a bit was to make the Admin read ACI (Admin read-only attributes) simpler (read - shorter). So please also update this aci in 536. Ah, right. IMO, 536 and 538 can be squashed, but that's up to you. I tried, but I couldn't get the commit message to not read like two unrelated changes, which to me is a clear sign they shouldn't be squashed. (I thought about also split moving the ACIs and the modifications, but maybe that'd be too purist.) I renumbered 0536 to 0538 to keep the order they should be applied in. Entire patchset attached. I think this is fine, I also tested upgrade and it went well. ACK for all 3, pushed to master:
[Freeipa-devel] [PATCH] webui: regression - enable fields on idrange type change (add)
ID range adder dialog was not properly addressed in field binding
refactoring.
The usage of reset caused some weird loops.
https://fedorahosted.org/freeipa/ticket/4326
--
Petr Vobornik
From 9e9e72dc795156811662b5130ad58084a898974c Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Thu, 24 Apr 2014 16:37:38 +0200
Subject: [PATCH] webui: regression - enable fields on idrange type change
(add)
ID range adder was not properly addressed in field binding refactoring.
The usage of reset caused some weird loops.
https://fedorahosted.org/freeipa/ticket/4326
---
install/ui/src/freeipa/idrange.js | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/install/ui/src/freeipa/idrange.js b/install/ui/src/freeipa/idrange.js
index d92ba7359ad6af74f2e7df1ce72d93188f8660c5..c7dc5c6832a484060a18197ba567cfd0f7e6b42c 100644
--- a/install/ui/src/freeipa/idrange.js
+++ b/install/ui/src/freeipa/idrange.js
@@ -19,6 +19,7 @@
*/
define([
+'dojo/on',
'./ipa',
'./jquery',
'./phases',
@@ -27,7 +28,7 @@ define([
'./search',
'./association',
'./entity'],
-function(IPA, $, phases, reg) {
+function(on, IPA, $, phases, reg) {
var exp = IPA.idrange = {};
@@ -171,7 +172,7 @@ IPA.idrange_adder_policy = function(spec) {
}
function disable(field) {
-field.reset();
+field.set_value(['']); // avoid usage of reset() to break event handler loop
field.set_required(false);
field.set_enabled(false);
}
@@ -195,9 +196,9 @@ IPA.idrange_adder_policy = function(spec) {
require(secondarybaserid_f);
}
-type_f.widget.value_changed.attach(that.on_input_change);
-baserid_f.widget.value_changed.attach(that.on_input_change);
-secondarybaserid_f.widget.value_changed.attach(that.on_input_change);
+on(type_f, 'value-change', that.on_input_change);
+on(baserid_f, 'value-change', that.on_input_change);
+on(secondarybaserid_f, 'value-change', that.on_input_change);
};
that.on_input_change = function() {
@@ -206,9 +207,9 @@ IPA.idrange_adder_policy = function(spec) {
var secondarybaserid_f = that.container.fields.get_field('ipasecondarybaserid');
var trusteddomainsid_f = that.container.fields.get_field('ipanttrusteddomainsid');
-var type_v = type_f.save()[0];
-var baserid_v = baserid_f.save()[0] || '';
-var secondarybaserid_v = secondarybaserid_f.save()[0] || '';
+var type_v = type_f.get_value()[0];
+var baserid_v = baserid_f.get_value()[0] || '';
+var secondarybaserid_v = secondarybaserid_f.get_value()[0] || '';
var is_ad_range = (type_v === 'ipa-ad-trust' || type_v === 'ipa-ad-trust-posix');
--
1.9.0
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 587 webui-ci: adjust id range tests to new validator
SSIA
--
Petr Vobornik
From 66410a435d641a90da7bc0f525d5e73e3a5c549d Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Thu, 24 Apr 2014 17:24:59 +0200
Subject: [PATCH] webui-ci: adjust id range tests to new validator
---
ipatests/test_webui/task_range.py | 33 +++--
ipatests/test_webui/test_range.py | 27 +++
ipatests/test_webui/test_trust.py | 6 --
ipatests/test_webui/ui_driver.py | 9 +++--
4 files changed, 37 insertions(+), 38 deletions(-)
diff --git a/ipatests/test_webui/task_range.py b/ipatests/test_webui/task_range.py
index 4775078e7388078ccf4d6a59288388c3dd363ff5..3b9c84a96be00cbe556c04b7c29028c2b2f21d0c 100644
--- a/ipatests/test_webui/task_range.py
+++ b/ipatests/test_webui/task_range.py
@@ -32,8 +32,8 @@ class range_tasks(UI_driver):
result = self.execute_api_from_ui('idrange_find', [], {})
idranges = result['result']['result']
-id_shift = 0
-rid_shift = 0
+max_id = 0
+max_rid = 0
for idrange in idranges:
size = int(idrange['ipaidrangesize'][0])
@@ -50,16 +50,14 @@ class range_tasks(UI_driver):
secondary_base_rid = int(idrange['ipasecondarybaserid'][0])
rid_end = max(base_rid, secondary_base_rid) + size
-if id_shift id_end:
-id_shift = id_end + 100
+if max_id id_end:
+max_id = id_end + 100
-if rid_shift rid_end:
-rid_shift = rid_end + 100
+if max_rid rid_end:
+max_rid = rid_end + 100
-self.id_shift = id_shift
-self.rid_shift = rid_shift
-self.sec_rid_shift = rid_shift + 1000
-self.shift = 0
+self.max_id = max_id
+self.max_rid = max_rid
def get_sid(self):
result = self.execute_api_from_ui('trust_find', [], {})
@@ -85,17 +83,24 @@ class range_tasks(UI_driver):
def get_add_data(self, pkey, range_type='ipa-local', size=50, shift=100, sid=None):
-self.shift += shift
+base_id = self.max_id + shift
+self.max_id = base_id + size
+
+base_rid = self.max_rid + shift
+self.max_rid = base_rid + size
+
add = [
('textbox', 'cn', pkey),
-('textbox', 'ipabaseid', str(self.id_shift + self.shift)),
+('textbox', 'ipabaseid', str(base_id)),
('textbox', 'ipaidrangesize', str(size)),
-('textbox', 'ipabaserid', str(self.rid_shift + self.shift)),
+('textbox', 'ipabaserid', str(base_rid)),
('radio', 'iparangetype', range_type),
]
if not sid:
-add.append(('textbox', 'ipasecondarybaserid', str(self.sec_rid_shift + self.shift)))
+base_rid = self.max_rid + shift
+self.max_rid = base_rid + size
+add.append(('textbox', 'ipasecondarybaserid', str(base_rid)))
if sid:
add.append(('textbox', 'ipanttrusteddomainsid', sid))
diff --git a/ipatests/test_webui/test_range.py b/ipatests/test_webui/test_range.py
index 534cd1cdd20435aebf6fa5832fac68cbf717bf31..663ff42cb7e2e383d45b37d077cf2a21f006a7f4 100644
--- a/ipatests/test_webui/test_range.py
+++ b/ipatests/test_webui/test_range.py
@@ -41,6 +41,13 @@ class test_range(range_tasks):
def test_types(self):
Test range types
+
+Only 'local' and 'ipa-ad-trust' types are tested since range validation
+made quite hard to test the other types:
+
+- 'ipa-ad-trust-posix' can be tested only with subdomains.
+- 'ipa-ad-winsync' and 'ipa-ipa-trust' and are not supported yet
+ https://fedorahosted.org/freeipa/ticket/4323
self.init_app()
self.get_shifts()
@@ -73,28 +80,8 @@ class test_range(range_tasks):
self.add_record(ENTITY, data, navigate=False)
self.assert_record_value('Active Directory domain range', pkey_ad, column)
-add = self.get_add_data(pkey_posix, range_type='ipa-ad-trust-posix', sid=sid)
-data = self.get_data(pkey_posix, add_data=add)
-self.add_record(ENTITY, data, navigate=False)
-self.assert_record_value('Active Directory trust range with POSIX attributes', pkey_posix, column)
-
self.delete(trust_mod.ENTITY, [trust_data])
-
self.navigate_to_entity(ENTITY)
self.delete_record(pkey_ad)
-self.delete_record(pkey_posix)
-self.delete_record(trust_tasks.get_range_name())
-
-add = self.get_add_data(pkey_winsync, range_type='ipa-ad-winsync')
-data = self.get_data(pkey_winsync, add_data=add)
-self.add_record(ENTITY, data, navigate=False)
-self.assert_record_value('Active Directory winsync range', pkey_winsync, column)
-
-add = self.get_add_data(pkey_trust, range_type='ipa-ipa-trust')
-
[Freeipa-devel] [PATCH] Stop ntpd before running ntpdate
Hello, Here is a patch for https://fedorahosted.org/freeipa/ticket/3735. It seemed better to try to stop ntpd before running ntpdate rather than not running ntpdate if ntpd was already running. I believe this patch only applies to the ipa-3-3 branch as ntpdate is not used anymore in the master. Thanks, Gabe From 6375c439c62d1987841ac02748fd41ccf7f6346b Mon Sep 17 00:00:00 2001 From: Gabe redhatri...@gmail.com Date: Fri, 25 Apr 2014 08:08:41 -0600 Subject: [PATCH] ipa-client-install stop ntpd before running ntpdate - Stop the ntpd service before ntpdate is run https://fedorahosted.org/freeipa/ticket/3735 --- ipa-client/ipa-install/ipa-client-install | 8 1 file changed, 8 insertions(+) diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa-client/ipa-install/ipa-client-install index afed54e5ddbf5ed985b637f20ac61d8ab1632364..bf45a83cb60f19c226cfc88075b00062275bde71 100755 --- a/ipa-client/ipa-install/ipa-client-install +++ b/ipa-client/ipa-install/ipa-client-install @@ -2089,6 +2089,14 @@ def install(options, env, fstore, statestore): nolog = tuple() # First test out the kerberos configuration try: +# Stop NTP if it is running when a sync is attempted +try: +ipaservices.knownservices.ntpd.stop() +except Exception: +root_logger.info(Trying to %s the %s daemon before + + before running ntpdate. It must not be running., +ntpd_service_action, ntpd.service_name) + # Attempt to sync time with IPA server. # We assume that NTP servers are discoverable through SRV records in the DNS # If that fails, we try to sync directly with IPA server, assuming it runs NTP -- 1.9.0 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 18 webui otptoken test data added
Hi,
this patch adds some static test data for the webui otptoken part.
AdamFrom a119f23cde594a0c9a4a2bf3cb91d259c5ce06b1 Mon Sep 17 00:00:00 2001
From: Adam Misnyovszki amisn...@redhat.com
Date: Fri, 25 Apr 2014 16:33:11 +0200
Subject: [PATCH] webui OTP token test data added
---
install/ui/test/data/otptoken_add.json | 43 +++
install/ui/test/data/otptoken_batch_del.json | 14 +++
install/ui/test/data/otptoken_batch_mod.json | 34 +++
install/ui/test/data/otptoken_del.json | 11 +
install/ui/test/data/otptoken_find.json| 54
install/ui/test/data/otptoken_find_pkeys.json | 17
install/ui/test/data/otptoken_get_records.json | 57 ++
install/ui/test/data/otptoken_mod.json | 9
install/ui/test/data/otptoken_show.json| 51 +++
9 files changed, 290 insertions(+)
create mode 100644 install/ui/test/data/otptoken_add.json
create mode 100644 install/ui/test/data/otptoken_batch_del.json
create mode 100644 install/ui/test/data/otptoken_batch_mod.json
create mode 100644 install/ui/test/data/otptoken_del.json
create mode 100644 install/ui/test/data/otptoken_find.json
create mode 100644 install/ui/test/data/otptoken_find_pkeys.json
create mode 100644 install/ui/test/data/otptoken_get_records.json
create mode 100644 install/ui/test/data/otptoken_mod.json
create mode 100644 install/ui/test/data/otptoken_show.json
diff --git a/install/ui/test/data/otptoken_add.json b/install/ui/test/data/otptoken_add.json
new file mode 100644
index ..5b20d1271c51d6afc5ff80cdcab580be89ccb231
--- /dev/null
+++ b/install/ui/test/data/otptoken_add.json
@@ -0,0 +1,43 @@
+{
+error: null,
+id: null,
+result: {
+result: {
+dn: ipatokenuniqueid=footoken,cn=otp,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com,
+ipatokenmodel: [
+totp
+],
+ipatokenotpalgorithm: [
+sha1
+],
+ipatokenotpdigits: [
+6
+],
+ipatokenotpkey: [
+{
+__base64__: 2TUYXOVTaZf/Og==
+}
+],
+ipatokentotpclockoffset: [
+0
+],
+ipatokentotptimestep: [
+30
+],
+ipatokenuniqueid: [
+footoken
+],
+ipatokenvendor: [
+FreeIPA
+],
+objectclass: [
+top,
+ipatokentotp,
+ipatoken
+],
+uri: otpauth://totp/IDM.LAB.ENG.BRQ.REDHAT.COM:footoken?digits=6secret=3E2RQXHFKNUZP7Z2period=30algorithm=sha1issuer=IDM.LAB.ENG.BRQ.REDHAT.COM
+},
+summary: Added OTP token \footoken\,
+value: footoken
+}
+}
\ No newline at end of file
diff --git a/install/ui/test/data/otptoken_batch_del.json b/install/ui/test/data/otptoken_batch_del.json
new file mode 100644
index ..8fb6d701d2f4741922482127e54f9a9b6503d43c
--- /dev/null
+++ b/install/ui/test/data/otptoken_batch_del.json
@@ -0,0 +1,14 @@
+{
+error: null,
+id: null,
+result: {
+count: 1,
+results: [
+{
+error: footoken: OTP token not found,
+error_code: 4001,
+error_name: NotFound
+}
+]
+}
+}
\ No newline at end of file
diff --git a/install/ui/test/data/otptoken_batch_mod.json b/install/ui/test/data/otptoken_batch_mod.json
new file mode 100644
index ..63b99b684ee2ee8aaede06f4f5f6d8080c71fe8c
--- /dev/null
+++ b/install/ui/test/data/otptoken_batch_mod.json
@@ -0,0 +1,34 @@
+{
+error: null,
+id: null,
+result: {
+count: 1,
+results: [
+{
+error: null,
+result: {
+description: [
+Description
+],
+ipatokendisabled: [
+FALSE
+],
+ipatokenmodel: [
+totp
+],
+ipatokenowner: [
+admin
+],
+ipatokenuniqueid: [
+10bd43b5-3204-4695-9225-91064f6c77b3
+],
+ipatokenvendor: [
+FreeIPA
+]
+},
+summary: Modified OTP token \10bd43b5-3204-4695-9225-91064f6c77b3\,
+value: 10bd43b5-3204-4695-9225-91064f6c77b3
+}
+]
+}
+}
\ No newline at end of file
diff --git a/install/ui/test/data/otptoken_del.json b/install/ui/test/data/otptoken_del.json
new file mode 100644
index
[Freeipa-devel] [PATCH] 588 webui: fix switching between multiple_choice_section choices
- required indicators are not present for all sections except the last
- validation has wrong color for the same sections
There was only one layout for all choices. Layout should not be reused
because `create` method will reset layout's rows therefore it worked
properly only for the last choice.
https://fedorahosted.org/freeipa/ticket/4327
--
Petr Vobornik
From e76604f82bacf23c51c4bc8821421aaa657ea0de Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Fri, 25 Apr 2014 19:15:52 +0200
Subject: [PATCH] webui: fix switching between multiple_choice_section choices
- required indicators are not present for all sections except the last
- validation has wrong color for the same sections
There was only one layout for all choices. Layout should not be reused
because `create` method will reset layout's rows therefore it worked
properly only for the last choice.
https://fedorahosted.org/freeipa/ticket/4327
---
install/ui/src/freeipa/widget.js | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/install/ui/src/freeipa/widget.js b/install/ui/src/freeipa/widget.js
index 568696b5b7a3f74572d6102e0cfb454101bb1b7c..bb668c371857a34e7a398fc4d26df7fa05ba9361 100644
--- a/install/ui/src/freeipa/widget.js
+++ b/install/ui/src/freeipa/widget.js
@@ -4534,7 +4534,7 @@ IPA.multiple_choice_section = function(spec) {
var that = IPA.composite_widget(spec);
that.choices = $.ordered_map().put_array(spec.choices, 'name');
-that.layout = IPA.build(spec.layout || IPA.fluid_layout);
+that.layout = spec.layout || IPA.fluid_layout;
that.create = function(container) {
@@ -4563,7 +4563,7 @@ IPA.multiple_choice_section = function(spec) {
that.create_choice = function(choice) {
-var widgets, i, widget, field, section, choice_el, header, radio,
+var widgets, i, widget, field, section, layout, choice_el, header, radio,
enabled, radio_id;
widgets = [];
@@ -4610,7 +4610,8 @@ IPA.multiple_choice_section = function(spec) {
'for': radio_id
}).appendTo(header);
-section = that.layout.create(widgets);
+layout = IPA.build(that.layout);
+section = layout.create(widgets);
section.appendTo(choice_el);
choice_el.appendTo(that.choice_container);
};
--
1.9.0
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
