Also regenerate it frequently, so that any change in configuration can be
automatically reflected in the metadata downloaded my clients over time.

Signed-off-by: Simo Sorce <simo@redhat.com>

Signed-off-by: Simo Sorce <simo@redhat.com>

Signed-off-by: Simo Sorce <simo@redhat.com>

Signed-off-by: Simo Sorce <simo@redhat.com>

Signed-off-by: Patrick Uiterwijk <puiterwijk@redhat.com>
Reviewed-by: Simo Sorce <simo@redhat.com>

Test to see if the request parameter value is a cherrypy Part
class. This was already being done for the case where the value was a
list, but it was omitted for single values. Logic was combined into new
local function print_param().

Changed the test for the class back to using

    if isinstance(item, cherrypy._cpreqbody.Part):

instead of:

    if getattr(item, "part_class", None):

because using isinstance() clearly indicates what is being done. The
use of getattr() was introduced to prevent a pylint warning concering
use of protected values. The getattr() hack is confusing and proably
not robust if the class implementation changes. The patch now disables
this warning. I cannot explain why cherrypy marks these modules as
protected when clearly one has to utilize them and they are documented
in the cherrypy API doc. Disabling the warning seems the cleanest and
most robust approach.

Signed-off-by: John Dennis <jdennis@redhat.com>
Reviewed-by: Simo Sorce <simo@redhat.com>

Mea culpa for not checking before pushing

Signed-off-by: Simo Sorce <simo@redhat.com>
Reviewed-by: John Dennis <jdennis@redhat.com>

The log.debug() function helpfully adds the name of the function
invoking it but in a complicated software package there are many
functions/methods which share the same name. Thus a debug message
like this:

DEBUG(__init__): xxx

does not give you much context, there are probably hundreds of
__init__ methods. It would help to qualify the method name which it's
class name, that gives a lot more context when reading the
log. Sometimes it's also helpful to know the file and line number.

This patch adds the class name to the function and included the
filename and line number as well. The file path is trimmed to the last
3 components, sufficient to give context but not too verbose. Now the
debug message might look like this instead:

DEBUG(ipsilon/providers/common.py:129 LoadProviders.__init__()): xxx

Also included is a config option 'stacktrace_on_error' which will
include a stacktrace when the log.error function is called. It can be
very useful to see a stacktrace when logging an error, it defaults to
off.

Signed-off-by: John Dennis <jdennis@redhat.com>
Reviewed-by: Simo Sorce <simo@redhat.com>

The ability to easily review the HTTP Ipsilon request and response is
boon for development and issue debugging. Normally these HTTP
conversations occur on SSL/TLS encrypted connections making it
difficult to use other tools to view the traffic. Client side tools
have known pitfalls (e.g. Firebug) and not all conversations are
browser initiated (e.g. SAML ECP). Logging performed by the server
hosting Ipsilon makes logging at the server level server specific
(e.g. Apache's dumpio requires post-processing the log file to extract
and reassamble the HTTP conversation). The best place to log requests
and responses is within Ipsilon using the cherrypy framework
Ipsilon is embedded in. Cherrypy provides user defined hooks that can
be invoked at specific places in the request pipeline. We establish a
hook at the last stage just before the response is written to the
client, it logs the incoming request and outgoing response.

Resolves: https://fedorahosted.org/ipsilon/ticket/44

Signed-off-by: John Dennis <jdennis@redhat.com>
Reviewed-by: Simo Sorce <simo@redhat.com>

Signed-off-by: Patrick Uiterwijk <puiterwijk@redhat.com>