Add vanilla broker resource implementation for existing e2e-tests

[BarcoMasile]

Description

This PR builds on top of #659.

This adds the broker resource implementation for the e2e tests present.
It implements the login behavior in the vanilla/common/BrowserWindow.py file, with the device flow.

An important thing to note is that the python script for the vanilla broker does two additional things compared to the original one used as a template from the msentraid folder:

• it adds the implementation (leveraging only the standard library) of the TOTP generation, so a new parameter is needed, which is the secret key for the TOTP
• it adds an assertion at the end of the sign-in process, since there was no assertion initially, so the script didn't change exit value based on the actual success of the login flow: now it does and it communicates success/failure through 0/1 exit codes

[BarcoMasile]

As per offline agreement, I'm moving this to Draft
cc @denisonbarbosa @shipperizer

[3v1n0]

This class should be actually moved to a generic place and re-used in both msentraid and vanilla.

The only part that should change is in the test itself, so I'd try to just have a common class and override what we need in each implementation

[BarcoMasile]

Nice, I'll coordinate with Denison for this

[3v1n0]

Maybe we can also depend and rely on python3-pyotp here?

[BarcoMasile]

Given some struggles to make the python part working (dependency-wise) I prefered to stick to a basic implementation that relies on the standard library only, so it would not add on the requirements

[3v1n0]

Well, we already have dependency on non-standard library already since we rely on python3-gi and some gir files, so I feel it's not a big deal one more.

[3v1n0]

Note there's also python3-onetimepass, not sure which one is maintained better, pick the one you like better

[BarcoMasile]

I've evaluated both those libraries when I went with this implementation
It is very simple as you can see, so IMO it would be good either way.
But I'll sync with Denis on this so we're aligned, thanks

[3v1n0]

maybe this can be part of the "generic" class and this can be another parameter

[BarcoMasile]

Yes it could be, even though from what I'm told this implementation is ok to keep implementation speicific (relatively to the OIDC broker target of this e2e test, which is the Canonical Identity Platform)

[3v1n0]

keep implementation speicific (relatively to the OIDC broker target of this e2e test, which is the Canonical Identity Platform)

Yes, but the much code we can share the better, so I'd make sure that what lands in #659 is something generic enough to be overridden here, or you rebase and split it here.

[3v1n0]

This is not something we should do, as it may break many things (github diff is messed, i meant):

while Gtk.events_pending():
       Gtk.main_iteration()

Instead the code should be looking something like:

    js_result = None
    loop = GLib.MainLoop()

    def on_js_finished(webview, result):
        nonlocal js_result

        try:
            js_result = webview.evaluate_javascript_finish(result)
        except Exception as e: # TODO: filter exception...
            print(f"{e}")
            # We want to raise it too?
            # raise e
        loop.quit()

    webview.evaluate_javascript(js, -1, None, None, None, on_js_finished, None)
    loop.run()

    if js_result and js_result.to_string():
        return js_result.to_string()

    wait_for_timeout(delay)

Using: #659 (comment)

[3v1n0]

Nope, no time.sleep in UI components :)

See also #659 (comment)

EDIT: github diff is messed up, but well the reference should be clear

[BarcoMasile]

I know, I'm aware that this sleep stops the main thread, but apparently it is useful to have a super short delay between one try and the other, I couldn't actually explain myself why.
It's for "looking for" the sucess message.

I'll try to remove it, but being the peculiarity of the Gtk library behavior, I'm not sure it will not affect the code :-/

[3v1n0]

If you use the code above should be good enough, if not we've other problems... :)