foodsoft
foodsoft copied to clipboard
Adopt printer plugin to use ActionCable
This is an overview of what is needed to adopt the printer plugin to ActionCable. (Please ignore the commits related to the Rails 5 update). I integrated it with the API controllers, but we need a new concept of "userless api keys". I created a simple config option for now, since I didn't find a matching concept in doorkeeper. (Another usecase for this userless api key would be a background job which synchronizes something with foodsoft and is not related to a user). I'd like to get some early feedback before cleaning it up.
I agree that we need some API keys that work without a user. I'll have a look at the different OAuth flows to see if anything is suitable.
I'll have a look at the different OAuth flows to see if anything is suitable.
@wvengen did you find a nice way for the api_key?
In theory we could use the client credentials grant type (see also here). This is especially meant for services without the context of a user. We could add a printer authorization scope. I didn't see this in the Applications configuration tab in Foodsoft, but it looks like Doorkeeper supports this (and see a spec). This is probably a little more complex then putting a key in the configuration file, but would keep keys for external applications in a single place, which I think is a good thing.
i use this already for the import foodsoft FinanctialTransaction
into another foodsoft as BankTransactions
in the austria fork, but this does not work reliable.
It often throws an OAuth2::Error
with invalid_grant: Die bereitgestellte Autorisierung ist inkorrekt, abgelaufen, widerrufen, ist mit einem anderen Client verknüpft oder der Redirection URI stimmt nicht mit der Autorisierungs-Anfrage überein.
, but then it works again without problems. IMHO this is a big show stoppper.
We could add a printer authorization scope.
of course
keep keys for external applications in a single place, which I think is a good thing.
i think so too (if it would work reliable)
Ouch, that doesn't sound too nice about the OAuth2::Error
(and I'm impressed you've already done something like that).
Did you find any clue with Doorkeeper?
Anyhow, this case would be slightly different, using the client credentials grant (no user context), so tiny chance it might work still.
Did you find any clue with Doorkeeper?
Unfortunately no and i wasn't able to make it 100% reproducible, which makes the whole bug hunting very frustrating.
#783 could explain the doorkeeper problem