bfca97f Compliant client side session cookie behavior

7 files Authored by jdennis 11 years ago, Committed by rcritten 11 years ago,
    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
    
        
file modified
+222 -58
file modified
+30 -16
file added
+699
file modified
+4 -2
file modified
+3 -1