Skip to content
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

Updated compliance api requests to actually use refresh token correctly #1416

Merged
merged 2 commits into from
Jan 26, 2017

Conversation

brentm5
Copy link
Contributor

@brentm5 brentm5 commented Jan 18, 2017

We do not store a token in the config file but rather generate one on each command called. This also does not cache any tokens but generates them every time. Not sure if this is ideal or not but this a first pass and needs some work. Also there are no tests added yet. At this point just looking for feedback on the approach. This is to help solve #1414

@@ -55,6 +55,9 @@ def self.resolve(target) # rubocop:disable PerceivedComplexity, Metrics/Cyclomat
end
profile_fetch_url = Compliance::API.target_url(config, profile)
end
# We need to pass the token to the fetcher
config['token'] = Compliance::API.get_token(config)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at this it might make sense to just follow this convention everywhere. Just on each request we set the config['token'] so it lives the entire life of the command but then do not save this to disk.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea. In general we want to avoid having the configuration in our API. Right now, storing it on disk is the only way to share it with the fetcher, since they run independently.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So currently this does not save to disk so if that is a requirement this approach might need to be changed.

@@ -179,7 +179,7 @@ def upload(path) # rubocop:disable Metrics/MethodLength, Metrics/AbcSize, Percei
end

# determine user information
if config['token'].nil? || config['user'].nil?
if (config['token'].nil? && config['refresh_token'].nil?) || config['user'].nil?
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having one or the other is now a valid use case, if a token is still in the config it will default to using that (which is the legacy behavior

end
headers
end

def self.get_token(config)
return config['token'] unless config['refresh_token']

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we do not need the spaces here

@@ -344,11 +343,10 @@ def store_refresh_token(url, refresh_token, verify, user, insecure)
success = true
msg = 'API refresh token stored'
else
success, msg, access_token = Compliance::API.get_token_via_refresh_token(url, refresh_token, insecure)
success, msg = Compliance::API.get_token_via_refresh_token(url, refresh_token, insecure)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need the _access_token here as well

@@ -55,6 +55,9 @@ def self.resolve(target) # rubocop:disable PerceivedComplexity, Metrics/Cyclomat
end
profile_fetch_url = Compliance::API.target_url(config, profile)
end
# We need to pass the token to the fetcher
config['token'] = Compliance::API.get_token(config)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea. In general we want to avoid having the configuration in our API. Right now, storing it on disk is the only way to share it with the fetcher, since they run independently.

@brentm5
Copy link
Contributor Author

brentm5 commented Jan 19, 2017

@chris-rock are the functional tests known to have these failures or is that something I broke?

https://travis-ci.org/chef/inspec/jobs/193035548

@chris-rock
Copy link
Contributor

I am taking care of the functional tests right now.

@chris-rock
Copy link
Contributor

@brentm5 Can you rebase on latest master? functional tests are fixed there. I apologise for the inconvenience.

We do not store a token in the config file but rather generate one on
each commmand.  This is just a first pass and needs some work.

Signed-off-by: Montague, Brent <brent@bmontague.com>
Signed-off-by: Montague, Brent <brent@bmontague.com>
@brentm5
Copy link
Contributor Author

brentm5 commented Jan 25, 2017

@chris-rock Done

@chris-rock
Copy link
Contributor

Very nice improvement @brentm5

@chris-rock chris-rock merged commit 440c09e into inspec:master Jan 26, 2017
@brentm5 brentm5 deleted the bm-add-refresh-token branch January 26, 2017 21:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants