Cognito Redirect URI defaults to HTTP

[sjhawkins01]

I'm working on setting up oidc authentication for shinyproxy through AWS Cognito, but as part of the handshake, the redirect uri gets formatted with http instead of https causing an error. I saw in the documentation that I need forward-headers-strategy: native in the server part of the yaml, but that still results in http being used in the redirect url. X-Forward-For and X-Forward-Proto both appear in the request logs, but X-Forward-Proto is still set to http. I saw several other people had the same/similar issue, but it doesn't look like there is a solution on those threads.

I have an application load balancer (not a NLB) in front of the ec2 running shinyproxy to handle the https encryption since my ec2 is running on a private network. Is that part of the problem? And if so, how would I get around this? Any help is much appreciated!

[LEDfan]

Hi

It seems your setup is correct, except that you mention X-Forward-Proto has the value http. ShinyProxy uses this value to know whether to start the generated url with http or https. We have used ALB before, and didn't experience this issue. Did you configure an ACM cert in ALB? It could also be worth to check whether ALB enforces a redirect to HTTPS.

[sjhawkins01]

Thank you so much for the quick reply! I do have an ACM cert in the ALB and I think the HTTPS redirect is fine. If I go back to simple authentication, the app gets served up on HTTPS just fine. I also have a traefik dashboard that is reachable over HTTPS too.

I am running shinyproxy with docker swarm for scaling, so I am using a little bit older version of the shinyproxy image since it looks like the latest image doesn't work well with docker swarm. Could that be part of the problem? If I change images to the latest shinyproxy version, the container fails to start and I get the exception "Backend is not a Docker Swarm" in the logs. Thank you again for the help!

[yangwu1227]

@LEDfan We're also facing the exact same redirect issue while setting up oidc. We've set both forward-headers-strategy: native in application.yml and proxy_set_header X-Forwarded-Proto $scheme; in the Nginx config.

Do you have any recommendations for further isolating the issue? I'm pretty convinced it's likely a misconfiguration on our end as it seems that others have resolved the redirect issue based on #114.

[sjhawkins01]

@YangWu1227 I use traefik as the revers proxy, so not sure if there is something applicable for Nginx, but I had to manually tell traefik which IP addresses to trust. When I added entrypoints.http.forwardedHeaders.trustedIPs={List IPs that could come from my subnets} to the command part of my traefik config file, the forward headers were correct. Hope this helps!

[yangwu1227]

@YangWu1227 I use traefik as the revers proxy, so not sure if there is something applicable for Nginx, but I had to manually tell traefik which IP addresses to trust. When I added entrypoints.http.forwardedHeaders.trustedIPs={List IPs that could come from my subnets} to the command part of my traefik config file, the forward headers were correct. Hope this helps!

@sjhawkins01 Thanks so much for the suggestion—it really helped us out! After adding the trusted IPs from our VPC subnets to the Nginx config with set_real_ip_from, the forwarded headers started working perfectly. We also had to tweak the security rules for the Application Load Balancer to make sure traffic was allowed on the right ports, but once that was sorted, everything fell into place.

Honestly, I wish I could just focus on being a data scientist, but figuring out these kinds of issues is oddly satisfying once it’s all working! Thanks again for your help.

[sjhawkins01]

@YangWu1227 I'm so glad it worked! It definitely is satisfying when it all comes together!

[LEDfan]

Thank you both for sharing the solution! It's difficult for us to know the details of all these systems, so we really appreciate sharing the result. If this issue is now completely fixed, you can close the issue.