-
Notifications
You must be signed in to change notification settings - Fork 48
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
base: develop
Are you sure you want to change the base?
Conversation
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:
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 |
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.
This is API breaking change.
…chingClientMixin I ran out of ideas for naming - name length reminds me Java.
b731408
to
d96ae81
Compare
@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 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:
|
I'm not sure about this approach especially because of API breakage. I'm marking this PR as draft one for now.