summaryrefslogtreecommitdiffstats
path: root/ipa-client/ipa-install
diff options
context:
space:
mode:
authorJohn Dennis <jdennis@redhat.com>2012-12-04 18:20:17 -0500
committerRob Crittenden <rcritten@redhat.com>2012-12-10 12:45:09 -0500
commit9269e5d6ddc85716d2b03c7763cf4b8e1ca67cad (patch)
treeb050248fb740cda4f0ecc8f8304f67af39a0cc4d /ipa-client/ipa-install
parent2bdffa4375d3fb657e5b5a65cb326aff77e35e09 (diff)
downloadfreeipa-9269e5d6ddc85716d2b03c7763cf4b8e1ca67cad.tar.gz
freeipa-9269e5d6ddc85716d2b03c7763cf4b8e1ca67cad.tar.xz
freeipa-9269e5d6ddc85716d2b03c7763cf4b8e1ca67cad.zip
Compliant client side session cookie behavior
In summary this patch does: * Follow the defined rules for cookies when: - receiving a cookie (process the attributes) - storing a cookie (store cookie + attributes) - sending a cookie + validate the cookie domain against the request URL + validate the cookie path against the request URL + validate the cookie expiration + if valid then send only the cookie, no attribtues * Modifies how a request URL is stored during a XMLRPC request/response sequence. * Refactors a bit of the request/response logic to allow for making the decision whether to send a session cookie instead of full Kerberous auth easier. * The server now includes expiration information in the session cookie it sends to the client. The server always had the information available to prevent using an expired session cookie. Now that expiration timestamp is returned to the client as well and now the client will not send an expired session cookie back to the server. * Adds a new module and unit test for cookies (see below) Formerly we were always returning the session cookie no matter what the domain or path was in the URL. We were also sending the cookie attributes which are for the client only (used to determine if to return a cookie). The attributes are not meant to be sent to the server and the previous behavior was a protocol violation. We also were not checking the cookie expiration. Cookie library issues: We need a library to create, parse, manipulate and format cookies both in a client context and a server context. Core Python has two cookie libraries, Cookie.py and cookielib.py. Why did we add a new cookie module instead of using either of these two core Python libaries? Cookie.py is designed for server side generation but can be used to parse cookies on the client. It's the library we were using in the server. However when I tried to use it in the client I discovered it has some serious bugs. There are 7 defined cookie elements, it fails to correctly parse 3 of the 7 elements which makes it unusable because we depend on those elements. Since Cookie.py was designed for server side cookie processing it's not hard to understand how fails to correctly parse a cookie because that's a client side need. (Cookie.py also has an awkward baroque API and is missing some useful functionality we would have to build on top of it). cookielib.py is designed for client side. It's fully featured and obeys all the RFC's. It would be great to use however it's tightly coupled with another core library, urllib2.py. The http request and response objects must be urllib2 objects. But we don't use urllib2, rather we use httplib because xmlrpclib uses httplib. I don't see a reason why a cookie library should be so tightly coupled to a protocol library, but it is and that means we can't use it (I tried to just pick some isolated entrypoints for our use but I kept hitting interaction/dependency problems). I decided to solve the cookie library problems by writing a minimal cookie library that does what we need and no more than that. It is a new module in ipapython shared by both client and server and comes with a new unit test. The module has plenty of documentation, no need to repeat it here. Request URL issues: We also had problems in rpc.py whereby information from the request which is needed when we process the response is not available. Most important was the requesting URL. It turns out that the way the class and object relationships are structured it's impossible to get this information. Someone else must have run into the same issue because there was a routine called reconstruct_url() which attempted to recreate the request URL from other available information. Unfortunately reconstruct_url() was not callable from inside the response handler. So I decided to store the information in the thread context and when the request is received extract it from the thread context. It's perhaps not an ideal solution but we do similar things elsewhere so at least it's consistent. I removed the reconstruct_url() function because the exact information is now in the context and trying to apply heuristics to recreate the url is probably not robust. Ticket https://fedorahosted.org/freeipa/ticket/3022
Diffstat (limited to 'ipa-client/ipa-install')
-rwxr-xr-xipa-client/ipa-install/ipa-client-install5
1 files changed, 2 insertions, 3 deletions
diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa-client/ipa-install/ipa-client-install
index 7f50b2a2f..7c3290298 100755
--- a/ipa-client/ipa-install/ipa-client-install
+++ b/ipa-client/ipa-install/ipa-client-install
@@ -42,8 +42,7 @@ try:
from ipalib import api, errors
from ipapython.dn import DN
from ipapython.ssh import SSHPublicKey
- from ipapython import kernel_keyring
- from ipalib.rpc import COOKIE_NAME
+ from ipalib.rpc import delete_persistent_client_session_data
import SSSDConfig
from ConfigParser import RawConfigParser
from optparse import SUPPRESS_HELP, OptionGroup
@@ -1741,7 +1740,7 @@ def install(options, env, fstore, statestore):
# Clear out any current session keyring information
try:
- kernel_keyring.del_key(COOKIE_NAME % host_principal)
+ delete_persistent_client_session_data(host_principal)
except ValueError:
pass