NGINX automatically redirects subdomain to domain - nginx

So I know this seems like a question many people have asked before but I wasn't able to find an answer yet so I'll ask anyway.
I have a few websites set up on one IP address, which means I need to use SNI - one of said subdomains is mail.domain.tld, which works perfectly fine and another is cloud.domain.tld, which unfortunately doesn't.
cloud.domain.tld redirects to www.domain.tld when it is up.
manually typing 'cloud.domain.tld/login' works even when other websites are up but I haven't been able to make the subdomain append /login automatically, which is what I want to do.
when I change the name of cloud.domain.tld to mail.domain.tld, leaving the entire config the same, it works.
when I added clou.domain.tld and clouds.domain.tld to my DNS settings and set the website to those it works too.

So I changed the location / block from
rewrite ^ /index.php$uri; - as default in owncloud configuration
to
return 301 /index.php$uri;
and now this problem has been resolved, however logging out now returns a CSRF error.

Related

How to create a HTTPS->HTTPS subdirectory redirect using subdomains?

I am currently having issues with setting up an HTTPS domain redirect. I have a DNS URL redirect entry that points a few sub-domains to same-server URLs. For example:
docs.kipper-lang.org -> kipper-lang.org/docs/
play.kipper-lang.org -> kipper-lang.org/playground
The issue I am currently experiencing is that when using the subdomains, it mostly works, but it can only use HTTP. If I attempt to use HTTPS (like for example https://docs.kipper-lang.org) the redirect won't work and will get stuck apparently waiting for the HTTPS certificate (I think, but I don't know for sure, since it loads forever and gets a time-out).
So my DNS provider does its job for the most part as I want, but I am not sure how to add the HTTPS encryption to these redirects. Is there maybe even some DNS configuration or even middle-man service for redirects I can use, where these HTTPS encryptions are built-In? Since receiving a "Warning: Insecure connection" every time someone uses the sub-domains is a massive problem for me.
Note though that considering I am hosting on a GitHub Pages server, I am unable to do these redirects on the server side myself, as I can't use any code in this case.
I would greatly appreciate any ideas for fixing this or what I could use to achieve this another way.
Thanks in advance!

Host WordPress on path on Cloudflare

My domain is managed by Cloudflare, and I want example.com/he/whatevs to point to an IP where WP is hosted, eg 11.2222.12.12/whatevs
For that I have example.com pointing to a worker script that redirects /he to the aforementioned IP.
For this to work on WP end, I changed to DB record of the root URL to example.com/he, since this is the "user facing" URL.
The problem is, when I try to login to WP, there's a redirect mechanism in there that seems to be built-in to WP, and that causes an infinite redirect loop that eventually errors out.
Any ideas how to walk around that?
Or maybe my entire approach is off?
The problem was with cloudflare's default SSL setting, which is "flexible".
Once I changed it to "full strict" it started working.

How to solve multiple landing page redirect in Wordpress at once?

I have a Wordpress website and want to have in form of https://website.com. When I test it on GTmertix in form of http://www.website.com, I receive multiple landing page redirects like this:
Avoid landing page redirects for the following chain of redirected URLs.
http://www.website.com/
http://website.com/
https://website.com/
I have set the base domain on https://website.com format in Wordpress, and also I have done many things on .htaccess file to redirect http to https, but could not solve this issue.
May you help me please?
Without the domain, it is difficult to diagnose (and even then it may be difficult without seeing your .htaccess). Something is obviously redirecting http://www.example.com to http://example.com rather than directly to HTTPS.
You could try looking further up the chain, such as at your domain registrar/DNS provider. If you are behind a proxy like Cloudflare, I'd also be curious if this happens when you add the instance's IP address in your hosts file and try connecting directly - that would at least determine if the issue exists on the host itself or further up the chain.

DNS custom domain to subfolder

I have a SaaS app where every user has a personal subdomain: username.domain.com. Every user has a personal blog at username.domain.com/blog.
Now I want to accept custom domains, e.g. www.mycustomblog.com would be an alias for username.domain.com/blog.
If someone browses to www.mycustomblog.com/123, the page username.domain.com/blog/123 should be served.
However, I do NOT want a redirect. The user should still see www.mycustomblog.com/123in their address bar.
How can I achieve this behaviour? I have looked into Nginx reverse proxies, DNS CNAME records... but nothing seems to suit my needs. I can access both the custom domain DNS settings and all of the server's config files.
I think what you're looking for is a rewrite. However your described logic doesn't work:
www.mycustomblog.com -> username.domain.com/blog
appears to be missing a piece of identifying information on the left side. Perhaps www.mycustomblog.com/username? After that, it's just a matter of writing out the match/map statements to change the request to match what you've got on the server.

IIS app pool caches wrong url

I have my production site's app pool to recycle every 2 hours or so. I noticed that when the first call to the site is made, the App Pool caches the base url (e.g. www.mysite.com). This makes sense as this is used to resolve relative paths in ASP.NET e.g. ~/MyFolder/MyPage.aspx, which is resolved to:
http://www.mysite.com/MyFolder/MyPage.aspx
However since the site can be reached via our host name e.g.
http://masdfg.my.provider.net
IIS thinks the url is
http://masdfg.my.provider.net/MyFolder/MyPage.aspx
As you can image, this causing an issue with SSL as well as others. How can I prevent this from happening?
UPDATE: The work around was to create a url redirect. If anyone knows how to prevent this let me know.
I hope I've understood your question correctly, but please do let me know if I haven't.
It sounds like the sole issue you have is that when you write the links to the response they sometimes reference the wrong root URL.
I notice that you use ~/ . This would resolve and write the entire URL to the response I think. It is better to use only / when writing links to the response.
So in your example you would write /myfolder/mypage.aspx. The browser would then resolve the / to mean that it's from the root address of the site, whichever that may be.
Like I said, I hope I've understood your question correctly and apologies if I haven't.
I know it's a long shot, but I've had a similar problem with my IIS setup. I solved it by going to the already mentioned "bindings" window through "Edit Bindings".
Then I removed all the not wanted bindings, then adding the hostname www.mydomain.com the server should answer to.
Finally I edited the windows hosts file at
%windir%\System32\drivers\etc\hosts
Adding the line
127.0.0.1 www.mydomain.com
This ensures that www.mydomain.com always resolves to the local computer.
After executing iisreset.exe as administrator my problem was over.
HttpContext.Current.Request.Url is not a cacheable item. That value comes from the HOST value of the HTTP headers. Which means it is passed in to the application from the request.
The only time it should take that second URL is if the requests HOST value was masdfg.my.provider.net
There are three possible fixes here. The first is to set your bindings and have any requests to masdfg.my.provider.net be forwarded over to www.mysite.com
The second, because your primary issue appears to be about SSL is to get a unified communications (UC) SSL certificate and install that on your server. This would be to cover the mysite.com and masdfg.my.provider.net domain names.
The third is to simply create a separate IIS site which points to the exact same production directory as the first one. Each site would have only 1 domain name it's responsible for.

Resources