Open ryancurrah opened 6 months ago
Follow-up to this Slack thread
- The
secure
variable is set to false becauseopts.TLSConfig
is nil, indicating that Argo Server is not terminating TLS. Instead, a reverse proxy is used to terminate TLS. So https://github.com/argoproj/argo-workflows/blob/v3.5.5/server/auth/sso/sso.go#L345-L348 ends up beinghttp
when infact we are usinghttps
.
We could potentially use the request's protocol to determine this.
But secure: false
has other implications, like the Cookie setting and potentially others that we should be careful around and ensure properly handle ingress TLS termination.
EDIT: Here's another redirect line that depends on it that should be changed too.
Thanks for opening this ticket from my slack help request! subscribing for updates...
Workaround is to use a self-signed cert on the Server with secure: true
, per the Slack thread
+1
Pre-requisites
:latest
image tag (i.e.quay.io/argoproj/workflow-controller:latest
) and can confirm the issue still exists on:latest
. If not, I have explained why, in detail, in my description below.What happened/what did you expect to happen?
Description:
When clicking an Argo Workflows link, if I'm not logged in, I'm redirected to the login page. After logging in, I'm redirected to the workflows page instead of the original page I was trying to access.
Steps to reproduce:
Debugging information:
strings.HasPrefix(cookie.Value, prefix)
always evaluates to false due to a mismatch between the HTTP and HTTPS schemes.secure
variable is set to false becauseopts.TLSConfig
is nil, indicating that Argo Server is not terminating TLS. Instead, a reverse proxy is used to terminate TLS. So https://github.com/argoproj/argo-workflows/blob/v3.5.5/server/auth/sso/sso.go#L345-L348 ends up beinghttp
when infact we are usinghttps
.Expected behavior:
After logging in, the user should be redirected to the original project they were trying to access, not the last viewed project.
Version: Argo Workflows v3.5.5
Version
v3.5.5
Paste a small workflow that reproduces the issue. We must be able to run the workflow; don't enter a workflows that uses private images.
Logs from the workflow controller
Logs from in your workflow's wait container