This worked for now, but is SyntaxError in Python 3.9.0a6:
File "/usr/lib/python3.9/site-packages/ipapython/cookie.py", line 222
return'/'
^
SyntaxError: invalid string prefix
(The Python change might actually be reverted before 3.9 final,
but this can be fixed anyway.)
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Replace six.moves and six.StringIO/BytesIO imports with cannonical
Python 3 packages.
Note: six.moves.input behaves differently than builtin input function.
Therefore I left six.moves.input for now.
See: https://pagure.io/freeipa/issue/7715
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
In Python 3, six.integer_types is (int,). In most places, the alias can
be simply replaced with int. In other places, it was possible to
simplify the code by unpacking the tuple.
See: https://pagure.io/freeipa/issue/7715
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
In Python 3, six.string_types is just an alias for str.
See: https://pagure.io/freeipa/issue/7715
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
Python 2 had old style and new style classes. Python 3 has only new
style classes. There is no point to subclass from object any more.
See: https://pagure.io/freeipa/issue/7715
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
Remove all object-specific loggers, with the exception of `Plugin.log`,
which is now deprecated. Replace affected logger calls with module-level
logger calls.
Deprecate object-specific loggers in `ipa_log_manager.get_logger`.
Reviewed-By: Martin Basti <mbasti@redhat.com>
Add new pylint AST checker plugin which implements a check for imports
forbidden in IPA. Which imports are forbidden is configurable in pylintrc.
Provide default forbidden import configuration and disable the check for
existing forbidden imports in our code base.
Reviewed-By: Martin Basti <mbasti@redhat.com>
When cookie has Max-Age set it tries to get expiration by adding
to a timestamp. Without this patch the timestamp would be set to
None and thus the addition of timestamp + max_age fails
https://pagure.io/freeipa/issue/6718
Reviewed-By: Simo Sorce <ssorce@redhat.com>
Stop using memcache, use mod_auth_gssapi filesystem based ccaches.
Remove custom session handling, use mod_auth_gssapi and mod_session to
establish and keep a session cookie.
Add loopback to mod_auth_gssapi to do form absed auth and pass back a
valid session cookie.
And now that we do not remove ccaches files to move them to the
memcache, we can avoid the risk of pollutting the filesystem by keeping
a common ccache file for all instances of the same user.
https://fedorahosted.org/freeipa/ticket/5959
Signed-off-by: Simo Sorce <simo@redhat.com>
Reviewed-By: Jan Cholasta <jcholast@redhat.com>
Check for import errors with pylint to make sure new python package
dependencies are not overlooked.
https://fedorahosted.org/freeipa/ticket/6418
Reviewed-By: Petr Spacek <pspacek@redhat.com>
Reviewed-By: Martin Basti <mbasti@redhat.com>
Unused variables may:
* make code less readable
* create dead code
* potentialy hide issues/errors
Enabled check should prevent to leave unused variable in code
Check is locally disabled for modules that fix is not clear or easy or have too many occurences of
unused variables
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
Reviewed-By: Stanislav Laznicka <slaznick@redhat.com>
The module is renamed to xmlrpc.client in Python 3.
Reviewed-By: David Kupka <dkupka@redhat.com>
Reviewed-By: Jan Cholasta <jcholast@redhat.com>
Reviewed-By: Martin Basti <mbasti@redhat.com>
In Python 3, these modules are reorganized.
Reviewed-By: David Kupka <dkupka@redhat.com>
Reviewed-By: Jan Cholasta <jcholast@redhat.com>
Reviewed-By: Martin Basti <mbasti@redhat.com>
Add more dynamic attribute info to IPATypeChecker in make-lint. Remove
unnecessary pylint comments. Fix false positivies introduced by Pylint 0.26.
https://fedorahosted.org/freeipa/ticket/3379
The Expires attribute in a cookie is supposed to follow the RFC 822
(superseded by RFC 1123) date format. That format includes a weekday
abbreviation (e.g. Tue) which must be in English according to the
RFC's.
ipapython/cookie.py has methods to parse and format the Expires
attribute but they were based on strptime() and strftime() which
respects the locale. If a non-English locale is in effect the wrong
date string will be produced and/or it won't be able to parse the date
string.
The fix is to use the date parsing and formatting functions from
email.utils which specifically follow the RFC's and are not locale
sensitive.
This patch also updates the unit test to use email.utils as well.
The patch should be applied to the following branches:
Ticket: https://fedorahosted.org/freeipa/ticket/3313
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
