The new implementations of lasso_node_impl_init_from_xml now validate
namespace of all child nodes befores parsing. It stops on any error. For
node which implement their own parsing of an attribute or a node, it
must declare an XmlSnippet with an offset field set to 0. The 0 value is
invalid for public GObject structure (it's the place of the GObject
machinery like the reference count). The 0 offset can be used for
XmlSnippet in a private structure, so never set the offset to 0 with the
flag SNIPPET_PRIVATE, for a field which is parsed by you get_xmlNode
virtual method.
Other ameliorations in this commit is the possibility to set attributes
with namespace when using the flags SNIPPET_ATTRIBUTE|SNIPPET_ANY. The
syntax for an attribute is inspired by the element tree API from Python:
{namespace}attribute_name
an example:
{http://www.w3.org/2001/XMLSchema-instance}type
for the classic xsi:type attribute.
To allow lasso_node_impl_init_from_xmlnode to do proper namespace
checking, child node which are not of the same namespace as their parent
in their XSD schema must have an explicit namespace declared in the
XmlSnippet.
- now any non expected log output is considered an error, by setting a
g_log default handler.
- block_lasso_logs()/unblock_lasso_logs() will block logging output at
the DEBUG level
- begin_check_do_log(level, message, endswith)/end_check_do_log() with
check that the only message emitted between the two macros is one
equals to "message" at the level "level", or ending (to work around
variable parts in a log message) with "message" if "endswith" is True.
The added key can be appended or prepended, depending on the need for the key:
- rollover
- improving performances (using simpler cryptographic algorithmss using shared secret keys)
Using this method you can specify a signing which will be used for
communication with the specified provider instead of the one configured
on the LassoServer object. The main objective is to allow shared secret
cryptography instead of public key cryptography.
LassoKey currenly store a LassoSignatureContext inside a
reference-counted and bindable object. It will be used to export API
around key management to bindings.
This test case is the first to abstract the workflow between two
LassoLogin object (for the idp and sp side). This part of the code could
be used to simplify the code of other tests in the future.
The only expected decryption error is on decryption of the symetric key
used to crypt the data. All other errors are critical and must be
logged.
Client of lasso_node_decrypt_xmlnode can then log the decryption failure
of the symetric if they tried with all possible keys (key rollover
case).