Re: [Freeipa-devel] [PATCH] 54 Fix attempted write to attribute of read-only object
Dne 14.10.2011 10:19, Alexander Bokovoy napsal(a): On Fri, 14 Oct 2011, Jan Cholasta wrote: Perform an HTTP request. -if self.ca_host == None: -self.ca_host = self._select_ca() +if self.ca_host is None: +object.__setattr__(self, 'ca_host', self._select_ca()) return dogtag.http_request(self.ca_host, port, url, **kw) I don't like this approach as well. A better way would be to have a class CaCache that is mutable and allow changing its properties. Then you would create an instance of CaCache in ca.__init__() and ask for its properties later. I don't like the idea of introducing a new class every time we need a ReadOnly attribute to be writable. There's quite a few places in the code where we do object.__setattr__ on ReadOnly objects. IMO the right thing to do would be to add means of whitelisting ReadOnly attributes that need to stay writable after locking. You can move those _select_ca(), _select_any_master(), _host_has_service() to CaCache as they seem to not depend on anything in class ca but rather use global api.env. This way you will get is a fairly simple CaCache class reusable both in ca and ra classes. Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 029 Page is cleared before it is visible
On 10/31/2011 11:38 PM, Endi Sukma Dewata wrote:
On 10/27/2011 4:57 AM, Petr Vobornik wrote:
https://fedorahosted.org/freeipa/ticket/1459
Some issues:
1. The new clear() method is called during refresh(), so the facet with
the old data is still shown for a brief moment before it's cleared.
The clear() should be called before show(). However, if the pkey/filter
is unchanged (check using needs_update()) we just need to show() the
facet, no need to clear() and refresh() again. The above logic needs to
be fixed.
Changed.
The we will need to override the needs_update() for search and
association facets because the default one always returns true.
Done
2. The following code in association.js and search.js will call clear()
if there's no old pkey/filter, is this intentional? No old pkey/filter
means the page is just loaded, so it probably doesn't need clearing.
if (!old_pkey || old_pkey[0] !== pkey[0]) {
that.clear();
}
if (!old_filter || old_filter[0] !== filter[0]) {
that.clear();
}
It seems unnecessary. But probably it was intentional (don't remember) -
IDRC if there is a widget - maybe keytab or certificate status, which
has some default state worth cleaning. Anyway in current implementation
this logic is part of need_update and it is a must. IMHO we should avoid
implementing special need_cleaning method. Cleaning at first display
doesn't do any harm and it is one less method to maintain in couple classes.
3) Fixed bad implementation of clear method in radio_widget.
4) Changed direct/indirect radio names in association facets - radios
form different facets were interfering.
5) Added ID generator, using in radio_widget, same reason as #4.
6) Added clearing of header in details facet and association facets -
refreshes of member counts were confusing.
7) Removed setting that.pkey in create method in details, association
facet (it broke need_update, didn't found purpose).
8) Maybe we should add a refresh button to search facet. It doesn't
reflect concurrent usage. Refresh by 2 changes of filter doesn't seem nice.
--
Petr Vobornik
From d99d152ea71f89459b4cdb2b60690cc771e1b8fc Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Mon, 24 Oct 2011 14:53:29 +0200
Subject: [PATCH] Page is cleared before it is visible
https://fedorahosted.org/freeipa/ticket/1459
Changes:
* added clear method to widgets, section, search, details, association facets
* clear and refresh method in facet are called only if key/filter was changed
* added id generator for widgets
---
install/ui/association.js | 21 ---
install/ui/certificate.js |9 +
install/ui/details.js | 21 ++--
install/ui/entity.js | 19 +--
install/ui/host.js| 12 +++
install/ui/search.js | 18 --
install/ui/service.js |5 +++
install/ui/user.js|5 +++
install/ui/widget.js | 80 +++--
9 files changed, 164 insertions(+), 26 deletions(-)
diff --git a/install/ui/association.js b/install/ui/association.js
index d3b66132d5043b0dfe60b8847896e9f27f676059..d3d6b124b431414ff04fad05b16dbb972b38c2b7 100644
--- a/install/ui/association.js
+++ b/install/ui/association.js
@@ -871,8 +871,6 @@ IPA.association_facet = function (spec) {
that.facet_create_header(container);
-that.pkey = IPA.nav.get_state(that.entity.name+'-pkey');
-
if (!that.read_only) {
that.remove_button = IPA.action_button({
name: 'remove',
@@ -908,12 +906,13 @@ IPA.association_facet = function (spec) {
span.append(IPA.messages.association.show_results);
span.append(' ');
-var direct_id = that.entity.name+'-'+that.attribute_member+'-'+that.other_entity+'-direct-radio';
+var name = that.entity.name+'-'+that.attribute_member+'-'+that.other_entity+'-type-radio';
+var direct_id = name + '-direct';
that.direct_radio = $('input/', {
id: direct_id,
type: 'radio',
-name: 'type',
+name: name,
value: 'direct',
click: function() {
that.association_type = $(this).val();
@@ -929,12 +928,12 @@ IPA.association_facet = function (spec) {
span.append(' ');
-var indirect_id = that.entity.name+'-'+that.attribute_member+'-'+that.other_entity+'-indirect-radio';
+var indirect_id = name + '-indirect';
that.indirect_radio = $('input/', {
id: indirect_id,
type: 'radio',
-name: 'type',
+name: name,
value: 'indirect',
click: function() {
that.association_type = $(this).val();
@@ -1201,6 +1200,16 @@ IPA.association_facet = function (spec) {
command.execute();
};
+that.clear = function() {
[Freeipa-devel] Unifying the PKI and IPA Directory Server instances
We had a brief discussion on unifying the PKI and IPA Directory Server instances. Here are my notes from it. Please fill out the details and correct me if I've mis-stated anything below. Issues: 1. Both make changes to Config. One identified conflict is he configuration of the Uniqueness plugin 2. PKI uses Directory Manager. This is insecure. Can it use a differen, limited admin? 3. Index strategies are different 4. make sure we have a union of the required sets of plugins 5. PKI needs to set D.S. Default Name context 6. If PKI uses the IPA datastore for users, it needs to creat the user with all the right prerequisites (object class, defaults) 7. PKI puts users in groups using member of so that should still work for the IPA tree ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Unifying the PKI and IPA Directory Server instances
On 11/01/2011 12:12 PM, Adam Young wrote: We had a brief discussion on unifying the PKI and IPA Directory Server instances. Here are my notes from it. Please fill out the details and correct me if I've mis-stated anything below. Issues: 1. Both make changes to Config. One identified conflict is he configuration of the Uniqueness plugin 2. PKI uses Directory Manager. This is insecure. Can it use a differen, limited admin? 3. Index strategies are different 4. make sure we have a union of the required sets of plugins 5. PKI needs to set D.S. Default Name context 6. If PKI uses the IPA datastore for users, it needs to creat the user with all the right prerequisites (object class, defaults) 7. PKI puts users in groups using member of so that should still work for the IPA tree ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel One additional point: 8. make sure that Certificate Server and IPA upgrade mechanisms for DirSrv don't conflict ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Unifying the PKI and IPA Directory Server instances
- Original Message - We had a brief discussion on unifying the PKI and IPA Directory Server instances. Here are my notes from it. Please fill out the details and correct me if I've mis-stated anything below. Issues: Do IPA and PKI use different suffixes? 1. Both make changes to Config. One identified conflict is he configuration of the Uniqueness plugin It may be easy to enhance this plugin and other plugins to allow different configuration per subtree. 2. PKI uses Directory Manager. This is insecure. Can it use a differen, limited admin? Or use ldapi? I don't think ldapjdk can use ldapi. 3. Index strategies are different Use a union? e.g. if ipa needs attribute a indexed for equality only, but PKI needs it indexed for presence and substring only, then we can just index it for eq, sub, and pres. 4. make sure we have a union of the required sets of plugins 5. PKI needs to set D.S. Default Name context What is this? 6. If PKI uses the IPA datastore for users, it needs to creat the user with all the right prerequisites (object class, defaults) If both PKI and IPA use structural objectclasses, we may have to create corresponding auxiliary objectclasses so that you can mix-in both sets of objectclasses while having only one structural objectclass per entry. 7. PKI puts users in groups using “member of” so that should still work for the IPA tree ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Unifying the PKI and IPA Directory Server instances
On Tue, 2011-11-01 at 12:12 -0400, Adam Young wrote: We had a brief discussion on unifying the PKI and IPA Directory Server instances. Here are my notes from it. Please fill out the details and correct me if I've mis-stated anything below. Issues: 1. Both make changes to Config. One identified conflict is he configuration of the Uniqueness plugin 2. PKI uses Directory Manager. This is insecure. Can it use a differen, limited admin? Not only insecure but we do not want necessarily trust PKI to touch stuff that is IPA specific. 3. Index strategies are different 4. make sure we have a union of the required sets of plugins 5. PKI needs to set D.S. Default Name context This is a DS/IPA feature, not a PKI feature. In an IPA install we will need to be able to tell DS that the IPA namingContext is the default one. 6. If PKI uses the IPA datastore for users, it needs to creat the user with all the right prerequisites (object class, defaults) No it should never be allowed to create users, it should just use existing users I think. 7. PKI puts users in groups using “member of” so that should still work for the IPA tree PKI is currently using groupOfUniqueUsers and uniqueMember. We will need it to use groupOfNames (as modified in 389DS to not require members) and use member (which will automatically create memberof attributes). 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] Unifying the PKI and IPA Directory Server instances
On Tue, 2011-11-01 at 12:40 -0400, Richard Megginson wrote: - Original Message - We had a brief discussion on unifying the PKI and IPA Directory Server instances. Here are my notes from it. Please fill out the details and correct me if I've mis-stated anything below. Issues: Do IPA and PKI use different suffixes? Currently not as we use completely separate instances, but we will be able to use different suffixes for some stuff. 1. Both make changes to Config. One identified conflict is he configuration of the Uniqueness plugin It may be easy to enhance this plugin and other plugins to allow different configuration per subtree. If we confirm this conflict this will become a requirement before we can proceed. 2. PKI uses Directory Manager. This is insecure. Can it use a differen, limited admin? Or use ldapi? I don't think ldapjdk can use ldapi. It's a matter of trust for me. I do not want to trust PKI to have free reign on all data. I want it to be confined to only what it needs. So we can use ldapi and user mapping, but we wouldn't map the user to DM anyway. 3. Index strategies are different Use a union? e.g. if ipa needs attribute a indexed for equality only, but PKI needs it indexed for presence and substring only, then we can just index it for eq, sub, and pres. The problem here is finding out and how to make sure pki vs ds/ipa install and upgrade scripts do not stomp on each other. 4. make sure we have a union of the required sets of plugins 5. PKI needs to set D.S. Default Name context What is this? See my other mail, we need DS to support setting defaultNamingContext in rootdse. 6. If PKI uses the IPA datastore for users, it needs to creat the user with all the right prerequisites (object class, defaults) If both PKI and IPA use structural objectclasses, we may have to create corresponding auxiliary objectclasses so that you can mix-in both sets of objectclasses while having only one structural objectclass per entry. The problem here is much bigger, PKI simply do not have enough information to create a proper IPA user, so it should not be allowed to. This is an example of why I want to tightly control through ACIs what PKI can do and prevent it from causing issues. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 0293-Add-priority-to-pwpolicy-list
From e5ba2e46e50cac4f1fe7f86ad7dcee42518f985c Mon Sep 17 00:00:00 2001
From: Adam Young ayo...@redhat.com
Date: Tue, 1 Nov 2011 12:51:05 -0400
Subject: [PATCH] Add priority to pwpolicy list
First step to solving
https://fedorahosted.org/freeipa/ticket/1977
---
install/ui/policy.js |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/install/ui/policy.js b/install/ui/policy.js
index 54321a481634e900d68e58d5f8acb38ac6819b0a..41432f743e2b894cb4a8d2a9b338bacc85b8c762 100644
--- a/install/ui/policy.js
+++ b/install/ui/policy.js
@@ -28,7 +28,7 @@ IPA.entity_factories.pwpolicy = function() {
return IPA.entity_builder().
entity('pwpolicy').
search_facet({
-columns:['cn']}).
+columns:['cn','cospriority']}).
details_facet({
sections:[
{
--
1.7.6.4
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Unifying the PKI and IPA Directory Server instances
On Tue, 2011-11-01 at 12:49 -0400, Simo Sorce wrote: On Tue, 2011-11-01 at 12:40 -0400, Richard Megginson wrote: - Original Message - We had a brief discussion on unifying the PKI and IPA Directory Server instances. Here are my notes from it. Please fill out the details and correct me if I've mis-stated anything below. Issues: Do IPA and PKI use different suffixes? Currently not as we use completely separate instances, but we will be able to use different suffixes for some stuff. I would suggest that if we use the same database, then we use different suffixes. For one thing, we will want to be able to set ACIs so that the information here is not publicly browsable. It will also be much easier to limit the pki users ability to touch the rest of the db, and visa versa. It also makes it less likely that upgrade scripts will stomp on each other. 1. Both make changes to Config. One identified conflict is he configuration of the Uniqueness plugin It may be easy to enhance this plugin and other plugins to allow different configuration per subtree. If we confirm this conflict this will become a requirement before we can proceed. 2. PKI uses Directory Manager. This is insecure. Can it use a differen, limited admin? Or use ldapi? I don't think ldapjdk can use ldapi. It's a matter of trust for me. I do not want to trust PKI to have free reign on all data. I want it to be confined to only what it needs. So we can use ldapi and user mapping, but we wouldn't map the user to DM anyway. 3. Index strategies are different Use a union? e.g. if ipa needs attribute a indexed for equality only, but PKI needs it indexed for presence and substring only, then we can just index it for eq, sub, and pres. The problem here is finding out and how to make sure pki vs ds/ipa install and upgrade scripts do not stomp on each other. 4. make sure we have a union of the required sets of plugins 5. PKI needs to set D.S. Default Name context What is this? See my other mail, we need DS to support setting defaultNamingContext in rootdse. 6. If PKI uses the IPA datastore for users, it needs to creat the user with all the right prerequisites (object class, defaults) If both PKI and IPA use structural objectclasses, we may have to create corresponding auxiliary objectclasses so that you can mix-in both sets of objectclasses while having only one structural objectclass per entry. The problem here is much bigger, PKI simply do not have enough information to create a proper IPA user, so it should not be allowed to. This is an example of why I want to tightly control through ACIs what PKI can do and prevent it from causing issues. If we do this integration, then I'm OK with IPA creating the users. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0293-Add-priority-to-pwpolicy-list
On 11/1/2011 11:53 AM, Adam Young wrote: ACK and pushed to master. -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 029 Page is cleared before it is visible
On 11/1/2011 7:37 AM, Petr Vobornik wrote:
1. The new clear() method is called during refresh(), so the facet with
the old data is still shown for a brief moment before it's cleared.
The clear() should be called before show(). However, if the pkey/filter
is unchanged (check using needs_update()) we just need to show() the
facet, no need to clear() and refresh() again. The above logic needs to
be fixed.
Changed.
The we will need to override the needs_update() for search and
association facets because the default one always returns true.
Done
On the second thought, this might not be sufficient to detect the
changes in the list page. Try changing an attribute in an entry, then go
back to the list page, the list page will not show the updated attribute
because the filter is not changed.
I think we should remove the needs_update() from the search facet so it
will always refresh, but we probably can keep it for association facet.
What do you think? Sorry about that.
There are probably better solutions, but let's do this separately.
5) Added ID generator, using in radio_widget, same reason as #4.
The get_id() method (might be better called get_next_id() or
generate_id()) doesn't really need to take a widget parameter. The
id_count should be unique enough. If you want, it can take an optional
prefix so the ID will be like 'prefix-id'. It will make it more
usable for other things not just widgets.
8) Maybe we should add a refresh button to search facet. It doesn't
reflect concurrent usage. Refresh by 2 changes of filter doesn't seem nice.
You can reload the page too, but I agree we probably need a refresh
button, and possibly for other facets too. I'll open a ticket.
9. The facet header's clear() calls load() with empty data. The load()
will display the facet group label using facet's pkey. Since this is
called before refresh(), sometimes you'll see 'undefined' or the old
pkey. I think the code in entity.js:351-354 should check if the data is
empty it should clear the label.
10. Instead of emptying button label in host.js:731-732, it's probably
better to reset it to its initial value:
var password_label = $('.button-label', that.set_password_button);
password_label.text(IPA.messages.objects.host.password_set_button);
--
Endi S. Dewata
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Nesting widgets
So I decided to try to get an IP Address widget working. See the
attached patch. It was fairly trivial.
However, this widget is not really all that useful by itself. It would
need to work as a part of a multivalued_text widget in order to
replace
the widget used on the dnsrecord page. And looking at the multivalued
text widget, I think you will agree that is going to be tricky.
I think we can create an extend point for validation logic (EG
validator object in field's spec) instead of inheriting the widget.
To summarize the recent discussion on IRC and other threads, we're
planning to split the existing widget concept into (logical) fields and
(visual) widgets. See: https://fedorahosted.org/freeipa/ticket/2040
The new widgets will be used mainly for input/output like the existing
widgets, but they can also be any other UI components such as header or
separator.
The widgets will support nesting. For example, the multivalued widget
will become a composite widget which has an Add and Undo All links and
can contain other widgets:
widgets: [
{
factory: IPA.multivalued_widget,
name: 'fullName',
widget: IPA.text_widget
}
]
The widgets can be arranged inside a section, which is also a composite
widget that has a header and is collapsible.
widgets: [
{
factory: IPA.section_widget,
name: 'identity',
widgets: [
{
factory: IPA.text_widget,
name: 'fullName'
}
]
}
]
For IP address we could either use a text widget with an IP address
validator, or we could also implement a custom IP address widget. Either
solution can be used inside multivalued widget.
widgets: [
{
factory: IPA.multivalued_widget,
name: 'ipaddress1',
widget: {
factory: IPA.text_widget,
validator: IPA.ipaddress_validator
}
},
{
factory: IPA.multivalued_widget,
name: 'ipaddress2',
widget: IPA.ipaddress_widget,
},
]
Interesting concept. Yes, this would work too, and solve the issue for
IP addresses validation. But there are places where we may want to
validate only a single IP address, and we may end up with code
duplication, although more likely they will both just call the same
utility function.
Since the multivalued widget is completely separate, we can reuse the IP
address widget for a single valued attribute.
widgets: [
{
factory: IPA.ipaddress_widget,
name: 'ipaddress'
}
]
In order to make the widget scheme more nestable, the section
section.load and save can do more work, such as scoping down the piece
of the request record to just that portion required by the widget.
Bascially, it can do what widget.load does, just externally
I don't think this would help. This would limit the widget. Currently
most widget works with the record.[widget name]. But we can override
load and save method to break the 1:1 mapping between widget and
record. Widget can consist of several widgets and supply them custom
record object (it can assume that the simple widget would fetch the
value of its name. The name is defined by the master widget (no
problem here).)
The concept you mentioned could be beneficial if we abandon flat
records and introduce structured ones. But I think there is no will
for it. Event then I don't know if sections should be responsible for
this. It's not their purpose.
Records are already structured, just that by the time we get to the
individual fields, they tend to be flat. But the record is JSON and is a
tree structure.
But I like what you are saying. I agree that the interface for Widget
and Section should be the same. Right now Section is:
that.save = function(record) {};
that.load = function(record) {);
and load is
that.load = function(record) {};
that.save = function() {};
It is this last function that needs to be changed, but it will have far
reaching effects. We use save to extract the value or values from the
field for many uses. I think we can do this: For all widgets, rename
save() to get_value(); and then add a save(record) method that calls
get_value(); Then widget and record have the same interface, which is a
big first step.
The fields will be used to load/store attributes. Each field usually
will have a corresponding widget, except hidden fields:
fields: [
{
name: 'krbprincipalname' // hidden
},
{
name: 'cn',
widget: 'identity.fullName' // widget inside a section
},
{
name: 'mail',
widget: 'contact.email' // multivalued widget
}
]
During load the fields will be used to get the attributes from the
records returned by the server and then pass them to the corresponding
widgets to be
