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

[BUG]: HTTP caching middleware returns cached responses to wrong users #1660

Open
1 task done
DimitriosLisenko opened this issue Jan 17, 2024 · 4 comments
Open
1 task done
Labels
Status: Up for grabs Issues that are ready to be worked on by anyone Type: Bug Something isn't working as documented

Comments

@DimitriosLisenko
Copy link

DimitriosLisenko commented Jan 17, 2024

What happened?

In version 4.22.0 (and onwards), http.authorization 'Bearer', @bearer_token (which immediately sets the Authorization header) was changed to http.request :authorization, 'Bearer', @bearer_token, which instead adds the Faraday::Request::Authorization to the middleware chain, which sets the Authorization header when called.

Since the authorization middleware is added at the point of the request, while the caching middleware is added on Faraday initialization (as suggested in the README), it means that the HTTP caching middleware runs first, and the authorization middleware runs second.

This means that when the caching middleware runs, it does not have the Authorization header set, and therefore caches requests and then returns them without having the ability to know that these requests are for different users.

For example, GET /user/installations?per_page=100 should return different results for different users, but with the HTTP caching enabled, it does not.

I have a PR that fixes the issue here: https://github.com/octokit/octokit.rb/pull/1661/files. Open to other approaches as well.

Versions

Octokit v8.0.0, Ruby v3.2.2

Relevant log output

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct
@DimitriosLisenko DimitriosLisenko added Status: Triage This is being looked at and prioritized Type: Bug Something isn't working as documented labels Jan 17, 2024
Copy link

👋 Hi! Thank you for this contribution! Just to let you know, our GitHub SDK team does a round of issue and PR reviews twice a week, every Monday and Friday! We have a process in place for prioritizing and responding to your input. Because you are a part of this community please feel free to comment, add to, or pick up any issues/PRs that are labled with Status: Up for grabs. You & others like you are the reason all of this works! So thank you & happy coding! 🚀

@nickfloyd nickfloyd added Status: Up for grabs Issues that are ready to be worked on by anyone and removed Status: Triage This is being looked at and prioritized labels Jan 19, 2024
@nickfloyd
Copy link
Contributor

Hey @DimitriosLisenko, great catch! Thanks for tracking this down. Let us know if you'd be interested in fixing the issue and submitting a PR. For now I have labeled this as "Up For Grabs" so that the community can take a stab at getting this fixed as well. ❤️

@DimitriosLisenko
Copy link
Author

Hey @nickfloyd! I have already submitted a PR at https://github.com/octokit/octokit.rb/pull/1661/files :)

@nickfloyd
Copy link
Contributor

Hey @nickfloyd! I have already submitted a PR at https://github.com/octokit/octokit.rb/pull/1661/files :)

Oof, sorry about that I completely missed that. Thank you for the follow up and the contributions! We'll have a look shortly! ❤

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Up for grabs Issues that are ready to be worked on by anyone Type: Bug Something isn't working as documented
Projects
Status: 🔥 Backlog
Development

No branches or pull requests

2 participants