Sounds good. Please feel free to create a pull request on the repo with any suggested changes - all contributions are very welcome!
That is interesting - at the moment I am coding for the specific API servers which (touch wood) have so far responded with the opaque info but I will bear this in mind. I have noticed that even within the same API ecosystem the www-auth response varies in composition.
I attempt to do something similar with the latest version of the code (will commit the latest shortly but is still WIP so bear that in mind). The particular service that I have to use always returns a 401 when talking to the first [director] server so the response needs to be constructed afresh each time. The latest code moves onto the next server (that I call the ASN server) where 200 codes are returned and there is merit in constructing an auth header from stored values. Have a look and let me know what you think.
I can appreciate your point regarding the state variable being visible but from my perspective this is an acceptable security risk. You could always use @thebearmay idea of encryption or explore using th new concept of hub variables brought in with 2.2.8
P.S. if you are creating a driver then you might want to take a look at some of the earlier examples posted by @tomw. I do plan on creating a driver as well once I have the app working but it is slow going for me! ![]()