-
-
Notifications
You must be signed in to change notification settings - Fork 729
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
[Citi OFN Voucher] Add VINE connected app #12886
[Citi OFN Voucher] Add VINE connected app #12886
Conversation
The connection/disconnection logic is yet to be implemented
Generate a JWT token to be used to connect to the VINE api
6a6cc6e
to
0c2dfe1
Compare
0c2dfe1
to
bde2f54
Compare
It handles connection to the VINE API
Add logiv to connect and disconnect VINE API plus spec
bde2f54
to
22428fc
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work! This looks like a good fit for our "connected apps". I think there might be one line to clean up, other comments are pretty minor and don't need changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really nice work, well done. Just a few little tweaks... ✨
channel: SessionChannel.for_request(request)) | ||
end | ||
|
||
def connect_vine |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that we can leave it for now but it would be better to move app-specific logic into the apps and have the controller be agnostic of the app's needs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be honest I would prefer to have the connect logic to be separated from the model and having a service handle the connection bit before storing the result in the model.
But yeah, this should live in a service.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, too. If we take the logic out of the models then we don't really need a polymorphic model. The beauty of the polymorphic model is that it loads the right code automatically. But reducing models to data storage is really handy as well. Then we just need service objects that are coupled to app types. I'm not sure which is better. Maybe it's just that the VINE app has some additional logic that should go into a service.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I notice that we're validating the presence of two values now, which we want to store in the model. ActiveRecord validations are made for that kind of thing (I guess it would have to be a custom validation to handle the values inside the data blob, but it still seems appropriate).
I'm not sure it's worth moving the logic right now though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like we might need other connected apps to see if a pattern emerges before we can refine the design. Maybe VINE is the odd one who knows. If I get a bit of time, I'll look at moving the VINE logic to a service.
def connected_app_params | ||
params.permit(:type) | ||
params.permit(:type, :vine_api_key) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could ask the app to give us a list of allowed parameters.
The VINE Api require a secret and an API key to be used. The secret is used to sign the request. The secret is linked to the API key so we need to store it along side the key.
Added layer of security, we encrypt the API key and related secret. It requires setting up some encryption keys that can be generated wiht `bin/rails db:encryption:init`
74234c2
to
a3d8ae6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
I queried Paul about the different handling of the secret but let's go ahead with this for now. We can use this interface either way.
channel: SessionChannel.for_request(request)) | ||
end | ||
|
||
def connect_vine |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, too. If we take the logic out of the models then we don't really need a polymorphic model. The beauty of the polymorphic model is that it loads the right code automatically. But reducing models to data storage is really handy as well. Then we just need service objects that are coupled to app types. I'm not sure which is better. Maybe it's just that the VINE app has some additional logic that should go into a service.
.env
Outdated
# VINE API settings | ||
# VINE_API_URL="https://vine-staging.openfoodnetwork.org.au/api/v1" | ||
# VINE_API_SECRET="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was a bit too quick here, we stil need the VINE_API_URL
😅 , I'll fix that this afternoon
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, looking good, but as mentioned awaiting VINE_API_URL..
channel: SessionChannel.for_request(request)) | ||
end | ||
|
||
def connect_vine |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I notice that we're validating the presence of two values now, which we want to store in the model. ActiveRecord validations are made for that kind of thing (I guess it would have to be a custom validation to handle the values inside the data blob, but it still seems appropriate).
I'm not sure it's worth moving the logic right now though.
And add error handling if the variable is not set
The condition for checking the error now match a real scenario
@rioug all scenario are passing 🎉 I'm noticing that it is enough to be In the meantime, merging :) |
What? Why?
Add VINE connected app, it allows an enterprise to provide a VINE API key and secret to be able to use VINE voucher for their enterprise.
A user is part of a team, so a successful call to /my-team endpoint mean the API key and secret are valid. It means the the API key needs at a minimum the "My Team Read" ability in VINE.
What should we test?
Turn on "connected_apps" feature toggle.
Make sure you have a valid API key and secret for vine staging server : https://vine-staging.openfoodnetwork.org.au/login
In the back office, logged as a super admin, enable Voucher Integration Engine (VINE) :
Still logged as a super admin:
As an enterprise manager:
--> The API Key should get added to the enterprise, and you should see a "Disconnect" button
--> The API Key will be removed from the enterprise, and you should see an API Key and secret input and a "Connect" button
--> You should get an error message asking you to check if you entered your API Key and secret correctly
--> You should get an error message saying API Key and secret can't be blank
Release notes
Changelog Category (reviewers may add a label for the release notes):
The title of the pull request will be included in the release notes.
Dependencies
This PR requires an encryption key set to work :
Documentation updates