This repository has been archived by the owner on Jan 24, 2019. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mbland
pushed a commit
to cloud-gov/oauth2_proxy
that referenced
this pull request
Jun 23, 2015
Per bitly#115, @jehiah noted that he encountered a cookie refresh bug whereby an empty cookie value was being set when --cookie-refresh was enabled. I was able to ascertain by studying the code that if the original cookie has expired, the "refresh" case would still be triggered, causing an empty cookie to be set. TestProcessCookieFailIfRefreshSetAndCookieExpired reproduces the bug when the `ok &&` component of the `ok && p.CookieRefresh != time.Duration(0)` expression within ProcessCookie() is removed. The bug is confirmed fixed when the `ok &&` component is reinstated. At the same time, it's now apparent that the effective cookie expiration period was always one week prior to @jehiah's changes, thanks to the timestamp in validateCookie() being compared against the hardcoded value `time.Duration(24)*7*time.Hour*-1`. TestProcessCookieFailIfCookieExpired confirms that @jehiah's changes solves this problem as well. I also took the liberty to add a comment to the timestamp comparison in validateCookie(), since it took effort to remind myself how it was supposed to work.
return | ||
} | ||
t = time.Unix(int64(ts), 0) | ||
if t.After(time.Now().Add(expiration*-1)) && t.Before(time.Now().Add(time.Minute*5)) { |
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.
Not sure of the utility of t.Before(time.Now().Add(time.Minute*5))
. Seems like it will always be true, unless there are clock skew issues between different oauth2_proxy instances running on different machines with the same cookie secret.
Thanks for the heads-up! I agree that this implementation does make more sense than the original. Aside from a couple minor comments, and jehiah#1 that I just sent to merge some regression tests and minor tweaks into this PR, it looks good otherwise. |
mbland
pushed a commit
to cloud-gov/oauth2_proxy
that referenced
this pull request
Jun 23, 2015
Helps to more clearly demonstrate that the empty cookie bug described in bitly#115 is caught by this test.
mbland
pushed a commit
to cloud-gov/oauth2_proxy
that referenced
this pull request
Jun 23, 2015
Per bitly#115, @jehiah noted that he encountered a cookie refresh bug whereby an empty cookie value was being set when --cookie-refresh was enabled. I was able to ascertain by studying the code that if the original cookie has expired, the "refresh" case would still be triggered, causing an empty cookie to be set. TestProcessCookieFailIfRefreshSetAndCookieExpired reproduces the bug when the `ok &&` component of the `ok && p.CookieRefresh != time.Duration(0)` expression within ProcessCookie() is removed. The bug is confirmed fixed when the `ok &&` component is reinstated. At the same time, it's now apparent that the effective cookie expiration period was always one week prior to @jehiah's changes, thanks to the timestamp in validateCookie() being compared against the hardcoded value `time.Duration(24)*7*time.Hour*-1`. TestProcessCookieFailIfCookieExpired confirms that @jehiah's changes solves this problem as well. I also took the liberty to add a comment to the timestamp comparison in validateCookie(), since it took effort to remind myself how it was supposed to work.
mbland
pushed a commit
to cloud-gov/oauth2_proxy
that referenced
this pull request
Jun 23, 2015
Per bitly#115, @jehiah noted that he encountered a cookie refresh bug whereby an empty cookie value was being set when --cookie-refresh was enabled. I was able to ascertain by studying the code that if the original cookie has expired, the "refresh" case would still be triggered, causing an empty cookie to be set. TestProcessCookieFailIfRefreshSetAndCookieExpired reproduces the bug when the `ok &&` component of the `ok && p.CookieRefresh != time.Duration(0)` expression within ProcessCookie() is removed. The bug is confirmed fixed when the `ok &&` component is reinstated. At the same time, it's now apparent that the effective cookie expiration period was always one week prior to @jehiah's changes, thanks to the timestamp in validateCookie() being compared against the hardcoded value `time.Duration(24)*7*time.Hour*-1`. TestProcessCookieFailIfCookieExpired confirms that @jehiah's changes solves this problem as well. I also took the liberty to add a comment to the timestamp comparison in validateCookie(), since it took effort to remind myself how it was supposed to work.
* refresh now calculated as duration from cookie set
mbland
pushed a commit
to 18F/hub
that referenced
this pull request
Jun 23, 2015
The cookie_refresh switched from time until expiration to time since creation, which makes more sense. Also updated cookie_key to cookie_name.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I experienced a few issues with the current cookie refresh handling, that left me puzzled, but primarily i got a an empty cookie when a refresh should have happened.
This refactors that code a bit to fix that, and switches the timeframe for renewal to be since a cookie was set. (which i think is simpler to understand). Since the requirements (less than expiry) didn't change i think this is ok.
cc: @mbland