Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

High interface fetches hw address #130

Draft
wants to merge 4 commits into
base: develop
Choose a base branch
from

Conversation

scrool
Copy link
Owner

@scrool scrool commented Mar 8, 2022

I'm not sure about this approach especially because of API breakage. I'm marking this PR as draft one for now.

@Anders-Holst
Copy link
Contributor

Hi @scrool

Nice functionality of course. But are you not complicating things a little? The low-level ControlInterface is perfectly capable of retrieveing the hardware address (and the "gestalt" endpoint formally does not require authentication, so it is formally ok according to the protocol to make this call before the hw address is known). Adding that capability somewhere else (in auth.py) is code duplication and makes it less modular, in case the interface changes. So what I do in my version of HighControlInterface is to instead add a few lines to the init method:

    def __init__(self, host, hw_address=None):
        super(HighControlInterface, self).__init__(host, hw_address)
        info = self.get_device_info()
        if not self.hw_address:
            self.hw_address = info["mac"]
        ...

Problem solved. (And then I read out a couple of other things from info, needed to make the interface device independent, like number of leds, led profile, family, etc. Just in case you wonder why info is not set within the if statement.)

Anders

scrool added 4 commits March 26, 2022 16:26
Out of ValidatingClientMixin and ClientApplication and use it by
BaseUrlChallengeResponseAuthSession. Previously ClientApplication
inherited from ValidatingClientMixin which ended up to be in reverse
order how it should have been. And BaseUrlChallengeResponseAuthSession
used that. That didn't seem very flexible if one didn't want to use
validation.
…chingClientMixin

I ran out of ideas for naming - name length reminds me Java.
@scrool scrool force-pushed the high_interface_fetches_hw_address branch from b731408 to d96ae81 Compare March 26, 2022 15:31
@scrool
Copy link
Owner Author

scrool commented Mar 26, 2022

@Anders-Holst long story short I would like to provide authentication for API calls where one doesn't need to care about HW address and challenge-response is still validated on the background.

For a context, see a documentation in PR #134, rendered here: https://xled--134.org.readthedocs.build/en/134/auth.html . And then here is a snippet of doc that would exist for this (#130) PR:

BaseUrlChallengeResponseAuthHwAddressFetchingSession
----------------------------------------------------

Third approach uses `BaseUrlChallengeResponseAuthHwAddressFetchingSession`
which automatically fetches HW address if it is not passed so
challenge-response could be validated::

    >>> from xled.auth import BaseUrlChallengeResponseAuthHwAddressFetchingSession
    >>> from xled.response import ApplicationResponse
    >>>
    >>> base_url = "http://{}/xled/v1/".format(hostname)
    >>>
    >>> session = BaseUrlChallengeResponseAuthHwAddressFetchingSession(
    >>>     base_url=base_url
    >>> )
    >>>
    >>> response = session.get("summary")
    >>> ApplicationResponse(response)
    <Response [200]>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants