I have an open shift account and I created an application a little while ago for which I didn't add a domain. Now i am trying to add the domain its not working correctly.
The domain is www.quantumfreedom.com. There is a CNAME in place for both www and * pointing to the application on openshift. I have submitted a ticket on GoDaddy and with my other domain provider and they both say it's a hosting issue and not a domain or DNS issue.
The full message reads as follows:
The page isn’t redirecting properly
Firefox has detected that the server is redirecting the request for
this address in a way that will never complete.
This problem can sometimes be caused by disabling or refusing to accept
cookies.
This is not the only domain I have an issue with before with open shift.
Current CNAME record for www.quantumfreedom.com looks like this:
;QUESTION
www.quantumfreedom.com. IN CNAME
;ANSWER
www.quantumfreedom.com. 3548 IN CNAME vitscript-james1vince.rhcloud.com.
If http://vitscript-james1vince.rhcloud.com is the site you want to show to the users who type http://www.quantumfreedom.com in their address bar, then as far as DNS is concerned, there is nothing more you can or should do, users will be directed to the correct IP address.
Now you need to make sure that once the request for www.quantumfreedom.com arrives at your http server, the server responds with correct content. At the moment that is not the case, if you try from command line:
curl -v http://www.quantumfreedom.com/
Notice these two lines in response:
< HTTP/1.1 301 Moved Permanently
< Location: http://www.quantumfreedom.com/
This means that webserver is redirecting the client back to the same url, causing an infinite loop, resulting in browser error:
ERR_TOO_MANY_REDIRECTS
(or similar, depending on the browser)
This redirect can com from either webserver settings (Apache .conf or .htaccess files) or even application itself, so those would be the places to look next.
Related
I am trying to point the domain www.xxx.com to www.ttio.com/tc using cloudflare to enable to the https on the site.
On GoDaddy I have changed the nameservers to cloudflare's recommended name servers
I have also gone to "Page rules" on Cloudflare and added a forwarding rule so that the above is in place.
On going to www.xxx.com however, i get the following error:
It redirects to this url: https://shortener.secureserver.net/error_404
and the error is:
Destination
Unknown
Everything's working on our side, so the link you clicked is either wrong or has been retired.
I have done everything I think I should have, so could anyone shed any light on this please?
You can't point a domain (e.g. www.xxx.com) at an URL (e.g. www.ttio.com/tc). A domain needs to be converted to an IP address by the browser.
If the web server for www.ttio.com is set to recognise www.xxx.com and serve the content from the /tc folder under www.ttio.com, just set up a CNAME for www.xxx.com pointing www.ttio.com and it will work.
If the web server for www.ttio.com doesn't know about www.xxx.com at all, you'll need to use a translation proxy. One way of doing that is using a Cloudflare worker to map the www.xxx.com/PATH URL to www.ttio.com/tc/PATH. An example of how to do this is at https://developers.cloudflare.com/workers/tutorials/configure-your-cdn/. You may also need to rewrite the HTML so that links in the pages don't point to www.ttio.com/tc. An example of how to do that is at https://developers.cloudflare.com/workers/reference/apis/html-rewriter/.
We have a site that we are trying to configure as a client in a SSO scenario, using WS Federation and SAML.
Our site sits behind a load balancer that is doing SSL offloading - the connection to the balancer is under https, but decrypted and forwarded (internally) to the actual site under http and port 81.
Somewhere the WS federation module is attempting to redirect us, but is building up the URL based on the port and incoming protocol to the website:
We request:
https://www.contoso.com/application
and are getting redirected to:
http://www.contoso.com:81/Application
Which doesn't work as the load balancer (correctly) won't respond on this port.
And it seems to be related to the casing of the virtual directory. Browsing to
https://www.contoso.com/Application
seems to work without issue.
(Note for completeness, attempting to browse to http://www.contoso.com/Application with no port will correctly redirect us to the SSL secured URL).
I am trying to find out:
a) Where this redirect is happening in the pipeline and
b) How to configure it to use the correct external address.
If anybody is able to point me in the right direction, I would very much appreciate it.
EDIT 14:19: Seems to be either the WsFederationAuthenticationModule or the SessionAuthenticationModule. These do a case sensitive comparison of the incoming url to what it expects and redirects otherwise:
https://brockallen.com/2013/02/08/beware-wif-session-authentication-module-sam-redirects-and-webapi-services-in-the-same-application/
So that seems to be happening, its a matter now of trying to get the site to behave nicely and redirect to the correct external url.
The following seems to be related and ultimately points to the culprit in the default CookieHandler:
Windows Identity Foundation and Port Forwarding
Looking at that code decompiled in VS, it compares HttpContext.Current.Request.Url against the targetUrl and will redirect to the expected 'cased' version otherwise (in our case including the errant port number).
It would seem that explicitly setting the path attribute of the cookie fixes this issue. Either an empty string or the virtual directory name seems to work:
<federationConfiguration>
<cookieHandler requireSsl="true" name="ContosoAuth" path="/Application/"/>
<wsFederation passiveRedirectEnabled="true" issuer="https://adfsSite" realm="https://www.contoso.com/Application/" reply="https://www.contoso.com/Application/Home" requireHttps="true"/>
</federationConfiguration>
I recently redid a client's old Drupal site, in Apostrophe, and pointed their domain to the new server.
I am now trying to access the old site via IP address, but there seems to be a redirect configured to rewrite the base IP address to the domain name (72.xx.xxx.xxx to www.clientdomain.com).
Is there something configured in Drupal to rewrite the IP address? Can I change a field in the database or configuration files to prevent this?
I have ssh access to the server, and have poured over the Drupal code, settings.php, .htaccess, etc., but cannot locate this offending field. I am not familiar with Drupal, but suspect it could be an admin setting. Since the site redirects, I am unable to login to the admin backend.
Any and all insight is appreciated. Thanks for your help!
A few possibilities:
In the settings.php (sites/default/settings.php), see if there is a $base_url set. If you can see any, comment that line. You can run a drupal site without the base_url hardcoded in the settings.php
In the .htaccess look for redirects. Your safest bet is to replace it with a fresh file downloaded from http://drupal.org/project/drupal
The most likely case is that your web server is configured to redirect the IP address to the main domain.
You can also access your site at old server by explicitly setting the IP address in your hosts file. Check it for your operating system DNS resolver docs.
i recently migrated my application to AWS and setup a cname for www.domain.com and a redirect for the domain.com to redirect to www.domain.com.
The problem is, an external service was using a path on the naked domain.com (something like domain.com/external/service/) But with the redirect all HTTP POST data is being dropped with the redirect and i cant change the url that the external service is calling.
To fix this, i have setup my naked domain on route53 to point to my elastic load balancer where my app is located. I set up an A record pointed at my elastic load balancer using an alias.
Its been two days now and my naked domain still redirects to www. and therefore the external service is down. Any ideas on what i could do?
I am taking a long shot - there are different possible problems:
You are forwarding naked domain via A record to ELB, but your EC2 instace (say Apache) is still doing a redirect (not DNS, but http 301) back to www.
Check the DNS TTL. If the TTL is too large (say 48 hrs), then it takes that time. You need to wait longer.
Is Route53 fully managing your DNS? One possibility is that, somebody else like Godaddy is still doing the DNS for you - so nobody is contacting Route53 for the change to reflect.
To replace a legacy web site, a client has pointed their DNS at my server where a new version of the website exists.
However they still serve http://support.example.com from their own server.
I have noticed that non-www requests, e.g. http://example.com still point to their own server, therefore show the old web site.
How can I point non-www requests, http://example.com at my server without breaking the functionality of their 'support' sub-domain?
The client's server is a Microsoft server, mine is Linux/Apache
Edit: Changing the DNS 'A' record will not break the existing sub-domain
I know I could add an index.html page to the front of the old site, but if it was ever deleted the page requests would cease to work
I can't use mod-rewrite because I don't have access to their web server files
PROPOSED SOLUTION:
On the client DNS, create an A
record for:
support.example.com – IP of the client's server
example.com – IP of my server
www.example.com - IP of my server
No need for any DNS changes on my server regarding this domain
Changing the A record for example.com won't affect the A record for support.example.com.