Closed zohiba closed 5 months ago
Issues go stale after 90d of inactivity.
Mark the issue as fresh by commenting /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen
.
If this issue is safe to close now please do so with /close
.
/lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh by commenting /remove-lifecycle rotten
.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen
.
If this issue is safe to close now please do so with /close
.
/lifecycle rotten /remove-lifecycle stale
Rotten issues close after 30d of inactivity.
Reopen the issue by commenting /reopen
.
Mark the issue as fresh by commenting /remove-lifecycle rotten
.
Exclude this issue from closing again by commenting /lifecycle frozen
.
/close
@openshift-bot: Closing this issue.
@openshift-bot /reopen
@stlaz @jianzhangbjz Do either of you know if this project is still being maintained? We are using this product and this is considered a security flaw.
/reopen
@amandalal: You can't reopen an issue/PR unless you authored it or you are a collaborator.
/reopen
/remove-lifecycle rotten
/reopen
@zohiba: Reopened this issue.
@zohiba: Reopened this issue.
@stlaz @jianzhangbjz Do either of you know if this project is still being maintained? We are using this product and this is considered a security flaw.
The cookie is bound to the site of use with the Domain
attribute, is HTTPOnly
and Secure
. Therefore the cookie is only ever visible to the oauth-proxy and the application behind it, which I don't think should be problematic.
Issues go stale after 90d of inactivity.
Mark the issue as fresh by commenting /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen
.
If this issue is safe to close now please do so with /close
.
/lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh by commenting /remove-lifecycle rotten
.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen
.
If this issue is safe to close now please do so with /close
.
/lifecycle rotten /remove-lifecycle stale
Rotten issues close after 30d of inactivity.
Reopen the issue by commenting /reopen
.
Mark the issue as fresh by commenting /remove-lifecycle rotten
.
Exclude this issue from closing again by commenting /lifecycle frozen
.
/close
@openshift-bot: Closing this issue.
Currently the _oauth_proxy cookie stores username information that is base64 encoded which is easy to decrypt. This is a security hole, can we encrypt it somewhere before it is assigned as the cookie value? How to encrypt the username before it is assigned as the cookie value?
Edit: I have tried using the --cookie-secret flag like
--cookie-secret=8_3IDOJAfTYz3plnjmD5pAbLr9BiJv81L-fuMoEynro=
but the cookie is not getting encrypted, it is still in base64 form. I have the following version that supports the flag but it is still not working.