Re: [Freeipa-devel] [PATCH] 762 Let the framework be able to override the hostname
On Wed, 2011-05-25 at 11:29 -0400, Rob Crittenden wrote:
Martin Kosek wrote:
On Fri, 2011-04-01 at 11:47 -0400, Rob Crittenden wrote:
The hostname is passed in during the server installation. We should use
this hostname for the resulting server as well. It was being discarded
and we always used the system hostname value.
ticket 1052
rob
I have to NACK this again. I have a problem communicating with IPA on a
master machine. I reproduced in on 2 different machines. Please, correct
my steps if I am wrong, I do the following procedure
1) I prepare a fresh minimal F-15
2) Install freeipa-server (current master with your patches)
3) Add custom hostname to /etc/hosts
4) Install IPA server:
ipa-server-install -p secret123 -a secret123 --hostname
ipa.idm.lab.bos.redhat.com --setup-dns --forwarder=10.16.255.2
5) # kinit admin
Password for ad...@idm.lab.bos.redhat.com:
6) # ipa user-show admin
ipa: ERROR: cannot connect to 'any of the configured servers':
https://ipa.idm.lab.bos.redhat.com/ipa/xml,
https://ipa.idm.lab.bos.redhat.com/ipa/xml
# ping -c 1 ipa.idm.lab.bos.redhat.com
PING ipa.idm.lab.bos.redhat.com (10.16.78.140) 56(84) bytes of data.
64 bytes from ipa.idm.lab.bos.redhat.com (10.16.78.140): icmp_req=1
ttl=64 time=0.049 ms
Apache error_log shows relevant errors:
[Wed May 25 06:42:38 2011] [error] ipa: ERROR: Failed to start IPA: Unable
to retrieve LDAP schema: Invalid credentials: SASL(-1): generic failure:
GSSAPI Error: Unspecified GSS failure. Minor code may provide more
information (Permission denied)
[Wed May 25 06:42:38 2011] [error] ipa: ERROR: Failed to start IPA: Unable
to retrieve LDAP schema: Invalid credentials: SASL(-1): generic failure:
GSSAPI Error: Unspecified GSS failure. Minor code may provide more
information (Permission denied)
[Wed May 25 06:43:55 2011] [error] Exception KeyError:
KeyError(140250828974112,) inmodule 'threading' from
'/usr/lib64/python2.7/threading.pyc' ignored
[Wed May 25 06:43:55 2011] [error] Exception KeyError:
KeyError(140250828974112,) inmodule 'threading' from
'/usr/lib64/python2.7/threading.pyc' ignored
[Wed May 25 06:43:55 2011] [error] Exception KeyError:
KeyError(140250828974112,) inmodule 'threading' from
'/usr/lib64/python2.7/threading.pyc' ignored
[Wed May 25 06:43:55 2011] [error] Exception KeyError:
KeyError(140250828974112,) inmodule 'threading' from
'/usr/lib64/python2.7/threading.pyc' ignored
[Wed May 25 06:43:55 2011] [error] Exception KeyError:
KeyError(140250828974112,) inmodule 'threading' from
'/usr/lib64/python2.7/threading.pyc' ignored
[Wed May 25 06:43:55 2011] [error] Exception KeyError:
KeyError(140250828974112,) inmodule 'threading' from
'/usr/lib64/python2.7/threading.pyc' ignored
[Wed May 25 06:43:55 2011] [error] Exception KeyError:
KeyError(140250828974112,) inmodule 'threading' from
'/usr/lib64/python2.7/threading.pyc' ignored
[Wed May 25 06:43:55 2011] [error] Exception KeyError:
KeyError(140250828974112,) inmodule 'threading' from
'/usr/lib64/python2.7/threading.pyc' ignored
[Wed May 25 06:43:55 2011] [error] Exception KeyError:
KeyError(140250828974112,) inmodule 'threading' from
'/usr/lib64/python2.7/threading.pyc' ignored
[Wed May 25 06:43:55 2011] [error] Exception KeyError:
KeyError(140250828974112,) inmodule 'threading' from
'/usr/lib64/python2.7/threading.pyc' ignored
[Wed May 25 06:43:56 2011] [notice] caught SIGTERM, shutting down
[Wed May 25 06:43:56 2011] [notice] SELinux policy enabled; httpd running
as context system_u:system_r:kernel_t:s0
[Wed May 25 06:43:57 2011] [notice] Digest: generating secret for digest
authentication ...
[Wed May 25 06:43:57 2011] [notice] Digest: done
[Wed May 25 06:43:57 2011] [notice] Apache/2.2.17 (Unix) DAV/2
mod_auth_kerb/5.4 mod_nss/2.2.17 NSS/3.12.9.0 mod_wsgi/3.2 Python/2.7.1
configured -- resuming normal operations
[Wed May 25 06:44:04 2011] [error] ipa: INFO: *** PROCESS START ***
[Wed May 25 06:44:04 2011] [error] ipa: INFO: *** PROCESS START ***
[Wed May 25 06:45:25 2011] [error] [client 10.16.78.140] mod_wsgi
(pid=5192): Exception occurred processing WSGI script
'/usr/share/ipa/wsgi.py'.
[Wed May 25 06:45:25 2011] [error] [client 10.16.78.140] Traceback (most
recent call last):
[Wed May 25 06:45:25 2011] [error] [client 10.16.78.140] File
/usr/share/ipa/wsgi.py, line 48, in application
[Wed May 25 06:45:25 2011] [error] [client 10.16.78.140] return
api.Backend.session(environ, start_response)
[Wed May 25 06:45:25 2011] [error] [client 10.16.78.140] File
/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py, line 141, in
__call__
[Wed May 25 06:45:25 2011] [error] [client 10.16.78.140]
self.create_context(ccache=environ.get('KRB5CCNAME'))
[Wed May 25 06:45:25 2011] [error] [client 10.16.78.140] File
[Freeipa-devel] [PATCH] 069 Improve interactive mode for DNS plugin
Interactive mode for commands manipulating with DNS records (dnsrecord-add, dnsrecord-del) is not usable. This patch enhances the server framework with new callback for interactive mode, which can be used by commands to inject their own interactive handling. The callback is then used to improve aforementioned commands' interactive mode. https://fedorahosted.org/freeipa/ticket/1018 From 25ece379e5982f28797e2fe5928511240bb0bfa5 Mon Sep 17 00:00:00 2001 From: Martin Kosek mko...@redhat.com Date: Thu, 26 May 2011 09:55:53 +0200 Subject: [PATCH] Improve interactive mode for DNS plugin Interactive mode for commands manipulating with DNS records (dnsrecord-add, dnsrecord-del) is not usable. This patch enhances the server framework with new callback for interactive mode, which can be used by commands to inject their own interactive handling. The callback is then used to improve aforementioned commands' interactive mode. https://fedorahosted.org/freeipa/ticket/1018 --- ipalib/cli.py | 35 ipalib/plugins/baseldap.py | 43 +++ ipalib/plugins/dns.py | 129 +--- 3 files changed, 188 insertions(+), 19 deletions(-) diff --git a/ipalib/cli.py b/ipalib/cli.py index 99f236bb4103c8524320b03aa4a311689ecef8e8..b33449842c3d3929c2d669b4610ca146a57c8f16 100644 --- a/ipalib/cli.py +++ b/ipalib/cli.py @@ -527,6 +527,38 @@ class textui(backend.Backend): return None return self.decode(data) +def prompt_yesno(self, label, default=None): + +Prompt user for yes/no input. + + +default_prompt = None +if default is not None: +if default: +default_prompt = Yes +else: +default_prompt = No + + +if default_prompt: +prompt = u'%s Yes/No (default %s): ' % (label, default_prompt) +else: +prompt = u'%s Yes/No: ' % label + +result=None +while result is None: +try: +data = raw_input(self.encode(prompt)).lower() +except EOFError: +return None + +if data in (u'yes', u'y'): +return True +elif data in ( u'n', u'no'): +return False +elif default is not None and data == u'': +return default + def prompt_password(self, label): Prompt user for a password or read it in via stdin depending @@ -1032,6 +1064,9 @@ class cli(backend.Executioner): param.label ) +for callback in getattr(cmd, 'INTERACTIVE_PROMPT_CALLBACKS', []): +callback(kw) + def load_files(self, cmd, kw): Load files from File parameters. diff --git a/ipalib/plugins/baseldap.py b/ipalib/plugins/baseldap.py index 43533c8c969e368f450cb049235816db8a954b46..0cc11a8fdc9f312288928b96d53ba10d662adc32 100644 --- a/ipalib/plugins/baseldap.py +++ b/ipalib/plugins/baseldap.py @@ -450,12 +450,17 @@ class CallbackInterface(Method): self.__class__.POST_CALLBACKS = [] if not hasattr(self.__class__, 'EXC_CALLBACKS'): self.__class__.EXC_CALLBACKS = [] +if not hasattr(self.__class__, 'INTERACTIVE_PROMPT_CALLBACKS'): +self.__class__.INTERACTIVE_PROMPT_CALLBACKS = [] if hasattr(self, 'pre_callback'): self.register_pre_callback(self.pre_callback, True) if hasattr(self, 'post_callback'): self.register_post_callback(self.post_callback, True) if hasattr(self, 'exc_callback'): self.register_exc_callback(self.exc_callback, True) +if hasattr(self, 'interactive_prompt_callback'): +self.register_interactive_prompt_callback( +self.interactive_prompt_callback, True) #pylint: disable=E1101 super(Method, self).__init__() @classmethod @@ -488,6 +493,16 @@ class CallbackInterface(Method): else: klass.EXC_CALLBACKS.append(callback) +@classmethod +def register_interactive_prompt_callback(klass, callback, first=False): +assert callable(callback) +if not hasattr(klass, 'INTERACTIVE_PROMPT_CALLBACKS'): +klass.INTERACTIVE_PROMPT_CALLBACKS = [] +if first: +klass.INTERACTIVE_PROMPT_CALLBACKS.insert(0, callback) +else: +klass.INTERACTIVE_PROMPT_CALLBACKS.append(callback) + def _call_exc_callbacks(self, args, options, exc, call_func, *call_args, **call_kwargs): rv = None for i in xrange(len(getattr(self, 'EXC_CALLBACKS', []))): @@ -635,6 +650,9 @@ class LDAPCreate(CallbackInterface, crud.Create): def exc_callback(self, keys, options, exc, call_func, *call_args, **call_kwargs): raise exc +def interactive_prompt_callback(self, kw): +return + # list of attributes we want exported to JSON
Re: [Freeipa-devel] [PATCH] 0227-2-automount-UI
On 5/25/2011 7:58 PM, Adam Young wrote:
17. The adder dialog boxes for map and key don't have a title. The
titles should be defined in internal.py and the ipa_init.json needs
to be regenerated.
Fixed
The ipa_init.json doesn't seem to be updated yet.
More changes in this patch. I combined most of the search and nested
search facet into a single fact, by adding a field : managed_entity.
THat way, the facet can still track the entity to which it belongs, but
it performs searches on the managed entity. Most of the code from
nested_entity_facet could then be removed.
I also fixed search and the back to list links.
19. The unit test failed.
20. When viewing a map, 'back to list' will bring you to locations
instead of maps.
21. Please see the attached patch. The managed_entity variable and
neseted_search_facet can be removed.
--
Endi S. Dewata
diff --git a/install/ui/automount.js b/install/ui/automount.js
index f865fe7..f48fd9d 100644
--- a/install/ui/automount.js
+++ b/install/ui/automount.js
@@ -35,7 +35,7 @@ IPA.entity_factories.automountlocation = function() {
}).
nested_search_facet({
facet_group: 'member',
-nested_entity : 'automountmap',
+entity_name : 'automountmap',
label : IPA.metadata.objects.automountmap.label,
name: 'maps',
columns:['automountmapname']
@@ -60,7 +60,7 @@ IPA.entity_factories.automountmap = function() {
containing_entity('automountlocation').
nested_search_facet({
facet_group: 'member',
-nested_entity : 'automountkey',
+entity_name : 'automountkey',
label : IPA.metadata.objects.automountkey.label,
name: 'keys',
columns:['description']
diff --git a/install/ui/entity.js b/install/ui/entity.js
index 889b6be..1db44e3 100644
--- a/install/ui/entity.js
+++ b/install/ui/entity.js
@@ -730,10 +730,9 @@ IPA.entity_builder = function(){
that.nested_search_facet = function(spec) {
-spec.entity_name = entity.name;
spec.label = spec.label || IPA.messages.facets.search;
-var factory = spec.factory || IPA.nested_search_facet;
+var factory = spec.factory || IPA.search_facet;
facet = factory(spec);
entity.add_facet(facet);
diff --git a/install/ui/search.js b/install/ui/search.js
index 450b8a6..e25a42b 100644
--- a/install/ui/search.js
+++ b/install/ui/search.js
@@ -161,12 +161,20 @@ IPA.search_facet = function(spec) {
that.show = function() {
that.facet_show();
-that.entity.header.set_pkey(null);
-that.entity.header.back_link.css('visibility', 'hidden');
-that.entity.header.facet_tabs.css('visibility', 'hidden');
+var pkey = $.bbq.getState(that.entity.name + '-pkey', true) || '';
+that.entity.header.set_pkey(pkey);
+
+// if this is a nested entity show back link and facet tabs
+if (that.entity.containing_entity) {
+that.entity.header.back_link.css('visibility', 'visible');
+that.entity.header.facet_tabs.css('visibility', 'visible');
+} else {
+that.entity.header.back_link.css('visibility', 'hidden');
+that.entity.header.facet_tabs.css('visibility', 'hidden');
+}
if (that.filter) {
-var filter = $.bbq.getState(that.entity_name + '-filter', true) || '';
+var filter = $.bbq.getState(that.managed_entity_name + '-filter', true) || '';
that.filter.val(filter);
}
};
@@ -261,7 +269,24 @@ IPA.search_facet = function(spec) {
};
that.refresh = function() {
-that.search_refresh(that.entity);
+
+var pkey = $.bbq.getState(that.entity.name + '-pkey', true) || '';
+
+// if this is a nested entity but no pkey specified then redirect
+if (that.entity.containing_entity !pkey that.entity.redirect_facet) {
+
+var current_entity = that.entity;
+while (current_entity.containing_entity){
+current_entity = current_entity.containing_entity;
+}
+
+IPA.nav.show_page(
+current_entity.name,
+that.entity.redirect_facet);
+return;
+}
+
+that.search_refresh(that.managed_entity);
};
that.search_refresh = function(entity){
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 790 document problems re-adding a replication
Simo Sorce wrote: On Wed, 2011-05-25 at 12:39 -0400, Rob Crittenden wrote: Simo Sorce wrote: On Wed, 2011-05-25 at 09:09 -0400, Rob Crittenden wrote: Dmitri Pal wrote: On 05/24/2011 04:21 PM, Rob Crittenden wrote: If you create a replica, remove it, then re-add it and try to re-initialize the database it will fail because the remote master has the old service principal cached. The remote dirsrv needs to be restarted. This is the issue in the disaster recovery case too, right? Yes, any time a replica is removed and re-added. I would add: within a short time frame If the replica is removed today and readded in one week there should be no problem because any ticket will have been expired so libgssapi will acquire a new one. Simo. Sure, makes sense. Patch revised. ACK Simo. pushed to master and ipa-2-0 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Summary of Session discussion
There are four cases where we've discussed using sessions for optimizations. During today's phone discussion we analysed them. 1. Avoiding the negotiate round trip. Requesting a page protected by Kerberos requires two round trips to the server: 1 for the initializ request, which gets denied with the negotiate challenge, and one for the negotiate response. mod_auth_kerb can fall back to userid/password. THe suggestion was t hat we allow mod_auth_kerb to set a session cookie after a successful negotiate request. Future requests can use that cookie to bypass the negotiate handshake. The problem with this approach is NFS home directories, and root users being able to get access to the session cookies, allowing a replay attack. Note that this is a problem with the userid/password fall-back as well. We are not going to pursue this right now. 2. Caching the service ticket. Once the http request has gone through, the ipa web server needs to request a service ticket for LDAP. If the session contained the service ticket, the could be bypassed for additional requests. Since the request has to be validated by Kerberos for the initial negotiate call, there is no additional loss of security in caching the ticket. A potential alternative to server side caching is for the client to request the service ticket and send it in the negotiate handshake. There is some question as to whether the web server would be able to acces this ticket, and also whether the client can somehow request a ticket that the server can use, and still comply with the Kerberos standards. 3. File Upload. Session time out provides a means to automate the clean up of files that might otherwise be orphaned. 4. Windowing search results. the 'find' APIs as implemented by LDAP limit the responses to 200 records by default. One request we've had is to provide sorting and windowing. Windowing here is defined as, for a sorted response, return a delimited number of records starting at an offset greater than 0. The LDAP implementation requires the equivalent of a cursor from the requester, in this case the Apache server. To maintain association between the user and the cursor, the cursor identifier would be stored in the session. Implementing this correctly will require further design. It will likely be done in the future. In summary, the caching of the service ticket alone provides a compelling reason to implement sessions. File upload will take advantage of them. Other uses may be found over time. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Summary of Session discussion
On Thu, 2011-05-26 at 12:53 -0400, Adam Young wrote: There are four cases where we've discussed using sessions for optimizations. During today's phone discussion we analysed them. 1. Avoiding the negotiate round trip. Requesting a page protected by Kerberos requires two round trips to the server: 1 for the initializ request, which gets denied with the negotiate challenge, and one for the negotiate response. mod_auth_kerb can fall back to userid/password. THe suggestion was t hat we allow mod_auth_kerb to set a session cookie after a successful negotiate request. Future requests can use that cookie to bypass the negotiate handshake. The problem with this approach is NFS home directories, Can you expand the reasoning about NFS home directories ? and root users being able to get access to the session cookies, allowing a replay attack. Root can simply steal your TGT, that is not a concern we have any reason to raise here. Note that this is a problem with the userid/password fall-back as well. We are not going to pursue this right now. We are not going to pursue using sessions ? Or concerning ourselves with these issues ? :) 2. Caching the service ticket. Once the http request has gone through, the ipa web server needs to request a service ticket for LDAP. If the session contained the service ticket, the could be bypassed for additional requests. Since the request has to be validated by Kerberos for the initial negotiate call, there is no additional loss of security in caching the ticket. Indeed. A potential alternative to server side caching is for the client to request the service ticket and send it in the negotiate handshake. There is some question as to whether the web server would be able to acces this ticket, and also whether the client can somehow request a ticket that the server can use, and still comply with the Kerberos standards. This should be possible, but there is no client that can do that right now, and changing clients is simply out of our reach in most cases. 3. File Upload. Session time out provides a means to automate the clean up of files that might otherwise be orphaned. What kind of files ? 4. Windowing search results. the 'find' APIs as implemented by LDAP limit the responses to 200 records by default. One request we've had is to provide sorting and windowing. Windowing here is defined as, for a sorted response, return a delimited number of records starting at an offset greater than 0. The LDAP implementation requires the equivalent of a cursor from the requester, in this case the Apache server. To maintain association between the user and the cursor, the cursor identifier would be stored in the session. Implementing this correctly will require further design. It will likely be done in the future. The cursor need also to be associated to a specific query, cannot be just a session-global variable. In summary, the caching of the service ticket alone provides a compelling reason to implement sessions. File upload will take advantage of them. Other uses may be found over time. Very good, thanks for taking up on this analysis task. 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] Summary of Session discussion
On 05/26/2011 02:01 PM, Simo Sorce wrote: On Thu, 2011-05-26 at 12:53 -0400, Adam Young wrote: There are four cases where we've discussed using sessions for optimizations. During today's phone discussion we analysed them. 1. Avoiding the negotiate round trip. Requesting a page protected by Kerberos requires two round trips to the server: 1 for the initializ request, which gets denied with the negotiate challenge, and one for the negotiate response. mod_auth_kerb can fall back to userid/password. THe suggestion was t hat we allow mod_auth_kerb to set a session cookie after a successful negotiate request. Future requests can use that cookie to bypass the negotiate handshake. The problem with this approach is NFS home directories, Can you expand the reasoning about NFS home directories ? Cookie can be stored on the home directory of the user and user home directory can be NFS mounted so if we save anything important in the cookie the NFS root would be able to impersonate the user. It assumes that TGTs are not stored on the NFS in this case so replacing the TGT auth with fast session cookie auth would be a security issue. I hope I understand the issue correctly. and root users being able to get access to the session cookies, allowing a replay attack. Root can simply steal your TGT, that is not a concern we have any reason to raise here. NFS root? Note that this is a problem with the userid/password fall-back as well. We are not going to pursue this right now. We are not going to pursue using sessions ? Or concerning ourselves with these issues ? :) We are not going to try to avoid kerberos renegotiation on every request. Hm should we consider something like Oauth in this case? 2. Caching the service ticket. Once the http request has gone through, the ipa web server needs to request a service ticket for LDAP. If the session contained the service ticket, the could be bypassed for additional requests. Since the request has to be validated by Kerberos for the initial negotiate call, there is no additional loss of security in caching the ticket. Indeed. In any case if we cache the ldap ticket we need to get it from the cache before finishing the request. The question came up: is the python-kerberos/krbV packages provide the interface to the CC to get the ticket. A potential alternative to server side caching is for the client to request the service ticket and send it in the negotiate handshake. There is some question as to whether the web server would be able to acces this ticket, and also whether the client can somehow request a ticket that the server can use, and still comply with the Kerberos standards. This should be possible, but there is no client that can do that right now, and changing clients is simply out of our reach in most cases. We can do it in the XML-RPC/JSON outside of kerberos but is it worth it? We need to extract the ticket first. 3. File Upload. Session time out provides a means to automate the clean up of files that might otherwise be orphaned. What kind of files ? Entitlements 4. Windowing search results. the 'find' APIs as implemented by LDAP limit the responses to 200 records by default. One request we've had is to provide sorting and windowing. Windowing here is defined as, for a sorted response, return a delimited number of records starting at an offset greater than 0. The LDAP implementation requires the equivalent of a cursor from the requester, in this case the Apache server. To maintain association between the user and the cursor, the cursor identifier would be stored in the session. Implementing this correctly will require further design. It will likely be done in the future. The cursor need also to be associated to a specific query, cannot be just a session-global variable. You can limit it to have one cursor open per session at a time so you can use it as session global. You do not need to have to queries paginated at the same time from UI so there is no need to keep more than one cursor. In summary, the caching of the service ticket alone provides a compelling reason to implement sessions. File upload will take advantage of them. Other uses may be found over time. Very good, thanks for taking up on this analysis task. Simo. -- 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] Summary of Session discussion
On Thu, 2011-05-26 at 14:19 -0400, Dmitri Pal wrote: On 05/26/2011 02:01 PM, Simo Sorce wrote: On Thu, 2011-05-26 at 12:53 -0400, Adam Young wrote: There are four cases where we've discussed using sessions for optimizations. During today's phone discussion we analysed them. 1. Avoiding the negotiate round trip. Requesting a page protected by Kerberos requires two round trips to the server: 1 for the initializ request, which gets denied with the negotiate challenge, and one for the negotiate response. mod_auth_kerb can fall back to userid/password. THe suggestion was t hat we allow mod_auth_kerb to set a session cookie after a successful negotiate request. Future requests can use that cookie to bypass the negotiate handshake. The problem with this approach is NFS home directories, Can you expand the reasoning about NFS home directories ? Cookie can be stored on the home directory of the user and user home directory can be NFS mounted so if we save anything important in the cookie the NFS root would be able to impersonate the user. It assumes that TGTs are not stored on the NFS in this case so replacing the TGT auth with fast session cookie auth would be a security issue. I hope I understand the issue correctly. We can store the the cookie in the ccache, so that we have it in the same place the TGT is. We shouldn't save it in the home, as it is insecure indeed. and root users being able to get access to the session cookies, allowing a replay attack. Root can simply steal your TGT, that is not a concern we have any reason to raise here. NFS root? if by NFS root you mean the root user on the NFS server serving out your home directories the answer is no. As the ccache is stored in files local to the system. Note that this is a problem with the userid/password fall-back as well. We are not going to pursue this right now. We are not going to pursue using sessions ? Or concerning ourselves with these issues ? :) We are not going to try to avoid kerberos renegotiation on every request. Why not ? Unless you have other concerns the one expressed above are all non-issues. Hm should we consider something like Oauth in this case? It would have exactly the same issues except it will be more complex to implement, so if you can do one you can do the other. 2. Caching the service ticket. Once the http request has gone through, the ipa web server needs to request a service ticket for LDAP. If the session contained the service ticket, the could be bypassed for additional requests. Since the request has to be validated by Kerberos for the initial negotiate call, there is no additional loss of security in caching the ticket. Indeed. In any case if we cache the ldap ticket we need to get it from the cache before finishing the request. EPARSE. The question came up: is the python-kerberos/krbV packages provide the interface to the CC to get the ticket. If python-krbV doesn't yet it should be relatively easy to add,l I expect no more than a couple days work to add enough functionality if it is not there. A potential alternative to server side caching is for the client to request the service ticket and send it in the negotiate handshake. There is some question as to whether the web server would be able to acces this ticket, and also whether the client can somehow request a ticket that the server can use, and still comply with the Kerberos standards. This should be possible, but there is no client that can do that right now, and changing clients is simply out of our reach in most cases. We can do it in the XML-RPC/JSON outside of kerberos but is it worth it? No, we do not want to get in the business of forwarding credential caches outside of the standard protocols, *that* is asking for trouble. We need to extract the ticket first. You do not have direct access to the credential cache from within the browser so you wouldn't be able to do that for the WebUI anyway. Building a whole mechanism like that just to optimized the CLI when we can do a much better job server side looks like a waste, plus it would force third party implementations that want to use the XML-RPC channel to do things they may possible not be able to do either, forcing them to the less efficient way. Not good. 3. File Upload. Session time out provides a means to automate the clean up of files that might otherwise be orphaned. What kind of files ? Entitlements I guess I miss too many details to understand this point, but given it doesn't seem to be relevant to the security aspect I think I'll just ignore for now. 4. Windowing search results. the 'find' APIs as implemented by LDAP limit the responses to 200 records by default. One request we've had is to provide sorting and windowing. Windowing here is defined as, for a sorted response, return a delimited number of records
Re: [Freeipa-devel] Summary of Session discussion
On 05/26/2011 02:19 PM, Dmitri Pal wrote: On 05/26/2011 02:01 PM, Simo Sorce wrote: On Thu, 2011-05-26 at 12:53 -0400, Adam Young wrote: There are four cases where we've discussed using sessions for optimizations. During today's phone discussion we analysed them. 1. Avoiding the negotiate round trip. Requesting a page protected by Kerberos requires two round trips to the server: 1 for the initializ request, which gets denied with the negotiate challenge, and one for the negotiate response. mod_auth_kerb can fall back to userid/password. THe suggestion was t hat we allow mod_auth_kerb to set a session cookie after a successful negotiate request. Future requests can use that cookie to bypass the negotiate handshake. The problem with this approach is NFS home directories, Can you expand the reasoning about NFS home directories ? Cookie can be stored on the home directory of the user and user home directory can be NFS mounted so if we save anything important in the cookie the NFS root would be able to impersonate the user. It assumes that TGTs are not stored on the NFS in this case so replacing the TGT auth with fast session cookie auth would be a security issue. I hope I understand the issue correctly. NOt secure cookies, so it is only an issue for the CLI. If the CLI can store the cookine in the key store, then we don't havea problem. and root users being able to get access to the session cookies, allowing a replay attack. Root can simply steal your TGT, that is not a concern we have any reason to raise here. NFS root? Root user on a different machine that is allowed to mount NFS has pretty much complete access to the NFS directories. The root user can su to an user on the system. Note that this is a problem with the userid/password fall-back as well. We are not going to pursue this right now. We are not going to pursue using sessions ? Or concerning ourselves with these issues ? :) We are not going to try to avoid kerberos renegotiation on every request. Hm should we consider something like Oauth in this case? OAuth suffers from the same issues. 2. Caching the service ticket. Once the http request has gone through, the ipa web server needs to request a service ticket for LDAP. If the session contained the service ticket, the could be bypassed for additional requests. Since the request has to be validated by Kerberos for the initial negotiate call, there is no additional loss of security in caching the ticket. Indeed. In any case if we cache the ldap ticket we need to get it from the cache before finishing the request. The question came up: is the python-kerberos/krbV packages provide the interface to the CC to get the ticket. A potential alternative to server side caching is for the client to request the service ticket and send it in the negotiate handshake. There is some question as to whether the web server would be able to acces this ticket, and also whether the client can somehow request a ticket that the server can use, and still comply with the Kerberos standards. This should be possible, but there is no client that can do that right now, and changing clients is simply out of our reach in most cases. We can do it in the XML-RPC/JSON outside of kerberos but is it worth it? We need to extract the ticket first. 3. File Upload. Session time out provides a means to automate the clean up of files that might otherwise be orphaned. What kind of files ? Entitlements 4. Windowing search results. the 'find' APIs as implemented by LDAP limit the responses to 200 records by default. One request we've had is to provide sorting and windowing. Windowing here is defined as, for a sorted response, return a delimited number of records starting at an offset greater than 0. The LDAP implementation requires the equivalent of a cursor from the requester, in this case the Apache server. To maintain association between the user and the cursor, the cursor identifier would be stored in the session. Implementing this correctly will require further design. It will likely be done in the future. The cursor need also to be associated to a specific query, cannot be just a session-global variable. You can limit it to have one cursor open per session at a time so you can use it as session global. You do not need to have to queries paginated at the same time from UI so there is no need to keep more than one cursor. In summary, the caching of the service ticket alone provides a compelling reason to implement sessions. File upload will take advantage of them. Other uses may be found over time. Very good, thanks for taking up on this analysis task. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0227-2-automount-UI
On 05/26/2011 09:30 AM, Endi Sukma Dewata wrote: On 5/25/2011 7:58 PM, Adam Young wrote: 17. The adder dialog boxes for map and key don't have a title. The titles should be defined in internal.py and the ipa_init.json needs to be regenerated. Fixed The ipa_init.json doesn't seem to be updated yet. More changes in this patch. I combined most of the search and nested search facet into a single fact, by adding a field : managed_entity. THat way, the facet can still track the entity to which it belongs, but it performs searches on the managed entity. Most of the code from nested_entity_facet could then be removed. I also fixed search and the back to list links. 19. The unit test failed. Fixed in pushed version 20. When viewing a map, 'back to list' will bring you to locations instead of maps. Deliberate. This is the right behaviour. What is questionable is the placement on the screen 21. Please see the attached patch. The managed_entity variable and neseted_search_facet can be removed. Will do in a future patch. ACKed in IRC by edewata and pushed to master ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 069 Improve interactive mode for DNS plugin
On 26.5.2011 14:32, Martin Kosek wrote: Interactive mode for commands manipulating with DNS records (dnsrecord-add, dnsrecord-del) is not usable. This patch enhances the server framework with new callback for interactive mode, which can be used by commands to inject their own interactive handling. The callback is then used to improve aforementioned commands' interactive mode. https://fedorahosted.org/freeipa/ticket/1018 ACK, works fine. Just a minor thing: $ git apply freeipa-mkosek-069-improve-interactive-mode-for-dns-plugin.patch freeipa-mkosek-069-improve-interactive-mode-for-dns-plugin.patch:33: trailing whitespace. freeipa-mkosek-069-improve-interactive-mode-for-dns-plugin.patch:41: trailing whitespace. freeipa-mkosek-069-improve-interactive-mode-for-dns-plugin.patch:289: trailing whitespace. freeipa-mkosek-069-improve-interactive-mode-for-dns-plugin.patch:193: new blank line at EOF. + warning: 4 lines add whitespace errors. Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 791 don't add IP address when creating zone
When creating a DNS zone if an IP address was passed in that address was
added to the record of the IPA server.
This was causing problems when creating new reverse zones for different
subnets with ipa-replica-prepare. If you padded in --ip_address then a
new reverse DNS zone would be created and the new IP would be added to
the IPA master. Installing the replica file would fail with odd errors.
ticket 1223
rob
From 783f1a3f5705cbba67d3109b310e11bbc9eb09c1 Mon Sep 17 00:00:00 2001
From: Rob Crittenden rcrit...@redhat.com
Date: Thu, 26 May 2011 14:30:17 -0400
Subject: [PATCH] Adding a forward record when creating a zone was adding bad aRecord.
The aRecord for the DNS server was getting a new aRecord for each
zone created. This occurred when a new reverse zone was created and
made the installation of a replics in the new subnet fail.
ticket 1223
---
ipalib/plugins/dns.py | 10 --
1 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py
index 3f8753d..4161a64 100644
--- a/ipalib/plugins/dns.py
+++ b/ipalib/plugins/dns.py
@@ -376,16 +376,6 @@ class dnszone_add(LDAPCreate):
entry_attrs['idnssoamname'] = nameserver
return dn
-def post_callback(self, ldap, dn, entry_attrs, *keys, **options):
-if 'ip_address' in options:
-nameserver = entry_attrs['idnssoamname'][0][:-1] # ends with a dot
-nsparts = nameserver.split('.')
-add_forward_record('.'.join(nsparts[1:]),
- nsparts[0],
- options['ip_address'])
-
-return dn
-
api.register(dnszone_add)
--
1.7.4
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 768 fix migration between v2 servers
Martin Kosek wrote: On Fri, 2011-04-08 at 10:24 -0400, Rob Crittenden wrote: Migration from a v2 server would fail because of our fake memberofindirect attribute. This isn't in any objectclass so would cause entries to fail to migrate. We can safely just remove it. Also remove any limits on time/size when searching for entries on the remote server. Otherwise only the number of entries configured in the local IPA server can be migrated. ticket 1124 rob Looks good, ACK. I tested a migration with users with memberofindirect + there were 700+ users. Even though the migration took quite a long time, all users were correctly migrated. Martin pushed to master and ipa-2-0 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 788 remove automountinformation from automount dns
On 05/23/2011 02:38 PM, Rob Crittenden wrote: In an attempt to support multiple direct maps we always included the automountinformation in the key dn. This makes showing keys impossible a bit of a catch-22. You want to get the mount info but to get it you need the mount info. This patch drops requiring automountinfo but if provided it'll use it to make the dn. This way we can have backwards compatibility for any existing maps but going forward only direct maps will have the info in it. --key is still required when dealing with keys, no way around that without doing a major API change, migrating data, etc. ticket 1229 rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel This approach still breaks many of the assumptions that the UI is built upon. First, the primary key is now description, which is will look odd to people. Second, the methods for show, add, and delete will require custom code. I think that, if ever there was a time to break the automount scheme, it is up front now when we don't have that embedded a user base. I'd rather get it right this time around then have to support an difficult implementation for a long time. The error doesn't get marshalled properly in JSON. u May 26 15:44:44 2011] [error] ipa: INFO: ad...@server15.ayoung.boston.devel.redhat.com: automountkey_find(u'default', u'auto.mnt', u'', all=False): SUCCESS [Thu May 26 15:44:46 2011] [error] ipa: ERROR: jsonserver.__call__(): [Thu May 26 15:44:46 2011] [error] Traceback (most recent call last): [Thu May 26 15:44:46 2011] [error] File /usr/lib/python2.7/site-packages/ipaserver/rpcserver.py, line 248, in __call__ [Thu May 26 15:44:46 2011] [error] response = self.wsgi_execute(environ) [Thu May 26 15:44:46 2011] [error] File /usr/lib/python2.7/site-packages/ipaserver/rpcserver.py, line 230, in wsgi_execute [Thu May 26 15:44:46 2011] [error] params = self.Command[name].args_options_2_params(*args, **options) [Thu May 26 15:44:46 2011] [error] File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 483, in args_options_2_params [Thu May 26 15:44:46 2011] [error] raise MaxArgumentError(name=self.name, count=self.max_args) [Thu May 26 15:44:46 2011] [error] MaxArgumentError: command 'automountkey_show' takes at most 2 arguments (END) ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Summary of Session discussion
On 05/26/2011 02:43 PM, Simo Sorce wrote: We need to extract the ticket first. You do not have direct access to the credential cache from within the browser so you wouldn't be able to do that for the WebUI anyway. I was talking about the server side. -- 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] Summary of Session discussion
On 05/26/2011 02:43 PM, Simo Sorce wrote: You can limit it to have one cursor open per session at a time so you can use it as session global. Dangerous. I have seen Adam's response. This functionality is easily extensible. You can start with one and then add hash. I do not see a use case in near future that would require more than one cursor to be open at a time per session. I am just voting for less work here as it can be enhanced when we need more than one. -- 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] [PATCH] 788 remove automountinformation from automount dns
On 05/26/2011 04:51 PM, Adam Young wrote: On 05/23/2011 02:38 PM, Rob Crittenden wrote: In an attempt to support multiple direct maps we always included the automountinformation in the key dn. This makes showing keys impossible a bit of a catch-22. You want to get the mount info but to get it you need the mount info. This patch drops requiring automountinfo but if provided it'll use it to make the dn. This way we can have backwards compatibility for any existing maps but going forward only direct maps will have the info in it. --key is still required when dealing with keys, no way around that without doing a major API change, migrating data, etc. ticket 1229 rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel This approach still breaks many of the assumptions that the UI is built upon. First, the primary key is now description, which is will look odd to people. Second, the methods for show, add, and delete will require custom code. I think that, if ever there was a time to break the automount scheme, it is up front now when we don't have that embedded a user base. I'd rather get it right this time around then have to support an difficult implementation for a long time. I thought we are clear about this. The patch needs to be reworked to allow --key or key as 3rd parameter and one of the two is required. Am I missing something? Adam didn't you just test the old patch that should have been withdrawn? The error doesn't get marshalled properly in JSON. u May 26 15:44:44 2011] [error] ipa: INFO: ad...@server15.ayoung.boston.devel.redhat.com: automountkey_find(u'default', u'auto.mnt', u'', all=False): SUCCESS [Thu May 26 15:44:46 2011] [error] ipa: ERROR: jsonserver.__call__(): [Thu May 26 15:44:46 2011] [error] Traceback (most recent call last): [Thu May 26 15:44:46 2011] [error] File /usr/lib/python2.7/site-packages/ipaserver/rpcserver.py, line 248, in __call__ [Thu May 26 15:44:46 2011] [error] response = self.wsgi_execute(environ) [Thu May 26 15:44:46 2011] [error] File /usr/lib/python2.7/site-packages/ipaserver/rpcserver.py, line 230, in wsgi_execute [Thu May 26 15:44:46 2011] [error] params = self.Command[name].args_options_2_params(*args, **options) [Thu May 26 15:44:46 2011] [error] File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 483, in args_options_2_params [Thu May 26 15:44:46 2011] [error] raise MaxArgumentError(name=self.name, count=self.max_args) [Thu May 26 15:44:46 2011] [error] MaxArgumentError: command 'automountkey_show' takes at most 2 arguments (END) ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- 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] [PATCH] 788 remove automountinformation from automount dns
On 05/26/2011 05:01 PM, Dmitri Pal wrote: On 05/26/2011 04:51 PM, Adam Young wrote: On 05/23/2011 02:38 PM, Rob Crittenden wrote: In an attempt to support multiple direct maps we always included the automountinformation in the key dn. This makes showing keys impossible a bit of a catch-22. You want to get the mount info but to get it you need the mount info. This patch drops requiring automountinfo but if provided it'll use it to make the dn. This way we can have backwards compatibility for any existing maps but going forward only direct maps will have the info in it. --key is still required when dealing with keys, no way around that without doing a major API change, migrating data, etc. ticket 1229 rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel This approach still breaks many of the assumptions that the UI is built upon. First, the primary key is now description, which is will look odd to people. Second, the methods for show, add, and delete will require custom code. I think that, if ever there was a time to break the automount scheme, it is up front now when we don't have that embedded a user base. I'd rather get it right this time around then have to support an difficult implementation for a long time. I thought we are clear about this. The patch needs to be reworked to allow --key or key as 3rd parameter and one of the two is required. Am I missing something? Adam didn't you just test the old patch that should have been withdrawn? There was nothing on the list under this patch, so I posted this. I decided to test it out to also see what happened. I told rcrit out of channel that I would see if I could make it work with this patch. The issue is not just the arguments, but also the fact that the pkey is the whole --key + --info combined into the description field. Thus, I think that just making the --key parameter optional is not sufficient. The error doesn't get marshalled properly in JSON. u May 26 15:44:44 2011] [error] ipa: INFO: ad...@server15.ayoung.boston.devel.redhat.com: automountkey_find(u'default', u'auto.mnt', u'', all=False): SUCCESS [Thu May 26 15:44:46 2011] [error] ipa: ERROR: jsonserver.__call__(): [Thu May 26 15:44:46 2011] [error] Traceback (most recent call last): [Thu May 26 15:44:46 2011] [error] File /usr/lib/python2.7/site-packages/ipaserver/rpcserver.py, line 248, in __call__ [Thu May 26 15:44:46 2011] [error] response = self.wsgi_execute(environ) [Thu May 26 15:44:46 2011] [error] File /usr/lib/python2.7/site-packages/ipaserver/rpcserver.py, line 230, in wsgi_execute [Thu May 26 15:44:46 2011] [error] params = self.Command[name].args_options_2_params(*args, **options) [Thu May 26 15:44:46 2011] [error] File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 483, in args_options_2_params [Thu May 26 15:44:46 2011] [error] raise MaxArgumentError(name=self.name, count=self.max_args) [Thu May 26 15:44:46 2011] [error] MaxArgumentError: command 'automountkey_show' takes at most 2 arguments (END) ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- 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 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Summary of Session discussion
On 05/26/2011 04:56 PM, Dmitri Pal wrote: On 05/26/2011 02:43 PM, Simo Sorce wrote: You can limit it to have one cursor open per session at a time so you can use it as session global. Dangerous. I have seen Adam's response. This functionality is easily extensible. You can start with one and then add hash. I do not see a use case in near future that would require more than one cursor to be open at a time per session. I am just voting for less work here as it can be enhanced when we need more than one. The term Session global is a little weird. If you mean that multiple requests in the same session can talk to the same cursor, then yes. Global implies multiple people can talk to it at once, and I do not mean that. So long as the cursor is read only it will not be a problem to share. If the user does a write, or wants to see changes that were made by other people, they need to explicitly refresh the cursor. As I said, getting this right requires thought, and should not be in the next release. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Summary of Session discussion
On 05/26/2011 05:19 PM, Adam Young wrote: The term Session global is a little weird. If you mean that multiple requests in the same session can talk to the same cursor, then yes. Global implies multiple people can talk to it at once, and I do not mean that. One cursor per session. The session is per user per connection. It is one global cursor for a session not a hash table or list of different cursors within a session. The latter IMO is not needed and an overhead. If you can't have session per connection then you would have to do what Simo suggests. So this brings me to the next point: Are all connections from one host started by the same user share the same session? If this is the case then uh ... bad ... than the hash is in fact needed. But this is really scary... -- 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] Summary of Session discussion
On 05/26/2011 05:23 PM, Dmitri Pal wrote: On 05/26/2011 05:19 PM, Adam Young wrote: The term Session global is a little weird. If you mean that multiple requests in the same session can talk to the same cursor, then yes. Global implies multiple people can talk to it at once, and I do not mean that. One cursor per session. The session is per user per connection. It is one global cursor for a session not a hash table or list of different cursors within a session. The latter IMO is not needed and an overhead. If you can't have session per connection then you would have to do what Simo suggests. So this brings me to the next point: Are all connections from one host started by the same user share the same session? If this is the case then uh ... bad ... than the hash is in fact needed. But this is really scary... That is the usual implementation. If I have a browser open, I want all of the requests made from that browser to go through the same session. If I have two browsers, say firefox and chrome, then they will have two different sessions. HTTP does not maintain a connection across mutliple requests...with a few exceptions, mostly to streamline the download of graphics etc for a single page. From a WebUI perspective, each JSON request would want to use the same session. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Summary of Session discussion
Dmitri Pal wrote: On 05/26/2011 05:19 PM, Adam Young wrote: The term Session global is a little weird. If you mean that multiple requests in the same session can talk to the same cursor, then yes. Global implies multiple people can talk to it at once, and I do not mean that. One cursor per session. The session is per user per connection. It is one global cursor for a session not a hash table or list of different cursors within a session. The latter IMO is not needed and an overhead. If you can't have session per connection then you would have to do what Simo suggests. So this brings me to the next point: Are all connections from one host started by the same user share the same session? If this is the case then uh ... bad ... than the hash is in fact needed. But this is really scary... Each new connection gets its own cookie (e.g. you don't pass a cookie in then you get one once you authenticate). To be honest, I was thinking about using the mod_session module but since we have only Apache 2.2.x it isn't available. We'll need to see what is available in the 2.x line. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 166 Fixed URL parameter parsing.
The $.bbq.getState() invocations have been modified not to coerce
URL parameter values to avoid parsing error.
Ticket #1208
--
Endi S. Dewata
From 0543036b5d59cb8769ee1857737fddf582613a13 Mon Sep 17 00:00:00 2001
From: Endi S. Dewata edew...@redhat.com
Date: Mon, 23 May 2011 17:48:37 -0500
Subject: [PATCH] Fixed URL parameter parsing.
The $.bbq.getState() invocations have been modified not to coerce
URL parameter values to avoid parsing error.
Ticket #1208
---
install/ui/associate.js | 45 ++---
install/ui/details.js|8
install/ui/dns.js| 14 +++---
install/ui/entity.js | 15 ++-
install/ui/hbac.js |8
install/ui/navigation.js |2 +-
install/ui/rule.js |2 +-
install/ui/search.js | 16
install/ui/sudo.js | 12 ++--
install/ui/widget.js | 23 ---
10 files changed, 71 insertions(+), 74 deletions(-)
diff --git a/install/ui/associate.js b/install/ui/associate.js
index b237d326f6bb0776633584599726e5eddd07bbbd..3ba510f10caf502cfa3323137b6a4eba27afbc72 100644
--- a/install/ui/associate.js
+++ b/install/ui/associate.js
@@ -527,7 +527,7 @@ IPA.association_table_widget = function (spec) {
};
that.create_add_dialog = function() {
-var pkey = $.bbq.getState(that.entity_name + '-pkey', true) || '';
+var pkey = $.bbq.getState(that.entity_name+'-pkey');
var label = IPA.metadata.objects[that.other_entity].label;
var title = IPA.messages.association.add;
@@ -575,7 +575,7 @@ IPA.association_table_widget = function (spec) {
that.add = function(values, on_success, on_error) {
-var pkey = $.bbq.getState(that.entity_name + '-pkey', true) || '';
+var pkey = $.bbq.getState(that.entity_name+'-pkey');
var command = IPA.command({
entity: that.entity_name,
@@ -600,7 +600,7 @@ IPA.association_table_widget = function (spec) {
return;
}
-var pkey = $.bbq.getState(that.entity_name + '-pkey', true) || '';
+var pkey = $.bbq.getState(that.entity_name+'-pkey');
var label = IPA.metadata.objects[that.other_entity].label;
var title = IPA.messages.association.remove;
@@ -638,7 +638,7 @@ IPA.association_table_widget = function (spec) {
that.remove = function(values, on_success, on_error) {
-var pkey = $.bbq.getState(that.entity_name + '-pkey', true) || '';
+var pkey = $.bbq.getState(that.entity_name+'-pkey');
var command = IPA.command({
entity: that.entity_name,
@@ -653,6 +653,29 @@ IPA.association_table_widget = function (spec) {
command.execute();
};
+that.refresh = function() {
+
+function on_success(data, text_status, xhr) {
+that.load(data.result.result);
+}
+
+function on_error(xhr, text_status, error_thrown) {
+var summary = $('span[name=summary]', that.tfoot).empty();
+summary.append('pError: '+error_thrown.name+'/p');
+summary.append('p'+error_thrown.message+'/p');
+}
+
+var pkey = $.bbq.getState(that.entity_name+'-pkey');
+IPA.command({
+entity: that.entity_name,
+method: 'show',
+args: [pkey],
+options: {'all': true, 'rights': true},
+on_success: on_success,
+on_error: on_error
+}).execute();
+};
+
// methods that should be invoked by subclasses
that.association_table_widget_init = that.init;
@@ -787,7 +810,7 @@ IPA.association_facet = function (spec) {
};
that.is_dirty = function() {
-var pkey = $.bbq.getState(that.entity_name + '-pkey', true) || '';
+var pkey = $.bbq.getState(that.entity_name+'-pkey');
return pkey != that.pkey;
};
@@ -795,7 +818,7 @@ IPA.association_facet = function (spec) {
that.facet_create_header(container);
-that.pkey = $.bbq.getState(that.entity_name + '-pkey', true) || '';
+that.pkey = $.bbq.getState(that.entity_name+'-pkey');
var other_label = IPA.metadata.objects[that.other_entity].label;
var title = that.title;
@@ -845,7 +868,7 @@ IPA.association_facet = function (spec) {
that.show = function() {
that.facet_show();
-that.pkey = $.bbq.getState(that.entity_name+'-pkey', true) || '';
+that.pkey = $.bbq.getState(that.entity_name+'-pkey');
that.entity.header.set_pkey(that.pkey);
that.entity.header.back_link.css('visibility', 'visible');
@@ -854,7 +877,7 @@ IPA.association_facet = function (spec) {
that.show_add_dialog = function() {
-var pkey = $.bbq.getState(that.entity_name + '-pkey', true) || '';
+var pkey = $.bbq.getState(that.entity_name+'-pkey');
var label = IPA.metadata.objects[that.other_entity] ?
Re: [Freeipa-devel] [PATCH] 166 Fixed URL parameter parsing.
On 05/26/2011 06:24 PM, Endi Sukma Dewata wrote: The $.bbq.getState() invocations have been modified not to coerce URL parameter values to avoid parsing error. Ticket #1208 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Shouldn't we replace most of these with something along the lines of: that.entity.get_primary_key() ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 166 Fixed URL parameter parsing.
On 05/26/2011 08:30 PM, Adam Young wrote: On 05/26/2011 06:24 PM, Endi Sukma Dewata wrote: The $.bbq.getState() invocations have been modified not to coerce URL parameter values to avoid parsing error. Ticket #1208 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Shouldn't we replace most of these with something along the lines of: that.entity.get_primary_key() ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Regardless, it works, and that fix could be done later. ACK ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 166 Fixed URL parameter parsing.
On 05/26/2011 08:30 PM, Adam Young wrote: On 05/26/2011 06:24 PM, Endi Sukma Dewata wrote: The $.bbq.getState() invocations have been modified not to coerce URL parameter values to avoid parsing error. Ticket #1208 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Shouldn't we replace most of these with something along the lines of: that.entity.get_primary_key() ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Pushed to Master ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 069 Improve interactive mode for DNS plugin
Martin Kosek wrote: Interactive mode for commands manipulating with DNS records (dnsrecord-add, dnsrecord-del) is not usable. This patch enhances the server framework with new callback for interactive mode, which can be used by commands to inject their own interactive handling. The callback is then used to improve aforementioned commands' interactive mode. https://fedorahosted.org/freeipa/ticket/1018 This works pretty nicely but it seems like with just a bit more it can be great. Can you add some doc examples for how this works? And you display the records now and then prompt for each to delete. Can you combine the two? For example: ipa dnsrecord-del greyoak.com lion No option to delete specific record provided. Delete all? Yes/No (default No): Current DNS record contents: A record: 192.168.166.32 Enter value(s) to remove: [A record]: If we know there is an record why not just prompt for each value yes/no to delete? The yes/no function needs more documentation on what default does too. It appears that the possible values are None/True/False and that None means that '' can be returned (which could still be evaluated as False if this isn't used right). rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
