I have traefik config in my docker-compose file which routes traffic between several apps and I'd like to add a middleware to app-main to forward all www.hostname requests to hostname. I've added the following lines
- "traefik.http.middlewares.cutwww.redirectregex.regex=^https?://(?:www\\.)?(.+)"
- "traefik.http.middlewares.cutwww.redirectregex.replacement=https://$${1}"
- "traefik.http.middlewares.cutwww.redirectregex.permanenttrue"
nearby line 80 and enabled this middleware in line 83 with
- "traefik.http.routers.${APP_NAME}-main.middlewares=traefik-compress,cutwww"
After that, all my working routes to app-main have stopped to work (error 404). Please point me what's wrong in this config
Related
I'm attempting to run Apache in Docker, behind a Traefik reverse proxy for https. Everything works, except that when I access a folder URL without a trailing slash, Apache redirects me to non-https (i.e. https://www.example.com/folder -> http://www.example.com/folder/). This is caused Apache mod_dir DirectorySlash, as described here & here. The solution is to use a rewrite rule, which kicks in before DirectorySlash, like this:
# Redirect to HTTPS before Apache mod_dir DirectorySlash redirect to HTTP
RewriteCond %{HTTP:X-Forwarded-Proto} =https
RewriteCond %{LA-U:REQUEST_FILENAME} -d
RewriteRule ^/(.*[^/])$ https://%{HTTP_HOST}/$1/ [R=301,L,QSA]
However, the issue is Traefik seems not to be setting the X-Forwarded-* headers. Here's a screenshot of the headers I'm getting:
Here are the labels I'm using in my Apache docker-compose file:
labels:
- traefik.enable=true
- traefik.port=80
- traefik.frontend.rule=PathPrefix:/web #Apache is accessible under https://example.com/web/
I've tried various combinations of labels, but no matter what I do, the x-forwarded-* headers always seem to be missing. For example (ref, ref):
- "traefik.frontend.headers.SSLProxyHeaders=X-Forwarded-Proto:https"
- "traefik.frontend.headers.SSLRedirect=true"
I've even tried just getting Traefik to add my own custom headers and can't get those to show up (ref):
- "traefik.https.middlewares.testHeader.Headers.CustomRequestHeaders.X-Script-Name=test"
...However, just to convince myself that I'm not crazy & this is actually running behind Traefik, & Traefik can add headers that I can see, this does work & cause the X-Frame-Options header to appear in Firefox:
- traefik.frontend.headers.frameDeny=true
So in summary, the question is: why isn't Traefik setting the x-forwarded-* headers (which I can then use in my Apache RewriteRules) - and how can I get it to do so?
For anyone who finds this & is wondering, my issue was twofold:
1) X-Forwarded-* headers are not viewable in the browser. You can see them on the server with i.e. phpinfo(), or by dumping the $_SERVER variable:
2) The reason the redirects weren't working (to fix the DirectorySlash issue) is because in addition to the RewriteRules listed above, your htaccess must include RewriteOptions AllowNoSlash. From the Apache documentation:
By default, mod_rewrite will ignore URLs that map to a directory on disk but lack a trailing slash, in the expectation that the mod_dir module will issue the client with a redirect to the canonical URL with a trailing slash. [...] the AllowNoSlash option can be enabled to ensure that rewrite rules are no longer ignored. This option makes it possible to apply rewrite rules within .htaccess files that match the directory without a trailing slash, if so desired.
Have you tried
traefik.frontend.passHostHeader: true
If it's possible, I'd recommend to let the http to https redirection to be sorted by traefik:
[entryPoints]
[entryPoints.http]
address = ":80"
[entryPoints.http.redirect]
entryPoint = "https"
[entryPoints.https]
address = ":443"
[entryPoints.https.tls]
I would like to redirect invalid URL to a 404 error with traefik and Docker
Example :
https://sub1.domain.com is a valid doamin referenced in traefik, so nothing happen
https://invalid.domain.com doesn't exist in Traefik configuration, so it will redirect to https://error.domain.com
I have searched in the official documentation and the only thing I found was about redirection , but I don't know how to use them to do my purpose.
You should be able to do this by specifying a redirect and a replacement. You'll also need to make sure that the Host rule matches any subdomains. Here's a config for docker-compose:
services:
traefik:
# ...existing config
sub1:
# ...existing config
error:
# ...existing config
labels:
# Match all subdomains
- traefik.frontend.rule=HostRegexp:{subdomain:[a-z]+}.domain.com
- traefik.frontend.redirect.regex=^https?://(.*).domain.com
- traefik.frontend.redirect.replacement=https://error.domain.com
# Set priority to low number so matches after other rules
- traefik.frontend.priority=1
It's even easier if you don't mind about the domain changing but instead just want to show an error as you don't need the traefik.frontend.redirect labels
I am working on a Ruby on Rails application and it is deployed on AWS Beanstalk. My Beanstalk application has two environments:
- Web Env
- config:
- Ruby 2.4.3
- Rails 5.1.4
- Puma as App server
- Nginx as Web Server
- Uses active_elastic_job
- Worker Env
- config:
- Ruby 2.4.3
- Rails 5.1.4
- Puma as App server
- Nginx as Web server
- Uses Amazon - SQS
- Uses active_elastic_job
Both Envs uses the same repo/codebase and my app was fully configured.
Last week, I came to know that my application is not force redirecting to https. Though, I was able to access my site with https but when accessed via http or accessing directly via the domain name was not redirecting me to secure site.
I came across with this link https://gist.github.com/petelacey/e35c98f9a35063a89fa9 and after deploying this file using .ebextensions on Web Env, I am now able to redirect to https --- Till here no problem
But, when I tried deploying the same Running version to my Worker Env, my background jobs have stopped working
To troubleshoot that, I ssh into my Worker env and inspected below files:
/var/log/nginx/error.log -- Nothing suspicious found
/var/log/puma/puma.log -- Nothing suspicious found
/var/log/aws-sqsd/default.log -- I see lots of http-err
/var/log/amazon/ssm/errors.log
2018-05-08 11:28:19 ERROR [HandleAwsError # awserr.go.48] [instanceID=i-YYYYYYYYYY] [MessagingDeliveryService] [Association] error when calling AWS APIs. error details - AccessDeniedException: User: arn:aws:sts::XXXXXXXXXX:assumed-role/role/i-YYYYYYYYYY is not authorized to perform: ssm:ListInstanceAssociations on resource: arn:aws:ec2:us-east-1:XXXXXXXXXX:instance/i-YYYYYYYYYY
status code: 400, request id: ''
2018-05-08 11:28:19 ERROR [HandleAwsError # awserr.go.48] [instanceID=i-YYYYYYYYYY] [MessagingDeliveryService] [Association] error when calling AWS APIs. error details - AccessDeniedException: User: arn:aws:sts::XXXXXXXXXX:assumed-role/aws-elasticbeanstalk-ec2-role/i-YYYYYYYYYY is not authorized to perform: ssm:ListAssociations on resource: arn:aws:ssm:us-east-1:XXXXXXXXXX:*
status code: 400, request id: ''
2018-05-08 11:28:19 ERROR [ProcessAssociation # processor.go.157] [instanceID=i-YYYYYYYYYY] [MessagingDeliveryService] [Association] Unable to load instance associations, unable to retrieve associations unable to retrieve associations AccessDeniedException: User: arn:aws:sts::XXXXXXXXXX:assumed-role/aws-elasticbeanstalk-ec2-role/i-YYYYYYYYYY is not authorized to perform: ssm:ListAssociations on resource: arn:aws:ssm:us-east-1:XXXXXXXXXX:*
status code: 400, request id: ''
Before rolling this nginx proxy file, everything was working fine. I am not sure what I did wrong?
Two things I am trying immediately:
Override /etc/nginx/conf.d/proxy.conf on my worker env manually with the old proxy.conf file I have.
Restart nginx to see if job/s are back to normal
But few points I would like to point here:
Both the ENVs are not supposed to use the same Running version?
If my above approach works, that means I will have 2 different proxy files on different ENV. In future, if I deploy to my worker ENV, it will override the custom one. Can this be skipped?
Thanks for the help in advance!
I got the solution for this. My friend told me to handle this in below way:
STEP:1 inside config/environments/production.rb
change config.force_ssl = true to config.force_ssl = 'web'.eql?(ENV.fetch('EB_ENV', 'web'))
STEP:2 Define EB_ENVenvironment variable as web for Web ENV or worker/whatever you like for Worker ENV
Thanks friend! Much appreciated.
I have a Rails 4 application with nginx 1.4.4 and I'm having issues trying to access JSON routes.
I'm trying to access the following route:
http://www.example.com/products/106.json
Which produces a 404 / Not found in my nginx server. However, in my development server it works correctly (a Thin server), it displays the product as JSON.
I have already added the application/json json; line to the mime.types config file.
What else should I look in order to fix this? I can provide more information if needed. Thanks.
We're using Passenger 4.0.59 behind Apache 2.2 (CentOS 6.latest) with Rails 3.2.
In /etc/httpd/conf/httpd.conf we have:
TraceEnable off
We have one virtual host configured in httpd.conf and a second virtual host configured in /etc/httpd/conf.d/ssl.conf that's configured with Passenger.
I'm using commands of this form to test:
curl -I -X {method} https://{host}/{resource}
...and seeing the following behavior:
When I TRACE a static image over http, i.e. http://host.domain.com/images/foo.png, I get a 405 response (as expected).
When I TRACE the same static image over https, meaning it goes through the virtual host configured with Passenger, I get 405 (as expected).
However, when I TRACE a Rails service in our app, e.g. https://host.domain.com/status.json, I get a 200 response w/ valid data.
I would expect Apache to shut down the request and return a 405 response before it even gets to Passenger/Rails, but that isn't happening.
What am I missing / misunderstanding?
What am I missing / misunderstanding?
TraceEnable off is the correct directive to use, but you may have another TraceEnable directive elsewhere in your configs.
You should check all of your apache config files to be sure there is no other TraceEnable directives.
Since the TraceEnable directive can be used within either the server config or the virtual host config, so you may just want to add it to both.