turingschool / johari_window_api

0 stars 0 forks source link

Fix census service #6

Closed s-espinosa closed 6 years ago

s-espinosa commented 6 years ago

@notmarkmiranda Can you take a look at this?

Changes

Changes the CensusService to get a new token for each request for student info rather than use tokens set in the environment.
Removes CENSUS_TOKEN from the application.sample.yml

Reasons for Changes

JohariWindowAPI was not pulling in cohorts from students. Appears that the token stored in the Heroku ENV was stale and therefore Census was telling us that we were unauthorized.
get_token was already built out, so just needed to change the request to use that token instead of a stored token.
With that change, appears that we no longer need CENSUS_TOKEN in the ENV.

Downsides

In order to get tests to pass with this change I had to delete cassettes.
Appears that the cassettes have been checked in.
Cassettes use filter_sensitive_data in spec/rails_helper.rb to make sure that the Census tokens are not committed.
The changed code doesn't register as CENSUS_TOKEN, so the token gets added to the cassettes.

Potential Solution

Delete the cassettes.
Commit.
Add cassettes to .gitignore
I never know if this works. It feels like every time I do this someone else manages to add the cassettes back in. Help?

Let me know what you think.

notmarkmiranda commented 6 years ago

@s-espinosa: I feel like you'll run in to this problem even without checking in cassettes. Everyone would have their own versions locally of the cassettes and eventually the tokens would go stale? Maybe I'm not understanding.

I think having the cassettes checked in is okay, we just need a solution that either mocks the response without a token, or a way to refresh tokens when that happens (similar to record new episodes)? At first google search: https://blog.element84.com/rails-vcr-tokens.html, this might be a possible solution? I'm not sure where the token goes in these requests.