Re: [Freeipa-devel] [PATCH] Make pwd-extop aware of new ipaNTHash attribute
On Mon, 28 Nov 2011, Sumit Bose wrote: Hi, in IPAv3 we introduce a new attribute 'ipaNTHash' to store the NT hash. Currently the plugin handling the change password extended operation only sets and updates 'sambaNTPassword'. This patch add support for the new attribute without removing the support for the old one. ACK One possible enhancement I would make is to get attribute names as constant defines and re-use them across the code. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Add ipasam samba passdb backend
On Wed, 30 Nov 2011, Martin Kosek wrote: On Wed, 2011-11-30 at 10:11 +0100, Sumit Bose wrote: On Tue, Nov 29, 2011 at 11:25:41PM +0200, Alexander Bokovoy wrote: On Tue, 29 Nov 2011, Sumit Bose wrote: @@ -199,10 +216,11 @@ class ADTRUSTInstance(service.Service): self.admin_conn.addEntry(entry) entry = ipaldap.Entry(self.smb_dom_dn) -entry.setValues(objectclass, [sambaDomain, nsContainer]) +entry.setValues(objectclass, [self.OBJC_DOMAIN, nsContainer]) entry.setValues(cn, self.domain_name) -entry.setValues(sambaDomainName, self.netbios_name) -entry.setValues(sambaSID, self.__gen_sid_string()) +entry.setValues(self.ATTR_FLAT_NAME, self.netbios_name) +entry.setValues(self.ATTR_SID, self.__gen_sid_string()) +entry.setValues(self.ATTR_GUID, str(uuid.uuid4())) #TODO: which MAY attributes do we want to set ? self.admin_conn.add_s(entry) Could you please also convert this one to .addEntry(entry)? I think it is the last one left... This is fixed in freeipa-sbose-0012-3-Fix-some-pylint-warnings.patch. Martin, shall I extract the add_s-addEntry changes into a separate patch so the they can reviewed indepently of the 6 ipasam patches? bye, Sumit I think it is OK to review (and push) them in a scope of your patch 0012-3, we don't have to divide them. Yes. ACK then. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Session design document
On Sat, 2011-12-03 at 14:06 -0500, Dmitri Pal wrote: On 12/01/2011 08:48 PM, Simo Sorce wrote: On Thu, 2011-12-01 at 19:31 -0500, John Dennis wrote: On 12/01/2011 06:54 PM, Dmitri Pal wrote: Seems reasonable. I agree with pros and cons and suggestions but I am not the person to make the final approval. Simo? Question for John: Is there any benefit for CLI or it is for UI only? Currently it would benefit the UI only. That's mostly because there is no mechanism in the cli to cache the session ID. Adding that wouldn't be too difficult except for the issue of how to store the session ID securely, it would have to be written to a file (unlike with a browser which is supposed to hold session cookies in memory). Is there an ability to add a data item like this to the user's kerberos credential cache? Yes we could create a fake key and stick the session id in it. That was the trick we proposed using when this question was raised a few months ago during a conference call on the matter. Simo. Can we please then extend the design to include this? Another approach (on Linux only) would be to have the CLI stuff the session key into the kernel keyring. It would be secure and would be capable of outliving the TGT life (if the session expiration is longer than the TGT expiration). signature.asc Description: This is a digitally signed message part ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Session design document
On Mon, 2011-12-05 at 09:42 -0500, Dmitri Pal wrote: On 12/05/2011 09:33 AM, Stephen Gallagher wrote: On Sat, 2011-12-03 at 14:06 -0500, Dmitri Pal wrote: On 12/01/2011 08:48 PM, Simo Sorce wrote: On Thu, 2011-12-01 at 19:31 -0500, John Dennis wrote: On 12/01/2011 06:54 PM, Dmitri Pal wrote: Seems reasonable. I agree with pros and cons and suggestions but I am not the person to make the final approval. Simo? Question for John: Is there any benefit for CLI or it is for UI only? Currently it would benefit the UI only. That's mostly because there is no mechanism in the cli to cache the session ID. Adding that wouldn't be too difficult except for the issue of how to store the session ID securely, it would have to be written to a file (unlike with a browser which is supposed to hold session cookies in memory). Is there an ability to add a data item like this to the user's kerberos credential cache? Yes we could create a fake key and stick the session id in it. That was the trick we proposed using when this question was raised a few months ago during a conference call on the matter. Simo. Can we please then extend the design to include this? Another approach (on Linux only) would be to have the CLI stuff the session key into the kernel keyring. It would be secure and would be capable of outliving the TGT life (if the session expiration is longer than the TGT expiration). We support CLI only on Linux so this is not an issue. But it would not work cross multiple CLI commands as they are different processes and AFAIU only the process that put the data into the keyring would be able to fetch it unless we provide a special IPA shell that keeps one process and executes batch inside it. Am I wrong? Yes, you are wrong :) The keyring can be configured to be limited to either user or user and a specific process ID. We do the latter in SSSD, but that's a recent change. Previously we were restricting it only by user. signature.asc Description: This is a digitally signed message part ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 051 Search facets show translated boolean values
Created format method for getting translated messages for boolean values
- IPA.boolean_column_format.
Used in hosts, sudo rules, hbac rules.
https://fedorahosted.org/freeipa/ticket/2027
--
Petr Vobornik
From df21f935ae6ce05ed0a4709aade99d9e94d2f810 Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Mon, 5 Dec 2011 16:23:38 +0100
Subject: [PATCH] Search facets show translated boolean values
Created format method for getting translated messages for boolean values - IPA.boolean_column_format.
Used in hosts, sudo rules, hbac rules.
https://fedorahosted.org/freeipa/ticket/2027
---
install/ui/hbac.js |5 -
install/ui/host.js |3 ++-
install/ui/sudo.js |5 -
install/ui/widget.js | 17 +
4 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/install/ui/hbac.js b/install/ui/hbac.js
index cf13e459ee2128aefd0e539ac4e4aa86950c069b..82d92c5c53a19fffb8b8bf6a52bb340c32b85d85 100644
--- a/install/ui/hbac.js
+++ b/install/ui/hbac.js
@@ -39,7 +39,10 @@ IPA.hbac.rule_entity = function(spec) {
search_all: true,
columns: [
'cn',
-'ipaenabledflag',
+{
+name: 'ipaenabledflag',
+format: IPA.boolean_column_format
+},
'description'
]
}).
diff --git a/install/ui/host.js b/install/ui/host.js
index 654b34de1ad99c3b80429b31c943d5d831940d6d..4da22df6fde52c6c9974edf1eefe263c62716df4 100644
--- a/install/ui/host.js
+++ b/install/ui/host.js
@@ -38,7 +38,8 @@ IPA.host.entity = function(spec) {
'description',
{
name: 'has_keytab',
-label: IPA.messages.objects.host.enrolled
+label: IPA.messages.objects.host.enrolled,
+format: IPA.boolean_column_format
}
]
}).
diff --git a/install/ui/sudo.js b/install/ui/sudo.js
index 6e7aeca26792ccc19268b436ece2ddf12b4812b0..5163d152621bb09c66571f5efe15f4039c9f6cda 100644
--- a/install/ui/sudo.js
+++ b/install/ui/sudo.js
@@ -37,7 +37,10 @@ IPA.sudo.rule_entity = function(spec) {
params.builder.search_facet({
columns: [
'cn',
-'ipaenabledflag',
+{
+name: 'ipaenabledflag',
+format: IPA.boolean_column_format
+},
'description'
]
}).
diff --git a/install/ui/widget.js b/install/ui/widget.js
index 5b50d8f16d339aaee499e1e00280eefe20a51545..b8fcbdeb0a17b96678bb5cbca9b88a4688d864bc 100644
--- a/install/ui/widget.js
+++ b/install/ui/widget.js
@@ -902,6 +902,23 @@ IPA.textarea_widget = function (spec) {
return that;
};
+IPA.boolean_column_format = function(value) {
+
+if (value instanceof Array) {
+value = value[0];
+}
+
+if (value === false || value === 'FALSE' || value === 'false') {
+return IPA.messages['false'];
+}
+
+if (value === true || value === 'TRUE' || value === 'true') {
+return IPA.messages['true'];
+}
+
+return '';
+};
+
/*
The entity name must be set in the spec either directly or via entity.name
*/
--
1.7.6.4
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Q: dnsclient portability
On Fri, 2011-12-02 at 10:20 -0500, John Dennis wrote: On 12/02/2011 07:58 AM, Alexander Bokovoy wrote: Hi, I'm working on ticket https://fedorahosted.org/freeipa/ticket/1837 which concerns portability of ipapython.dnsclient module. ipapython.dnsclient module uses acutil module to perform 'res_send(3)' call provided by libresolv. acutil implements bindings to two system calls (res_send() and getusershell()) and belongs to authconfig package. The total size of acutil module source code is ~100 lines of C code. Now, authconfig package is not available beyond Fedora/RHEL distributions and, in particular, it is not available in Ubuntu / GNU/Debian Linux. It means ipapython.dnsclient will fail on those platforms and a way of getting around the issue needs to be found. So far, there are two options: 1. Extract acutil module from authconfig and supply it with freeipa-python in a manner similar to default_encoding module. This is 'cheapest' solution in a sense we only interested in bindings to res_send(3). FreeIPA client code then will be self-contained and would not depend on authconfig availability (platform portability code already allows to re-implement authconfig implementation). 2. Port ipapython.dnsclient to use dnspython module if acutil is not available. This module, available from http://www.dnspython.org/, can be found in Fedora, GNU/Debian Linux, Ubuntu and many other distributions. It is python-only resolver providing a super-set of ipapython.dnsclient features. The downside of the first approach is a need to distribute and maintain another CPython extension. Though the code is straight forward and simple enough, it is still a separate maintenance burden. The downside of the second approach is to write a bridge code between ipapython.dnsclient API and dnspython API. They are different enough so that remapping of fields in objects resulting from a query is needed. I've started to implement the bridge code myself but it is quickly getting to the level of effort original ipapython.dnsclient has (due to API differences in attributes names) and that means it is probably not worth it. I think the second approach is better, here is my reasoning: * If we rebuilt acutil it would make more sense to package it an actual package, not just another IPA CPython module, this would be more flexible and other could use it, but ... * acutil seems incomplete and an odd mix of just 2 functions, probably the minimum needed but not general (I don't know the API's so I might be wrong on that score) * We really don't want to maintain YAP (Yet Another Package) * dnspython seems more complete, widely used, has other maintainers and support we can leverage. (Should we have used it in the first place) * Since dnspython is a superset and once we get ipapython.dnsclient ported to it maybe we'll discover we can then easily user other features dnspython provides. Anyway, tough call, the right answer is not entirely obvious, just my 2 cents. I like second approach more too. Although I think the best solution here would be to discard ipapython.dnsclient as is and use dnspython directly in our code. ipapython.dnsclient is not used on that many places in our code anyway. This way, we wouldn't have use our artificial dnsclient API in the proposed bridge but rather use (more standard) dnspython API and have access to all its native functionality. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Q: dnsclient portability
On Mon, 05 Dec 2011, Martin Kosek wrote: On Fri, 2011-12-02 at 10:20 -0500, John Dennis wrote: On 12/02/2011 07:58 AM, Alexander Bokovoy wrote: Hi, I'm working on ticket https://fedorahosted.org/freeipa/ticket/1837 which concerns portability of ipapython.dnsclient module. ipapython.dnsclient module uses acutil module to perform 'res_send(3)' call provided by libresolv. acutil implements bindings to two system calls (res_send() and getusershell()) and belongs to authconfig package. The total size of acutil module source code is ~100 lines of C code. Now, authconfig package is not available beyond Fedora/RHEL distributions and, in particular, it is not available in Ubuntu / GNU/Debian Linux. It means ipapython.dnsclient will fail on those platforms and a way of getting around the issue needs to be found. So far, there are two options: 1. Extract acutil module from authconfig and supply it with freeipa-python in a manner similar to default_encoding module. This is 'cheapest' solution in a sense we only interested in bindings to res_send(3). FreeIPA client code then will be self-contained and would not depend on authconfig availability (platform portability code already allows to re-implement authconfig implementation). 2. Port ipapython.dnsclient to use dnspython module if acutil is not available. This module, available from http://www.dnspython.org/, can be found in Fedora, GNU/Debian Linux, Ubuntu and many other distributions. It is python-only resolver providing a super-set of ipapython.dnsclient features. The downside of the first approach is a need to distribute and maintain another CPython extension. Though the code is straight forward and simple enough, it is still a separate maintenance burden. The downside of the second approach is to write a bridge code between ipapython.dnsclient API and dnspython API. They are different enough so that remapping of fields in objects resulting from a query is needed. I've started to implement the bridge code myself but it is quickly getting to the level of effort original ipapython.dnsclient has (due to API differences in attributes names) and that means it is probably not worth it. I think the second approach is better, here is my reasoning: * If we rebuilt acutil it would make more sense to package it an actual package, not just another IPA CPython module, this would be more flexible and other could use it, but ... * acutil seems incomplete and an odd mix of just 2 functions, probably the minimum needed but not general (I don't know the API's so I might be wrong on that score) * We really don't want to maintain YAP (Yet Another Package) * dnspython seems more complete, widely used, has other maintainers and support we can leverage. (Should we have used it in the first place) * Since dnspython is a superset and once we get ipapython.dnsclient ported to it maybe we'll discover we can then easily user other features dnspython provides. Anyway, tough call, the right answer is not entirely obvious, just my 2 cents. I like second approach more too. Although I think the best solution here would be to discard ipapython.dnsclient as is and use dnspython directly in our code. ipapython.dnsclient is not used on that many places in our code anyway. This way, we wouldn't have use our artificial dnsclient API in the proposed bridge but rather use (more standard) dnspython API and have access to all its native functionality. Hm. Good idea. This though will have a toll for platforms where dnspython is not yet available like various Red Hat Enterprise Linux versions... -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Q: dnsclient portability
On Mon, 2011-12-05 at 18:09 +0200, Alexander Bokovoy wrote: On Mon, 05 Dec 2011, Martin Kosek wrote: On Fri, 2011-12-02 at 10:20 -0500, John Dennis wrote: On 12/02/2011 07:58 AM, Alexander Bokovoy wrote: Hi, I'm working on ticket https://fedorahosted.org/freeipa/ticket/1837 which concerns portability of ipapython.dnsclient module. ipapython.dnsclient module uses acutil module to perform 'res_send(3)' call provided by libresolv. acutil implements bindings to two system calls (res_send() and getusershell()) and belongs to authconfig package. The total size of acutil module source code is ~100 lines of C code. Now, authconfig package is not available beyond Fedora/RHEL distributions and, in particular, it is not available in Ubuntu / GNU/Debian Linux. It means ipapython.dnsclient will fail on those platforms and a way of getting around the issue needs to be found. So far, there are two options: 1. Extract acutil module from authconfig and supply it with freeipa-python in a manner similar to default_encoding module. This is 'cheapest' solution in a sense we only interested in bindings to res_send(3). FreeIPA client code then will be self-contained and would not depend on authconfig availability (platform portability code already allows to re-implement authconfig implementation). 2. Port ipapython.dnsclient to use dnspython module if acutil is not available. This module, available from http://www.dnspython.org/, can be found in Fedora, GNU/Debian Linux, Ubuntu and many other distributions. It is python-only resolver providing a super-set of ipapython.dnsclient features. The downside of the first approach is a need to distribute and maintain another CPython extension. Though the code is straight forward and simple enough, it is still a separate maintenance burden. The downside of the second approach is to write a bridge code between ipapython.dnsclient API and dnspython API. They are different enough so that remapping of fields in objects resulting from a query is needed. I've started to implement the bridge code myself but it is quickly getting to the level of effort original ipapython.dnsclient has (due to API differences in attributes names) and that means it is probably not worth it. I think the second approach is better, here is my reasoning: * If we rebuilt acutil it would make more sense to package it an actual package, not just another IPA CPython module, this would be more flexible and other could use it, but ... * acutil seems incomplete and an odd mix of just 2 functions, probably the minimum needed but not general (I don't know the API's so I might be wrong on that score) * We really don't want to maintain YAP (Yet Another Package) * dnspython seems more complete, widely used, has other maintainers and support we can leverage. (Should we have used it in the first place) * Since dnspython is a superset and once we get ipapython.dnsclient ported to it maybe we'll discover we can then easily user other features dnspython provides. Anyway, tough call, the right answer is not entirely obvious, just my 2 cents. I like second approach more too. Although I think the best solution here would be to discard ipapython.dnsclient as is and use dnspython directly in our code. ipapython.dnsclient is not used on that many places in our code anyway. This way, we wouldn't have use our artificial dnsclient API in the proposed bridge but rather use (more standard) dnspython API and have access to all its native functionality. Hm. Good idea. This though will have a toll for platforms where dnspython is not yet available like various Red Hat Enterprise Linux versions... RHEL can ship a version that bundles dnspython, we just need a conditional on import so that we import from ipasomething.dnspython if regular dnspython is not available. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Q: dnsclient portability
On Mon, 05 Dec 2011, Simo Sorce wrote: I like second approach more too. Although I think the best solution here would be to discard ipapython.dnsclient as is and use dnspython directly in our code. ipapython.dnsclient is not used on that many places in our code anyway. This way, we wouldn't have use our artificial dnsclient API in the proposed bridge but rather use (more standard) dnspython API and have access to all its native functionality. Hm. Good idea. This though will have a toll for platforms where dnspython is not yet available like various Red Hat Enterprise Linux versions... RHEL can ship a version that bundles dnspython, we just need a conditional on import so that we import from ipasomething.dnspython if regular dnspython is not available. Ok. From my perspective it is also much simpler to turn around and fix usage of ipapython.dnsclient rather than mimic it on top of dnspython. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 32-47 #2040, #1515 Refactor UI widgets
On 12/5/2011 7:41 AM, Petr Vobornik wrote: All tests passed. ACK 32-47, 49-1, 50. Pushed to master. YAY! -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 051 Search facets show translated boolean values
On 12/5/2011 9:37 AM, Petr Vobornik wrote: Created format method for getting translated messages for boolean values - IPA.boolean_column_format. Used in hosts, sudo rules, hbac rules. https://fedorahosted.org/freeipa/ticket/2027 The patch works, so it's ACKed. There are a few suggestions but they can be done later: 1. It might be better to name the function IPA.boolean_format because we can use it for other things too, not just inside a column. 2. The value can be normalized using toLowerCase() before comparison. 3. If the value doesn't match true/false it can return the original value instead of empty string. -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 051 Search facets show translated boolean values
On 12/05/2011 12:27 PM, Endi Sukma Dewata wrote: On 12/5/2011 9:37 AM, Petr Vobornik wrote: Created format method for getting translated messages for boolean values - IPA.boolean_column_format. Used in hosts, sudo rules, hbac rules. https://fedorahosted.org/freeipa/ticket/2027 The patch works, so it's ACKed. There are a few suggestions but they can be done later: 1. It might be better to name the function IPA.boolean_format because we can use it for other things too, not just inside a column. 2. The value can be normalized using toLowerCase() before comparison. 3. If the value doesn't match true/false it can return the original value instead of empty string. Can we make this the default handling for boolean columns? ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Q: dnsclient portability
Alexander Bokovoy wrote: On Mon, 05 Dec 2011, Martin Kosek wrote: On Fri, 2011-12-02 at 10:20 -0500, John Dennis wrote: On 12/02/2011 07:58 AM, Alexander Bokovoy wrote: Hi, I'm working on ticket https://fedorahosted.org/freeipa/ticket/1837 which concerns portability of ipapython.dnsclient module. ipapython.dnsclient module uses acutil module to perform 'res_send(3)' call provided by libresolv. acutil implements bindings to two system calls (res_send() and getusershell()) and belongs to authconfig package. The total size of acutil module source code is ~100 lines of C code. Now, authconfig package is not available beyond Fedora/RHEL distributions and, in particular, it is not available in Ubuntu / GNU/Debian Linux. It means ipapython.dnsclient will fail on those platforms and a way of getting around the issue needs to be found. So far, there are two options: 1. Extract acutil module from authconfig and supply it with freeipa-python in a manner similar to default_encoding module. This is 'cheapest' solution in a sense we only interested in bindings to res_send(3). FreeIPA client code then will be self-contained and would not depend on authconfig availability (platform portability code already allows to re-implement authconfig implementation). 2. Port ipapython.dnsclient to use dnspython module if acutil is not available. This module, available from http://www.dnspython.org/, can be found in Fedora, GNU/Debian Linux, Ubuntu and many other distributions. It is python-only resolver providing a super-set of ipapython.dnsclient features. The downside of the first approach is a need to distribute and maintain another CPython extension. Though the code is straight forward and simple enough, it is still a separate maintenance burden. The downside of the second approach is to write a bridge code between ipapython.dnsclient API and dnspython API. They are different enough so that remapping of fields in objects resulting from a query is needed. I've started to implement the bridge code myself but it is quickly getting to the level of effort original ipapython.dnsclient has (due to API differences in attributes names) and that means it is probably not worth it. I think the second approach is better, here is my reasoning: * If we rebuilt acutil it would make more sense to package it an actual package, not just another IPA CPython module, this would be more flexible and other could use it, but ... * acutil seems incomplete and an odd mix of just 2 functions, probably the minimum needed but not general (I don't know the API's so I might be wrong on that score) * We really don't want to maintain YAP (Yet Another Package) * dnspython seems more complete, widely used, has other maintainers and support we can leverage. (Should we have used it in the first place) * Since dnspython is a superset and once we get ipapython.dnsclient ported to it maybe we'll discover we can then easily user other features dnspython provides. Anyway, tough call, the right answer is not entirely obvious, just my 2 cents. I like second approach more too. Although I think the best solution here would be to discard ipapython.dnsclient as is and use dnspython directly in our code. ipapython.dnsclient is not used on that many places in our code anyway. This way, we wouldn't have use our artificial dnsclient API in the proposed bridge but rather use (more standard) dnspython API and have access to all its native functionality. Hm. Good idea. This though will have a toll for platforms where dnspython is not yet available like various Red Hat Enterprise Linux versions... I think this is why we stuck with acutil. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] What is the status of the patches/tickets?
Hi These have patches on the list: https://fedorahosted.org/freeipa/ticket/1496 https://fedorahosted.org/freeipa/ticket/1827 These tickets depend on external work: https://fedorahosted.org/freeipa/ticket/2103 https://fedorahosted.org/freeipa/ticket/2117 -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] What is the status of the patches/tickets?
Dmitri Pal wrote: Hi These have patches on the list: https://fedorahosted.org/freeipa/ticket/1496 NACKd on 12/2 https://fedorahosted.org/freeipa/ticket/1827 Needs a rebase and I had a question/suggestion. I did the reviews Friday afternoon after Alexander's day had ended. He'll take a look when he gets back on Wed. These tickets depend on external work: https://fedorahosted.org/freeipa/ticket/2103 In updates-testing now awaiting feedback and karma. https://fedorahosted.org/freeipa/ticket/2117 This handles some of the dogtag upgrade issues but not specifically the profile problem I outlined. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] minor cleanup
Straightforward cleanup.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
From 1da9fb9c63d77fe9c30d26ae1ed376c74f7bf93a Mon Sep 17 00:00:00 2001
From: Simo Sorce sso...@redhat.com
Date: Mon, 5 Dec 2011 15:54:27 -0500
Subject: [PATCH] ipa-kdb: return properly when no PAC is available
---
daemons/ipa-kdb/ipa_kdb_mspac.c | 13 +++--
1 files changed, 3 insertions(+), 10 deletions(-)
diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c
index 62b11becf2fa94cf88e9edf221ece36def758b6f..74eca53367922d69450718fe523ec67f3cdac450 100644
--- a/daemons/ipa-kdb/ipa_kdb_mspac.c
+++ b/daemons/ipa-kdb/ipa_kdb_mspac.c
@@ -696,18 +696,11 @@ krb5_error_code ipadb_sign_authdata(krb5_context context,
goto done;
}
}
-#if 0
-if (pac == NULL client != NULL) {
-code = ks_get_pac(context, client, pac);
-if (code != 0) {
-goto done;
-}
-}
-#endif
if (pac == NULL) {
-kerr = KRB5_PLUGIN_OP_NOTSUPP;
-/*kerr = KRB5_KDB_DBTYPE_NOSUP; */
+/* No PAC to deal with, proceed */
+*signed_auth_data = NULL;
+kerr = 0;
goto done;
}
--
1.7.7.1
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] Implement support for S4U2Proxy delegation in IPA
On Fri, 2011-12-02 at 10:10 -0500, Simo Sorce wrote:
On Fri, 2011-12-02 at 09:27 -0500, Rob Crittenden wrote:
Simo Sorce wrote:
Hello all,
with this set of patches it is possible to allow constrained delegation
of credentials so that a service can impersonate a user when
[..]
In the third patch in ipadb_get_delegation_acl() you can just fall
through to the return.
Removed useless check.
I also noticed I had added the prototype declaration for the new vtable
function in the 2nd patch instead of the 3rd where it belongs by
mistake.
So I fixed that too.
I think the content of this e-mail should be added as a README to the
source tree.
Ok, I dumped and adapted the email content into a README file and added
it to the third patch.
I also fixed the patch names as per policy.
Simo.
We have discovered a few issues w/ MIT 1.9 and s4u2proxy used outside of
the 'artificial' test done by kvno.
I pushed a patch to handle part of the problem as a new krb5 package in
ipa-devel.
Soon we will have a patch for mod_auth_kerb that handles an issue there.
But we still have an unresolved issue when using the adtrust
functionality and our KDC releases PACs.
The attached patch can be used to deal with that case. As you can see
this is not intended for production, but can be used until we have a
better fix on the KDC side.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
From 33aebb5702fd77926340d1d0fb6556299a3831c0 Mon Sep 17 00:00:00 2001
From: Simo Sorce sso...@redhat.com
Date: Mon, 5 Dec 2011 15:46:59 -0500
Subject: [PATCH] ipa-kdb: temporary workaround for s4u2proxy ops
---
daemons/ipa-kdb/ipa_kdb_mspac.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c
index 160974ceb9cede21a3709316551fa5e1f1c5d5df..62b11becf2fa94cf88e9edf221ece36def758b6f 100644
--- a/daemons/ipa-kdb/ipa_kdb_mspac.c
+++ b/daemons/ipa-kdb/ipa_kdb_mspac.c
@@ -683,7 +683,11 @@ krb5_error_code ipadb_sign_authdata(krb5_context context,
}
}
-if (!is_as_req) {
+if (!is_as_req
+!(flags KRB5_KDB_FLAG_CONSTRAINED_DELEGATION)) {
+/* FIXME: flags check is temporary,
+ * remove once KDC code properly passes us keys for s4u2 ops */
+/* WARNING: THIS IS A SECURITY ISSUE, DO NOT SHIP WITH THIS HACK */
kerr = ipadb_verify_pac(context, flags,
ks_client_princ, client,
server_key, krbtgt_key,
--
1.7.7.1
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 316 Added support for radio buttons in table widget.
On 11/21/2011 12:18 PM, Endi Sukma Dewata wrote:
The table widget has been modified to support single-valued attribute
using radio buttons needed by some facets in HBAC Test. The widget now
uses 'pagination' flag to determine whether to show the pagination
control. The test data has also been updated.
Ticket #388
Updated patch attached.
--
Endi S. Dewata
From e577864b76377c9f0cdf86ed6959cdc976344420 Mon Sep 17 00:00:00 2001
From: Endi Sukma Dewata edew...@redhat.com
Date: Thu, 17 Nov 2011 11:25:09 -0600
Subject: [PATCH] Added support for radio buttons in table widget.
The table widget has been modified to support single-valued attribute
using radio buttons needed by some facets in HBAC Test. The widget now
uses 'pagination' flag to determine whether to show the pagination
control. The test data has also been updated.
Ticket #388
---
install/ui/facet.js |3 +-
install/ui/ipa.css|6 +-
install/ui/test/data/user_find_pkeys.json | 294 -
install/ui/widget.js | 103 ++-
4 files changed, 354 insertions(+), 52 deletions(-)
diff --git a/install/ui/facet.js b/install/ui/facet.js
index e4377151bcd5bf13adc39da4ceb6ca4f5221bc86..3a1ae92edc6b20515fc29627b32c2d1442aaa0ac 100644
--- a/install/ui/facet.js
+++ b/install/ui/facet.js
@@ -391,7 +391,6 @@ IPA.table_facet = function(spec) {
var that = IPA.facet(spec);
that.managed_entity_name = spec.managed_entity_name || that.entity.name;
-that.page_length = spec.page_length === undefined ? 20 : spec.page_length;
that.pagination = spec.pagination === undefined ? true : spec.pagination;
that.search_all = spec.search_all;
@@ -509,7 +508,7 @@ IPA.table_facet = function(spec) {
name: entity.metadata.primary_key,
label: entity.metadata.label,
entity: entity,
-page_length: that.page_length,
+pagination: true,
search_all: that.search_all,
scrollable: true,
selectable: that.selectable !that.read_only
diff --git a/install/ui/ipa.css b/install/ui/ipa.css
index d9b547575510e2b54acc98b8d3c0019a7e53bcca..c1391a4ea5db0c17e968dfbd3ad0016821982ec2 100644
--- a/install/ui/ipa.css
+++ b/install/ui/ipa.css
@@ -709,15 +709,15 @@ span.main-nav-off a:visited {
margin-right: 4em;
}
-.search-table span[name=pagination] {
+.search-table .pagination-control {
float: right;
}
-.search-table span[name=pagination] a {
+.search-table .pagination-control a {
cursor:pointer;
}
-.search-table span[name=pagination] input[name=current_page] {
+.search-table .pagination-control input[name=current_page] {
width: 22px;
}
diff --git a/install/ui/test/data/user_find_pkeys.json b/install/ui/test/data/user_find_pkeys.json
index 1669d249e9d677b6bee49d47e636c48199018945..00bbfb3e971fa5a4e3d2bbee0e075765523949dd 100644
--- a/install/ui/test/data/user_find_pkeys.json
+++ b/install/ui/test/data/user_find_pkeys.json
@@ -2,7 +2,7 @@
error: null,
id: null,
result: {
-count: 200,
+count: 248,
result: [
{
dn: uid=abarrett,cn=users,cn=accounts,dc=example,dc=com,
@@ -47,6 +47,12 @@
]
},
{
+dn: uid=ajennings,cn=users,cn=accounts,dc=example,dc=com,
+uid: [
+ajennings
+]
+},
+{
dn: uid=aobrien,cn=users,cn=accounts,dc=example,dc=com,
uid: [
aobrien
@@ -95,6 +101,12 @@
]
},
{
+dn: uid=bbarber,cn=users,cn=accounts,dc=example,dc=com,
+uid: [
+bbarber
+]
+},
+{
dn: uid=bbauer,cn=users,cn=accounts,dc=example,dc=com,
uid: [
bbauer
@@ -107,6 +119,12 @@
]
},
{
+dn: uid=bbush,cn=users,cn=accounts,dc=example,dc=com,
+uid: [
+bbush
+]
+},
+{
dn: uid=bgross,cn=users,cn=accounts,dc=example,dc=com,
uid: [
bgross
@@ -119,6 +137,12 @@
]
},
{
+dn: uid=bmullins,cn=users,cn=accounts,dc=example,dc=com,
+uid: [
+bmullins
+]
+},
+{
dn: uid=bnewton,cn=users,cn=accounts,dc=example,dc=com,
uid: [
bnewton
@@ -155,12 +179,30 @@
]
},
{
+dn: uid=cblackwell,cn=users,cn=accounts,dc=example,dc=com,
+uid: [
+cblackwell
+]
+},
+{
Re: [Freeipa-devel] [PATCH] 317 Fixed entity metadata resolution.
On 11/21/2011 12:23 PM, Endi Sukma Dewata wrote:
The current code assumes that an entity will always have a corresponding
LDAPObject on the server, so it looks for the metadata in a fixed
location. This assumption doesn't work for HBAC Test since it is a
Command, not an LDAPObject, so the metadata has to be obtained from a
different location. A new method get_default_metadata() has been added
to allow each entity to find the metadata from the correct location.
Ticket #388
Updated patch attached.
--
Endi S. Dewata
From 6697f518e26ef44733d675951db8de9b23a95643 Mon Sep 17 00:00:00 2001
From: Endi Sukma Dewata edew...@redhat.com
Date: Wed, 16 Nov 2011 21:07:20 -0600
Subject: [PATCH] Fixed entity metadata resolution.
The current code assumes that an entity will always have a corresponding
LDAPObject on the server, so it looks for the metadata in a fixed location.
This assumption doesn't work for HBAC Test since it is a Command, not an
LDAPObject, so the metadata has to be obtained from a different location.
A new method get_default_metadata() has been added to allow each entity
to find the metadata from the correct location.
Ticket #388
---
install/ui/aci.js | 25 +++--
install/ui/automount.js | 15 +--
install/ui/dns.js | 34 ++
install/ui/entitle.js |5 +++--
install/ui/entity.js| 33 +
install/ui/group.js |5 +++--
install/ui/hbac.js | 15 +--
install/ui/host.js |5 +++--
install/ui/hostgroup.js |5 +++--
install/ui/ipa.js | 10 --
install/ui/netgroup.js |5 +++--
install/ui/policy.js| 10 ++
install/ui/serverconfig.js |5 +++--
install/ui/service.js |5 +++--
install/ui/sudo.js | 15 +--
install/ui/test/details_tests.js| 19 ++-
install/ui/test/entity_tests.js | 10 +-
install/ui/test/navigation_tests.js | 22 +++---
install/ui/user.js | 13 +++--
19 files changed, 149 insertions(+), 107 deletions(-)
diff --git a/install/ui/aci.js b/install/ui/aci.js
index 7f82714c1a409d35b4f82d53f5ba6499357f0e5d..8e9e5433b0211d7c87be2191f54e28442c7bb0e1 100644
--- a/install/ui/aci.js
+++ b/install/ui/aci.js
@@ -29,9 +29,10 @@ IPA.aci.permission_entity = function(spec) {
var that = IPA.entity(spec);
-that.init = function(params) {
+that.init = function() {
+that.entity_init();
-params.builder.facet_groups([ 'privilege' , 'settings' ]).
+that.builder.facet_groups([ 'privilege' , 'settings' ]).
search_facet({
columns: [ 'cn' ]
}).
@@ -203,9 +204,10 @@ IPA.aci.privilege_entity = function(spec) {
var that = IPA.entity(spec);
-that.init = function(params) {
+that.init = function() {
+that.entity_init();
-params.builder.facet_groups([ 'role', 'settings', 'permission' ]).
+that.builder.facet_groups([ 'role', 'settings', 'permission' ]).
search_facet({
columns: [
'cn',
@@ -259,9 +261,10 @@ IPA.aci.role_entity = function(spec) {
var that = IPA.entity(spec);
-that.init = function(params) {
+that.init = function() {
+that.entity_init();
-params.builder.facet_groups([ 'member', 'settings', 'privilege' ]).
+that.builder.facet_groups([ 'member', 'settings', 'privilege' ]).
search_facet({
columns: [
'cn',
@@ -308,9 +311,10 @@ IPA.aci.selfservice_entity = function(spec) {
var that = IPA.entity(spec);
-that.init = function(params) {
+that.init = function() {
+that.entity_init();
-params.builder.search_facet({
+that.builder.search_facet({
pagination: false,
columns: [ 'aciname' ]
}).
@@ -349,9 +353,10 @@ IPA.aci.delegation_entity = function(spec) {
var that = IPA.entity(spec);
-that.init = function(params) {
+that.init = function() {
+that.entity_init();
-params.builder.search_facet({
+that.builder.search_facet({
pagination: false,
columns: [ 'aciname' ]
}).
diff --git a/install/ui/automount.js b/install/ui/automount.js
index 11034ea250d8f4d00ea50e3341a0451770fac8a5..8db08e384126db595244c6f597e5f07355c5f2c4 100644
--- a/install/ui/automount.js
+++ b/install/ui/automount.js
@@ -29,9 +29,10 @@ IPA.automount.location_entity = function(spec) {
var that = IPA.entity(spec);
-that.init = function(params) {
+that.init = function() {
+that.entity_init();
-params.builder.facet_groups([ 'automountmap', 'settings' ]).
+
Re: [Freeipa-devel] [PATCH] 319 Added HBAC Test page.
On 11/21/2011 12:38 PM, Endi Sukma Dewata wrote:
This is the initial implementation of HBAC Test page. Currently it
can select user, source/target group, service, rules, and execute
the test. Other functionalities to be implemented include the search
filter, external users/hosts, back/next buttons, validation, styling,
and internalization.
Ticket #388
Updated patch attached.
--
Endi S. Dewata
From 68f2702276385a4a64413d18c4ddb98484c3c339 Mon Sep 17 00:00:00 2001
From: Endi Sukma Dewata edew...@redhat.com
Date: Wed, 16 Nov 2011 21:07:20 -0600
Subject: [PATCH] Added HBAC Test page.
This is the initial implementation of HBAC Test page. Currently it
can select user, source/target group, service, rules, and execute
the test. Other functionalities to be implemented include the search
filter, external users/hosts, back/next buttons, validation, styling,
and internalization.
Ticket #388
---
install/ui/Makefile.am |1 +
install/ui/facet.js| 59 ++--
install/ui/hbactest.js | 510
install/ui/index.html | 13 +-
install/ui/ipa.css | 20 +-
install/ui/ipa.js | 14 +-
install/ui/search.js | 18 +-
install/ui/test/data/hbacrule_find_pkeys.json | 16 +-
install/ui/test/data/hbacrule_get_records.json | 83 -
install/ui/test/data/hbacrule_show.json|4 +-
install/ui/test/data/hbactest.json | 16 +
install/ui/webui.js|3 +-
install/ui/widget.js | 10 +-
13 files changed, 710 insertions(+), 57 deletions(-)
create mode 100644 install/ui/hbactest.js
create mode 100644 install/ui/test/data/hbactest.json
diff --git a/install/ui/Makefile.am b/install/ui/Makefile.am
index 8b613666c83fec65cafe98ddda704fb9a1729e57..835888d94e65704ae12d4098ead210bfb195ce85 100644
--- a/install/ui/Makefile.am
+++ b/install/ui/Makefile.am
@@ -25,6 +25,7 @@ app_DATA =\
field.js \
group.js \
hbac.js \
+ hbactest.js \
host.js \
hostgroup.js \
index.html \
diff --git a/install/ui/facet.js b/install/ui/facet.js
index 71ad5c08b2c1ea9105dfff3d5b71673f8e36d348..65ac71ee0ac92a1cbb2d8893fe6c013a0cca9b19 100644
--- a/install/ui/facet.js
+++ b/install/ui/facet.js
@@ -110,6 +110,9 @@ IPA.facet = function(spec) {
that.header.load(data.result.result);
};
+that.refresh = function() {
+};
+
that.clear = function() {
};
@@ -320,7 +323,7 @@ IPA.facet_header = function(spec) {
}).appendTo(container);
var span = $('h3/', {
-text: that.facet.entity.metadata.label
+text: that.facet.entity.label
}).appendTo(that.title_container);
if (!that.facet.disable_facet_tabs) {
@@ -341,9 +344,6 @@ IPA.facet_header = function(spec) {
that.load = function(data) {
if (!that.facet.disable_facet_tabs) {
var pkey = that.facet.pkey;
-if(!pkey || !data) {
-pkey = '';
-}
var facet_groups = that.facet.entity.facet_groups.values;
for (var i=0; ifacet_groups.length; i++) {
@@ -353,13 +353,15 @@ IPA.facet_header = function(spec) {
if (!span.length) continue;
var label = facet_group.label;
-if (label) {
+if (pkey label) {
label = label.replace('${primary_key}', pkey);
-
-var label_container = $('.facet-group-label', span);
-label_container.text(label);
+} else {
+label = '';
}
+var label_container = $('.facet-group-label', span);
+label_container.text(label);
+
var facets = facet_group.facets.values;
for (var j=0; jfacets.length; j++) {
var facet = facets[j];
@@ -461,15 +463,13 @@ IPA.table_facet = function(spec) {
that.load_all = function(data) {
-that.table.empty();
-
var result = data.result.result;
+var records = [];
for (var i=0; iresult.length; i++) {
var record = that.table.get_record(result[i], 0);
-that.table.add_record(record);
+records.push(record);
}
-
-that.table.unselect_all();
+that.load_records(records);
if (data.result.truncated) {
var message = IPA.messages.search.truncated;
@@ -480,7 +480,7 @@ IPA.table_facet = function(spec) {
}
};
-that.get_pkeys = function(data){
+that.get_pkeys = function(data) {
return [];
};
@@ -511,9 +511,8 @@ IPA.table_facet = function(spec) {
that.table.current_page = page;
if (!that.pkeys || !that.pkeys.length) {
-that.table.empty();
+
Re: [Freeipa-devel] [PATCH] 320 Fixed navigation buttons for HBAC Test.
On 11/21/2011 7:31 PM, Endi Sukma Dewata wrote:
The Back, Next, and New Test buttons in HBAC Test have been fixed
to work properly.
Ticket #388
Updated patch attached.
--
Endi S. Dewata
From f61c2c2967cefeed7ff5d0ab0319cd4b1944ba31 Mon Sep 17 00:00:00 2001
From: Endi Sukma Dewata edew...@redhat.com
Date: Mon, 21 Nov 2011 16:43:52 -0600
Subject: [PATCH] Fixed navigation buttons for HBAC Test.
The Back, Next, and New Test buttons in HBAC Test have been fixed
to work properly.
Ticket #388
---
install/ui/facet.js | 12 +
install/ui/hbactest.js | 97 +
install/ui/ipa.css | 26 ++
install/ui/jquery.ordered-map.js | 18 +++-
install/ui/widget.js |2 +-
5 files changed, 131 insertions(+), 24 deletions(-)
diff --git a/install/ui/facet.js b/install/ui/facet.js
index 65ac71ee0ac92a1cbb2d8893fe6c013a0cca9b19..4ffd43dcdbd61553ed8d010019b7942ecd577d55 100644
--- a/install/ui/facet.js
+++ b/install/ui/facet.js
@@ -702,6 +702,18 @@ IPA.facet_group = function(spec) {
return that.facets.get(name);
};
+that.get_facet_index = function(name) {
+return that.facets.get_key_index(name);
+};
+
+that.get_facet_by_index = function(index) {
+return that.facets.get_value_by_index(index);
+};
+
+that.get_facet_count = function(index) {
+return that.facets.length;
+};
+
return that;
};
diff --git a/install/ui/hbactest.js b/install/ui/hbactest.js
index b5bf3de2cd4ee5cf1bd0f9a83378853e1bfd04c5..715c0449c56b75c55883518ab4128f8c83671152 100644
--- a/install/ui/hbactest.js
+++ b/install/ui/hbactest.js
@@ -204,22 +204,31 @@ IPA.hbac.test_facet = function(spec) {
style: 'float: right'
}).appendTo(container);
-that.back_button = IPA.button({
-name: 'back',
-label: 'Back',
-click: function() {
-if (!that.back_button.hasClass('action-button-disabled')) {
-that.back();
+var facet_group = that.entity.get_facet_group('default');
+var index = facet_group.get_facet_index(that.name);
+
+if (index 0) {
+that.back_button = IPA.button({
+name: 'back',
+label: 'Back',
+icon: 'ui-icon ui-icon-triangle-1-w',
+click: function() {
+if (!that.back_button.hasClass('action-button-disabled')) {
+that.back();
+}
+return false;
}
-return false;
-}
-}).appendTo(buttons);
+}).appendTo(buttons);
+
+buttons.append(' ');
+}
that.next_button = IPA.button({
name: 'next',
label: 'Next',
+icon: 'ui-icon ui-icon-triangle-1-e',
click: function() {
-if (!that.add_button.hasClass('action-button-disabled')) {
+if (!that.next_button.hasClass('action-button-disabled')) {
that.next();
}
return false;
@@ -227,6 +236,30 @@ IPA.hbac.test_facet = function(spec) {
}).appendTo(buttons);
};
+that.back = function() {
+var facet_group = that.entity.get_facet_group('default');
+var index = facet_group.get_facet_index(that.name);
+if (index = 0) return;
+
+var facet = facet_group.get_facet_by_index(index - 1);
+
+var state = {};
+state[that.entity.name+'-facet'] = facet.name;
+IPA.nav.push_state(state);
+};
+
+that.next = function() {
+var facet_group = that.entity.get_facet_group('default');
+var index = facet_group.get_facet_index(that.name);
+if (index = facet_group.get_facet_count() - 1) return;
+
+var facet = facet_group.get_facet_by_index(index + 1);
+
+var state = {};
+state[that.entity.name+'-facet'] = facet.name;
+IPA.nav.push_state(state);
+};
+
that.get_pkeys = function(data) {
var result = data.result.result;
var pkey_name = that.managed_entity.metadata.primary_key;
@@ -261,7 +294,7 @@ IPA.hbac.test_facet = function(spec) {
command.on_success = function(data, text_status, xhr) {
if (that.filter) that.filter.focus();
-that.load(data); // table_facet.load()
+that.load(data);
};
command.on_error = function(xhr, text_status, error_thrown) {
@@ -271,6 +304,10 @@ IPA.hbac.test_facet = function(spec) {
command.execute();
};
+that.reset = function() {
+that.table.set_values([]);
+};
+
that.save = function(record) {
if (that.selected_values that.selected_values.length) {
record[that.name] = that.selected_values[0];
@@ -336,6 +373,11 @@ IPA.hbac.test_rules_facet = function(spec) {
Re: [Freeipa-devel] [PATCH] 321 Fixed search filter in HBAC Test.
On 11/21/2011 7:33 PM, Endi Sukma Dewata wrote:
The search filter in HBAC Test has been fixed to work properly.
Ticket #388
Updated patch attached.
--
Endi S. Dewata
From 8e60a7fb610753863f8745fd955a497fade5b118 Mon Sep 17 00:00:00 2001
From: Endi Sukma Dewata edew...@redhat.com
Date: Mon, 21 Nov 2011 17:11:49 -0600
Subject: [PATCH] Fixed search filter in HBAC Test.
The search filter in HBAC Test has been fixed to work properly.
Ticket #388.
---
install/ui/hbactest.js |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/install/ui/hbactest.js b/install/ui/hbactest.js
index 715c0449c56b75c55883518ab4128f8c83671152..b195c796bfedbc4d78f5e653d79c9721c6a3d25b 100644
--- a/install/ui/hbactest.js
+++ b/install/ui/hbactest.js
@@ -236,6 +236,13 @@ IPA.hbac.test_facet = function(spec) {
}).appendTo(buttons);
};
+that.find = function() {
+var filter = that.filter.val();
+var state = {};
+state[that.entity.name+'-'+that.name+'-filter'] = filter;
+IPA.nav.push_state(state);
+};
+
that.back = function() {
var facet_group = that.entity.get_facet_group('default');
var index = facet_group.get_facet_index(that.name);
@@ -278,7 +285,7 @@ IPA.hbac.test_facet = function(spec) {
that.refresh = function() {
-var filter = IPA.nav.get_state(that.managed_entity.name+'-filter');
+var filter = IPA.nav.get_state(that.entity.name+'-'+that.name+'-filter');
var command = IPA.command({
name: that.get_search_command_name(),
--
1.7.5.1
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 322 Added external fields for HBAC Test.
A text field has been added for specifying external user, host, and
service for HBAC testing.
Ticket #388
--
Endi S. Dewata
From 441a96d27c0862a3f0eabd05bcef982727a92434 Mon Sep 17 00:00:00 2001
From: Endi Sukma Dewata edew...@redhat.com
Date: Mon, 21 Nov 2011 18:58:38 -0600
Subject: [PATCH] Added external fields for HBAC Test.
A text field has been added for specifying external user, host, and
service for HBAC testing.
Ticket #388
---
install/ui/facet.js|6 +++-
install/ui/hbactest.js | 64 +++-
2 files changed, 68 insertions(+), 2 deletions(-)
diff --git a/install/ui/facet.js b/install/ui/facet.js
index 4ffd43dcdbd61553ed8d010019b7942ecd577d55..0680c1502b0a6135907e42c759b2a6ad6548afa5 100644
--- a/install/ui/facet.js
+++ b/install/ui/facet.js
@@ -602,9 +602,13 @@ IPA.table_facet = function(spec) {
batch.execute();
};
+that.get_selected_values = function() {
+return that.table.get_selected_values();
+};
+
that.select_changed = function() {
-that.selected_values = that.table.get_selected_values();
+that.selected_values = that.get_selected_values();
if (that.remove_button) {
if (that.selected_values.length === 0) {
diff --git a/install/ui/hbactest.js b/install/ui/hbactest.js
index b195c796bfedbc4d78f5e653d79c9721c6a3d25b..4d35942e67e06af83392e932fc43839b6e3aaa07 100644
--- a/install/ui/hbactest.js
+++ b/install/ui/hbactest.js
@@ -195,6 +195,35 @@ IPA.hbac.test_facet = function(spec) {
container.append('br/');
+var id = that.entity.name+'-'+that.name+'-external';
+var pkey_name = that.managed_entity.metadata.primary_key;
+
+that.external_radio = $('input/', {
+id: id,
+type: 'radio',
+name: pkey_name,
+value: '__external__',
+click: function() {
+that.selected_values = [ that.external_radio.val() ];
+}
+}).appendTo(container);
+
+$('label/', {
+text: 'Specify external '+that.managed_entity.metadata.label_singular+':',
+'for': id
+}).appendTo(container);
+
+container.append(' ');
+
+that.external_text = $('input/', {
+name: 'external',
+focus: function() {
+that.external_radio.click();
+}
+}).appendTo(container);
+
+container.append('br/');
+
that.create_buttons(container);
};
@@ -311,13 +340,42 @@ IPA.hbac.test_facet = function(spec) {
command.execute();
};
+that.get_selected_values = function() {
+var values = that.table.get_selected_values();
+if (values values.length) return values;
+
+if (that.external_radio that.external_radio.is(':checked')) {
+return [ that.external_radio.val() ];
+}
+
+return [];
+};
+
that.reset = function() {
that.table.set_values([]);
+that.external_radio.attr('checked', false);
+};
+
+that.load_records = function(records) {
+that.table.empty();
+for (var i=0; irecords.length; i++) {
+that.table.add_record(records[i]);
+}
+if (that.selected_values[0] === '__external__') {
+that.external_radio.attr('checked', true);
+} else {
+that.table.set_values(that.selected_values);
+}
};
that.save = function(record) {
if (that.selected_values that.selected_values.length) {
-record[that.name] = that.selected_values[0];
+var value = that.selected_values[0];
+if (value === that.external_radio.val()) {
+record[that.name] = that.external_text.val();
+} else {
+record[that.name] = value;
+}
}
};
@@ -380,6 +438,10 @@ IPA.hbac.test_rules_facet = function(spec) {
that.create_buttons(container);
};
+that.get_selected_values = function() {
+return that.table.get_selected_values();
+};
+
that.reset = function() {
that.table.set_values([]);
if (that.enabled) that.enabled.attr('checked', false);
--
1.7.5.1
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
