I am trying to point www.mydomain.example/blogs to www.anotherdomain.example/blog.html and still keep the URL the same, any ideas?
I have tried so many different methods and the URL changes to the URL im am redirecting to.
Thanks
Unless both domains are hosted on the same server and you have access via the file system, you will probably need a proxy on mydomain.example that forwards the requests to anotherdomain.example, fetched the response and forwards it back to the client.
Related
I have a site being hosted on heroku so I can go to myapp.herokuapp.com/ and my SPA loads. I got a domain and used cloudflare with a CName record to alais mydomain.com to myapp.herokuapp.com. Great the sites load. Within my SPA i load some images. If my app loads directly from heroku *myapp.herokuapp.com/images/filex.png" it works fine but if I call (or type in the address bar) myDomain.com/images/files.png" I just get my site back like i types mydomain.com
Is this an issue with cloudflare? Do i need additional routing rules?
or is this an issue with my express server that is serving the app and images? does the redirected
request look different and do I need to add code to handle the redirect?
I'm not sure why the redirect is happening without more information. My best guess is that you need to follow these instructions from Heroku. Without this, Heroku servers will have no idea what to do with a request that has a host header of mydomain.com, and will perform in some unexpected way. Heroku needs some way on its side to know that all mydomain.com requests should be handled identically to myapp.herokuapp.com requests.
If this configuration is already in place, your underlying code needs to handle myapp.herokuapp.com and mydomain.com, but I believe by default express will not care about hostname.
Seems to have been an issue with heroku. It’s working fine on aws.
I have a website (userbob.com) that normally serves all pages as https. However, I am trying to have one subdirectory (userbob.com/tools/) always serve content as http. Currently, it seems like Chrome's HSTS feature (which I don't understand how it works) is forcing my site's pages to load over https. I can go to chrome://net-internals/#hsts and delete my domain from Chrome's HSTS set, and the next query will work as I want without redirecting to an https version. However, if I try to load the page a second time, it ends up redirecting again. The only way I can get it to work is if I go to chrome://net-internals/#hsts and delete my domain from Chrome's HSTS set after each request. How do I let browsers know that I want all my pages from userbob.com/tools/ to load as http? My site uses an apache/tomcat web server.
(Just FYI, the reason I want the pages in the tools directory to serve pages over http instead of https is because some of them are meant to iframe http pages. If I try to iframe an http page from an https page I end up getting mixed-content errors.)
HTTP Strict Transport Security (or HSTS) is a setting your site can send to browsers which says "I only want to use HTTPS on my site - if someone tries to go to a HTTP link, automatically upgrade them to HTTPS before you send the request". It basically won't allow you to send any HTTP traffic, either accidentally or intentionally.
This is a security feature. HTTP traffic can be intercepted, read, altered and redirected to other domains. HTTPS-only websites should redirect HTTP traffic to HTTPS, but there are various security issues/attacks if any requests are still initially sent over HTTP so HSTS prevents this.
The way HSTS works is that your website sends a HTTP Header Strict-Transport-Security with a value of, for example, max-age=31536000; includeSubDomains on your HTTPS requests. The browser caches this and activates HSTS for 31536000 seconds (1 year), in this example. You can see this HTTP Header in your browsers web developer tools or by using a site like https://securityheaders.io . By using the chrome://net-internals/#hsts site you are able to clear that cache and allow HTTP traffic again. However as soon as you visit the site over HTTPS it will send the Header again and the browser will revert back to HTTPS-only.
So to permanently remove this setting you need to stop sending that Strict-Transport-Security Header. Find this in your Apache/Tomcat server and turn it off. Or better yet change it to max-age=0; includeSubDomains for a while first (which tells the browser to clear the cache after 0 seconds and so turns it off without having to visit chrome://net-internals/#hsts, as long as you visit the site over HTTPS to pick up this Header, and then remove the Header completely later.
Once you turn off HSTS you can revert back to having some pages on HTTPS and some on HTTP with standard redirects.
However it would be remiss of me to not warn you against going back to HTTP. HTTPS is the new standard and there is a general push to encourage all sites to move to HTTPS and penalise those that do not. Read his post for more information:
https://www.troyhunt.com/life-is-about-to-get-harder-for-websites-without-https/
While you are correct that you cannot frame HTTP content on a HTTPS page, you should consider if there is another way to address this problem. A single HTTP page on your site can cause security problems like leaking cookies (if they are not set up correctly). Plus frames are horrible and shouldn't be used anymore :-)
You can use rewrite rules to redirect https requests to http inside of subdirectory. Create an .htaccess file inside tools directory and add the following content:
RewriteEngine On
RewriteCond %{HTTPS} on
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
Make sure that apache mod_rewrite is enabled.
Basically any HTTP 301 response from an HTTPS request indicating a target redirect to HTTP should never be honored at all by any browser, those servers doing that are clearly violating basic security, or are severaly compromized.
However a 301 reply to an HTTPS request can still redirect to another HTTPS target (including on another domain, provided that other CORS requirements are met).
If you navigate an HTTPS link (or a javascript event handler) and the browser starts loading that HTTPS target which replies with 301 redirect to HTTP, the behavior of the browser should be like if it was a 500 server error, or a connection failure (DNS name not resolved, server not responding timeout).
Such server-side redirect are clearly invalid. And website admins should never do that ! If they want to close a service and inform HTTPS users that the service is hosted elsewhere and no longer secure, they MUST return a valid HTTPS response page with NO redirect at all, and this should really be a 4xx error page (most probably 404 PAGE NOT FOUND) and they should not redirect to another HTTPS service (e.g. a third-party hosted search engine or parking page) which does not respect CORS requirements, or sends false media-types (it is acceptable to not honor the requested language and display that page in another language).
Browsers that implement HSTS are perfectly correct and going to the right direction. But I really think that CORS specifications are a mess, just tweaked to still allow advertizing network to host and control themselves the ads they broadcast to other websites.
I strongly think that serious websites that still want to display ads (or any tracker for audience measurement) for valid reasons can host these ads/trackers themselves, on their own domain and in the same protocol: servers can still get themselves the ads content they want to broadcast by downloading/refreshing these ads themselves and maintaining their own local cache. They can track their audience themselves by collecting the data they need and want and filtering it on their own server if they want this data to be analysed by a third party: websites will have to seriously implement thelselves the privacy requirements.
I hate now those too many websites that, when visited, are being tracked by dozens of third parties, including very intrusive ones like Facebook and most advertizing networks, plus many very weak third party services that have very poor quality/security and send very bad content they never control (including fake ads, fake news, promoting illegal activities, illegal businesses, invalid age rating...).
Let's return to the origin of the web: one site, one domain, one third party. This does not mean that they cannot link to other third party sites, but these must done only with an explicit user action (tapping or clicking), and visitors MUST be able to kn ow wherre this will go to, or which content will be displayed.
This is even possible for inserting videos (e.g. Youtube) in news articles: the news website can host themselves a cache of static images for the frame and icons for the "play" button: when users click that icon, it will start activating the third party video, and in that case the thirf party will interact directly with that user and can collect other data. But the unactivated contents will be tracked only by the origin website, under their own published policy.
In my local development environment I use apache server. What worked for me was :
Open you config file in sites-availabe/yoursite.conf. then add the following line inside your virtualhost:
Header always set Strict-Transport-Security "max-age=0". Restart your server.
Apologies if this is a duplicate, but I couldn't find a question fitting my exact circumstances.
I am redesigning a site, part of which will require SSL coverage. I have set up SSL with our hosting provider, but this is shared SSL. Whereas our current site is at www.companyname.com, the secure server is at companyname.genericssl-host.com.
I believe the best way to proceed is to simply shift all the web files onto the secure server, whether they need to be secure or not, then redirect www.companyname.com to there. However, the provider informs me that if I do that, the URL in the browser address bar will still read companyname.genericssl-host.com once the redirect completes, and that I would need to edit the htaccess file to make it read good ol' www.companyname.com again.
What does the htaccess file need to contain in order to do this?
Not sure what your hosting provider is referring to, but changing it back to "www.companyname.com" defeats the purpose of using SSL at all. What shows up in the browser's address bar is:
what host the browser is going to send a request to
what URI it will request
the query string if there is any
If you change it back to www.companyname.com, it's going to send a non-SSL request to that host, which defeats the purpose of redirecting it to SSL in the first place.
You need to buy a certificate for *.companyname.com and install if on a host specific to your server.
I've setup 'ssl endpoint' on heroku and that works great. I have a cname for www.miketown3.com pointing to osaka-4635.herokussl.com. https is working great.
However, when I GET http://www.miketown3.com, I get redirected to https://www.miketown3.com and I want to remain on http. When testing my app locally this does not happen. Also, when watching the traffic in chrome, I see no http level redirection of any kind. There's just a request to http://www.miketown3.com with no response. Then immediately the next request is to https://www.miketown3.com, but this time there is a valid response.
My question, where is this redirection happening and how can I stop it? Thanks a bunch!
Since your www subdomain is pointed to osaka-4635.herokussl.com, the server at this address performs the redirection. To stop it, you have to remove the ssl endpoint addon, and change your DNS records per https://devcenter.heroku.com/articles/custom-domains (e.g. point your root and www subdomain to yourapp.herokuapp.com)
I'm not 100% sure what you question is but if you only want HTTPS for certain parts(urls) of your website and assuming you are using rails you can add the gem 'rack-ssl-enforcer', this will allow you to specify what parts of your website redirect to https i.e. login
This was a chrome cache thing.
One of YSlow's measurables is to use cookie-free domains to serve static files.
"When the browser requests a static
image and sends cookies with the
request, the server ignores the
cookies. These cookies are unnecessary
network traffic. To workaround this
problem, make sure that static
components are requested with
cookie-free requests by creating a
subdomain and hosting them there." --
Yahoo YSlow
I interpret this to mean that I could experience performance gains if I move www.example.com/images to static.example.com/images.
Although this is easy to do, I would lose the handy ability within my content management system (Joomla/WordPress) to easily reference and link to these images.
Is it possible to use .htaccess to redirect all requests for a particular folder on www.example.com to a folder on static.example.com instead? Would this method also fool the CMS into thinking the images were located in the default locations on its own domain?
Is it possible to use .htaccess to redirect all requests
for a particular folder on www.example.com to a folder on
static.example.com instead?
Possible, but counter productive — the client would have to make an HTTP request, get the redirect response, then make another HTTP request.
This costs a lot more than the single line of cookie data saved!
Would this method also fool the CMS into thinking the images
were located in the default locations on its own domain?
No.
Although this is easy to do, I would
lose the handy ability within my
content management system
(Joomla/WordPress) to easily reference
and link to these images.
What you could try to do is create a plugin in Joomla that dinamically creates these references.
For example, you have a plugin that when you enter {dinamic_path path} in an article, it appends 'static.example.com/images' to the path provided. So, everytime you need to change the server path, you just change in the plugin. For the links that are already in the database, you can try to use phpMyAdmin to change them in this structure.
It still loses the WYSIWYG hability in TinyMCE, but is an alternative.
In theory you could create a virtual domain that points directly to the images folder, such as images.example.com. Then in your CMS (hopefully at the theme layer) you could replace any paths that point to the images folder with an absolute path to the subdomain.
The redirects would cause far more network traffic, and far more latency, than simply leaving things as they are.
It would redirect the request but the client would still be sending its cookies to the server, so really you accomplished nothing. You would have to directly access the files from a domain that isn't storing cookies for it to work.
What you really want to do is use staticexample.com/images instead of static.example.com/images so that you don't pick up any cookies on the example.com domain that you may have set. If all you do is server images from that domain with a simple apache server or something then you can configure that server not to return even a session cookie.
The redirects are a very bad idea. Cookies cause some performance hits but round trips to the server such as a redirect would cause are a much more serious performance issue.
I did below and gained success:
<FilesMatch "!\.(gif|jpe?g|png)$">
php_value session.cookie_domain example.com
</FilesMatch>
What it means is that if you do not set images in cookie information.
Then images are cookie-free with server.