I am using Ghost Version 4+.
I created a custom admin link by customizing my config.production and now I am successfully redirected to my subdomain admin.mysite.com, but the problem is that everything is working fine but it refuses to connect in editing sections. I have attached a screenshot for reference.
Reference image to the error being shown
It's basically a frame showing "refused to connect" earlier which was working fine and showing a preview of all functions of the site in real time.
This was working fine on my main link - mysite.com/ghost but refuses to connect since I changed my config to a new link admin.mysite.com
This is my config file ->
{
"url": "https:/mysite.com",
"admin": {
"url": "https://admin.mysite.com/"
},
"server": {
"port": 2369,
"host": "127.0.0.1"
},
Important notes to consider :
When I open my subdomain(admin.mysite.com) it shows default Nginx page, so I used Cloudflare redirect to point it to admin.mysite.com/ghost which holds the admin area after changing my configuration above.
I have set my subdomain by an A record pointing to the IP address of my server. What I have not done is configuring Nginx. This is reference information hope anyone finds any solution to why I am facing this.
My assumption is that ghost is designed to connect everything at the default link which is mysite.com/ghost, the forum of ghost shows a way to do it Ghost Admin Security: Is there any way to redirect Admin-URL (Redirection Alternative)
I am not sure if I have to configure Nginx, DNS, or Config.
If you are using Nginx :
location / {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $http_host;
proxy_pass http://127.0.0.1:2369;
add_header X-Frame-Options "ALLOW-FROM URI";
}
Add this line
add_header X-Frame-Options "ALLOW-FROM URI";
If you are using Apache
Header always set X-Frame-Options "ALLOW-FROM URI"
For reference : X-Frame-Options Mozzila
Adding this header shall add a vulnerability of embedding a webpage within an Iframe despite being from the same origin.
Related
I am writing a backend for my Flutter app using Aqueduct. I have Aqueduct set up so that Nginx proxies requests to it like this:
server {
root /home/web/my_server/web;
index index.html index.htm;
server_name example.com www.example.com;
location / {
try_files $uri $uri/ =404;
}
location /api {
proxy_set_header X-Real-IP $remote_addr;
proxy_pass http://127.0.0.1:8888;
proxy_http_version 1.1;
}
...
}
In Aqueduct I serve the files using a FileController:
router.route("/api/v1/app/*")
.link(() => LogController(context))
.link(() => FileController("public/app/")
..setContentTypeForExtension('apk', ContentType('application', 'vnd.android.package-archive')));
However, any files that it returns don't include the Content-Length header. That means that I can't show download progress.
I tried creating a custom FileController where I added the headers in manually:
final contentLengthValue = file.lengthSync();
return Response.ok(byteStream,
headers: {HttpHeaders.lastModifiedHeader: lastModifiedDateStringValue,
HttpHeaders.contentLengthHeader: contentLengthValue,
'x-decompressed-content-length': contentLengthValue,
HttpHeaders.cacheControlHeader: 'no-transform',
HttpHeaders.acceptRangesHeader: 'bytes'})
..cachePolicy = _policyForFile(file)
..encodeBody = false
..contentType = contentType;
The Content-Length header was still removed, but the x-decompressed-content-length header remained so this is a possible workaround. It just doesn't play nicely with some Flutter plugins that look for the Content-Length header and don't have a convenient way to check other headers.
Is this an Aqueduct problem or an Nginx problem? How do I solve it?
This solution works, but it skirts around the original problem. That it, it allows you to serve files that have the Content-Length in the header, but it doesn't explain why it was getting stripped in Aqueduct. Other answers are welcome.
Rather than have Aqueduct serve files, just have Nginx serve them directly.
If you can't change your API route, you can just give it an alias in the Nginx config location block. Add this before the /api location block.
location /api/v1/app/ {
alias /home/web/my_server/public/app/;
}
Now files in the app/ folder will get served by Nginx rather than Aqueduct. Nginx includes the Content-Length header in the files it returns.
I have used Facebooks sharing debugger to highlight an issue on the website
URL requested a HTTP redirect, but it could not be followed.
https://developers.facebook.com/tools/debug/sharing/?q=https%3A%2F%2Fwww.badgerbookings.com
This is also stopping it accepting the url in the privacy policy when creating an app.
I have researched and made sure to add all OG meta tags. I also "reduced" down the redirects on my nginx to only support a http > https redirect which to me seems pretty standard.
It still produces the error on both the debugger and the Privacy Policy URL.
My Nginx config:
server_tokens off; #Enables or disables emitting nginx version on error pages and in the “Server” response header field
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
server {
listen 80;
server_name _;
return 301 https://www.badgerbookings.com$request_uri;
}
server {
server_name www.badgerbookings.com badgerbookings.com *.badgerbookings.com;
location / {
proxy_pass http://localhost:3000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade; # allow websockets
proxy_set_header Connection $connection_upgrade;
proxy_set_header X-Forwarded-For $remote_addr; # preserve client IP
proxy_set_header Host $http_host;
proxy_set_header X-Forward-Proto http;
proxy_set_header X-Nginx-Proxy true;
}
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/badgerbookings.com-0001/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/badgerbookings.com-0001/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
Go to Facebook Developer's policy page.
Scroll down to this bit:
Privacy Policy
a. Provide a publicly available and easily accessible privacy policy
that explains what data you are collecting and how you will use that
data.
Now run
curl https://badgerbookings.com/terms
Are you looking at an easily accessible privacy policy which is publicly available at that url?
You maybe having IPv6 issues which can be resolved as simple as adding a listen [::]:443 ssl directive in you SSL server block.
If that doesn't fix it, try redirecting with a matching if directive
if ($scheme != "https") {
return 301 https://www.badgerbookings.com$request_uri
}
This is best if you unite both server blocks in one, to avoid more code. Just delete the non-https one and insert port 80 listen directives on the other one as well, with that conditional redirect, this way your code will be even slimmer.
I've the below nginx conf file to redirect all the requests (by default) to /auth (of my service) and then get back a response header (foo_id). This header will be forwarded to the original request URI triggered by user. The below works properly with the nginx.
...
location /
{
auth_request /auth;
auth_request_set $foo_id $upstream_http_foo_id;
proxy_pass $request_uri
proxy_set_header X-foo-Token $foo_id;
root html;
index index.html index.htm;
}
location /auth
{
internal;
proxy_pass https://myhost/myservice;
proxy_pass_request_body off;
proxy_set_header Content-Length "";
proxy_set_header X-Original-URI $request_uri;
}
But I need the corresponding ingress rules/annotations that are required to achieve the above use case. I couldn't get the respective auth/proxy-pass related annotations. Kindly help out.
You can use Nginx Ingress Annotations to achieve this goal.
In nutshell:
Assuming, you have an external auth service, which has a Kubernetes service configured.
You need an annotation, which sends auth requests to this service:
nginx.ingress.kubernetes.io/auth-url: http://auth-service.<NameSpace>.svc.cluster.local/auth
Also, you can use nginx.ingress.kubernetes.io/auth-snippet annotation to set your custom configuration for the auth request e.g.
nginx.ingress.kubernetes.io/auth-snippet: |
auth_request_set $foo_id $upstream_http_foo_id;
proxy_pass $request_uri
proxy_set_header X-foo-Token $foo_id;
If you need to return some headers on successful auth, you can use nginx.ingress.kubernetes.io/auth-response-headers:
nginx.ingress.kubernetes.io/auth-response-headers: X-Auth
And, nginx.ingress.kubernetes.io/auth-signin to specify the custom error page
The compoments of the system are
(source: snag.gy)
:
"nginx server" - A
"3rd party server" - B
"User PC" (browser) - C
The server "A" and the user PC "C" are connected in the same network "Network A", but the server "A" and 3rd party machine "B" are connected in the network "Network B".
The goal is to access 3rd party machine "B" from the user browser "C" through the Server "A". In order to perform it, the server "A" should do reverse proxy of the 3rd party content.
Nginx server is installed and configured on the server "A". The rule for reverse proxy is:
location ~* ^/3rdparty/(.*)___(.*)___(.*)___(.*)$ {
proxy_pass https://$1.$2.$3.$4?$args;
proxy_redirect off;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
Using the rule we would like to do reverse proxy for URL:
http:///3rdparty/<3RD_PARTY_IP_URL> => https://<3RD_PARTY_IP_ADDRESS>
For example:
http:// 192.168.237.208/3rdparty/192___168___237___222 => https://192.168.237.222
Actually, we want everything appended to the URL to be redirected.
For example:
http://192.168.237.208/3rdparty/192___168___237___222/blah/blah => https://192.168.237.222/blah/blah
That configuration works for us for some another setup, but the problem in this case is: on 3rd party machine "B", there is another web server which does some redirections:
https://192.168.237.222 => https://192.168.237.222/users/sign_in
So, the final result when we put the desired URI in the browser is:
http://192.168.237.208/3rdparty/192___168___237___222
the webserver on "B" takes host name of the URL and appends the redirection rule (users/sign_in), which results that browser is requesting the following URL:
https://192.168.237.208/users/sign_in
which is not available on Server "A" (actually it is on "B") => we got http error code 302 (moved temporarelly).
Are there any missing configuration rules we didn't apply? Or any other http request header parameters should be updated/forwarded?
The backend connection to 192.168.237.222 is transparent to the client which is only connected to 192.168.237.208
When server B (backend) sends back a /users/sign_in redirection, it is reversely propagated to the client, which applies it against the server he is connected to, ie server A (gateway/proxy), resulting in the erroneous request of /users/sign_in on 192.168.237.208.
You need to keep in mind redirections are propagated back to and processed by the client, not the gateway/proxy.
I would do something like the following:
location ~* ^/3rdparty/([0-9]{1-3})___([0-9]{1-3})___([0-9]{1-3})___([0-9]{1-3})(/.*)?$ {
proxy_pass https://$1.$2.$3.$4$5$is_args$args;
proxy_redirect off;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
Details:
Modifying your regex to also match against requests with /blah/blah appended to the backend IP address and copy-pasting them at the end of the proxy_pass directive using another variable ($5)
Using $is_args nginx embedded variable instead of a question mark (avoiding to have it in a request if no args are to be passed to the backend)
Trying to refine the regex syntax to match IP address numbers (quick and dirty, the one I provide you with still leads to incorrect matches but is at least better than wildcards)
Now, you need to redirect clients on server B (192.168.237.222) to /3rdparty/192___168___237___222/users/sign_in which is a location that can be requested against server A (192.168.237.208, the only server clients are connected to) and happily forwarded to the right backend.
==========
You could also rely on the nginx proxy_redirect directive rather than setting it to off and make your backend server making redirection answers like https://192.168.237.221/users/sign_in. proxy_redirect would then allow you to rewrite those proxied answers to the right URI against 192.168.237.208.
To do so, try something like (watchout, I am still using the lazy IP address mask):
proxy_redirect ~*^https://([0-9]{3}).([0-9]{3}).([0-9]{3}).([0-9]{3})(/.*)?$ http://192.168.237.208/3rdparty/$1___$2___$3____$4$5;
I wonder if variables like $is_args and $args are working in this context:
proxy_redirect ~*^https://([0-9]{3}).([0-9]{3}).([0-9]{3}).([0-9]{3})(/.*)?$ http://192.168.237.208/3rdparty/$1___$2___$3____$4$5$is_args$args;
I currently have two enabled site configurations in nginx, let us call them old-site.example and new-site.example. There is no other site configuration active.
old-site.example should 301-redirect to new-site.example. This currently works well as long as the old-site.example configuration is alone. After adding the new-site.example configuration file, it does not redirect anymore.
oldsite.conf:
server {
listen 80;
server_name *.old-site.example;
rewrite_log on;
location / {
return 301 http://www.new-site.example$request_uri;
}
}
newsite.conf:
server {
listen 80;
server_name www.new-site.example;
charset utf-8;
location / {
#forward to application server
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://127.0.0.1:8080;
}
}
other configuration details:
JBoss AS7 as application server running behind Nginx 1.5.1
This was a DNS related error, sorry everyone.
Background: The ISP of the client managed to "smart redirect" the domain instead of using DNS. They basically scraped the new site on their servers and returned it via the old domain. I'm speechless.
If you ever have a problem like this, check DNS resolution before second-guessing your config.