Closed emptyflask closed 3 years ago
Hi, many thanks for your interest and contribution!
Before going on with this PR, I'd first like to check something with you. My hesitation is about the very necessity of the client_secret
, for both the Device Authorization Request and the Device Access Token Request (polling).
Using a client secret in this context seems at least unusual in principle, being the client almost certainly a "public" app.
Going further, I looked again at the RFC (respectively here and here), which is the original source of the POST request examples. The specs never mention a client secret - as far as I can see, not even indirectly. So, maybe, using a secret is even against the specs? (that's really a genuine question from my side!)
Last but not least, there's our naive sample application https://github.com/exop-group/doorkeeper-device-flow-example, which should work well with client requests closely modeled on the examples from the RFC (and readme).
Now, forgetting about the theory, I'd like in practice to better understand your use case, and possibly to reproduce a setup where I can get your original problem, that is, where the secrets are required in those requests to make them succeed.
Can you identify some obvious configuration settings that could explain that behavior? Or, if not, maybe you can just list your current ruby & gems versions, so that I can start making some attempts?
Thanks, Marco
I discovered the source of my troubles: Doorkeeper::Application#confidential
. Setting that field to false allows me to omit the client_secret
.
Thanks for pointing out my mistake!
I spent an hour or two trying to figure out why I couldn't get the examples to work, then noticed it was delegating the client lookup to
Doorkeeper::OAuth::Client.authenticate
, which requiresclient_secret
.