-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Adds support for root context redirection #427
Conversation
@aledbf Don't know why CI failed, as those were simple changes. Can you help me in this to check if this is a real failure? Thanks! |
Tks :D |
examples/rewrite/README.md
Outdated
@@ -1,3 +1,28 @@ | |||
# Sticky Session | |||
|
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.
This should be Rewrite
?
@rikatz Sound good. Btw the Awaiting this PR merged to add this feature to HAProxy Ingress as well =) Thanks! |
@rikatz just one change, plese move |
OK, made it as asked. |
@aledbf Travis / Coveralls seems to be broken :( My last commit only moved the Example as you requested, but the CI broke :( |
/lgtm |
@rikatz thanks! |
@@ -236,7 +236,19 @@ http { | |||
ssl_verify_client on; | |||
ssl_verify_depth {{ $location.CertificateAuth.ValidationDepth }}; | |||
{{ end }} | |||
|
|||
{{ if (or $location.Redirect.ForceSSLRedirect (and (not (empty $server.SSLCertificate)) $location.Redirect.SSLRedirect)) }} |
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.
@aledbf this seems broken. I think it should be moved back into the location {{path}}
block.
What happens if we have one location with ssl-redirect: "false" and one with ssl-redirect: "true" - won't they now both be redirected?
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.
@rikatz please check ^^
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.
@aledbf I've only changed the piece of code from it's location. The idea is first make it's HTTPs redirection based on the configs (as defined previous in lines 282:287 and then moved to this new location) and then redirect (if it exists) to the root context.
One doesn't exclude other, this code existed previously. It only orders which rules will be followed first :)
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.
By the way, acording to NGINX docs, the IF and redirects can happen inside a location, a if and a server directive. The usage of this directive inside the 'location' limits the redirection only for the current location (maybe only the '/' path), not containing the other paths that might exist.
I'm on vacation (and traveling) right now, but will take a look again in this behaviour ASAP.
@jasonbrownbridge How have you detected this? Can you please reproduce the taken steps, so I can try here and take a look.
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.
@rikatz I was thinking something like this (substituting in appropriate ssl-wildcard secret):
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: default-route
annotations:
kubernetes.io/ingress.class: "nginx"
kubernetes.io/ssl-redirect: "true"
spec:
tls:
- hosts:
- "*.example.com"
secretName: "ssl-wildcard"
rules:
- host: "www.example.com"
http:
paths:
- path: /
backend:
serviceName: route-default
servicePort: 80
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: check-route
annotations:
kubernetes.io/ingress.class: "nginx"
ingress.kubernetes.io/ssl-redirect: "false"
spec:
rules:
- host: "www.example.com"
http:
paths:
- path: /check
backend:
serviceName: route-check
servicePort: 80
My thought is this should create something like:
server {
server_name www.example.com;
...
location / {
if ($pass_access_scheme = http) {
return 301 https://$host$request_uri;
}
...
}
location /check {
...
}
Instead this code would generate (which always does ssl redirect):
server {
server_name www.example.com;
...
if ($pass_access_scheme = http) {
return 301 https://$host$request_uri;
}
location / {
...
}
location /check {
...
}
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.
@rikatz will try do a more concrete test case tomorrow (UTC+2 here)
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.
Also @rikatz I'm not blocked here (I use a custom template anyway) - so enjoy your vacation :)
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.
@jasonbrownbridge We all do :P I've removed all the passthrough stuff, as I use only HTTP/s traffic.
Anyway, I think the idea is to always redirect the SSL, as this is a global annotation, isn't it?
This '/check', by the otherside could be inside the same Ingress Object (of the vhost that contains the TLS config). I suppose that Ingress Controller assumes the first created ingress and discards the conflicting one. (you have two ingress objects pointing to the same host, in this case www.example.com)
Also, by the previous template (before this commit), the HTTPs redirection would be inserted anyway in all existing 'path' rules :)
But let me know about your tests!
@aledbf Am I right with this conclusion?
Do you know when this will be in a beta? |
This is needed to avoid ingress definitions with different settings for SSL redirection conflicting with each other. NB: This was discussed in the review of kubernetes#427, but ultimately not addressed.
This PR adds support for Root Context Redirection.
This is necessary for some Apps (as Java Apps) that aren't created containing a root context, but instead answers only its context.
An example, a Java App that exposes itself as '/app1'. When you create an Ingress, you need to redirect the call to 'app1.ingress.com/' to 'app1.ingress.com/app1'.
TODO:
After I finish documentating this, the PR is ready.
@jcmoraisjr Please take a look to see if this is applicable to our case.