I need a help to setup a complex .HTACCESS rule.
My site (abc.com) has SSL setup.
The gallery images are hosted in an external site pqr.com, it doesn't have SSL.
I want, if my site (abc.com) is opened in ssl (that is https://abc.com) the external images (jpeg or png) that are coming from pqr.com will use a SSL proxy.
Example - http://pqr.com/pic1.png will convert into https://abc.com/proxy/pqr.com/pic1.png
How to do it?
To convert http://pqr.com/pic1.png to https://abc.com/proxy/pqr.com/pic1.png - you will need rules on external domain pqr.com and also need the same images on abc.com (which will not make any sense).
The other option is to install SSL on pqr.com and provide secure access. Check out this article and see if SSL installation is really needed for pqr.com.
Hope this helps!
Related
I've just reset my Ubuntu 14.04 LAMP server hosted with digital ocean. Could someone tell me the 'proper' way to do server configuration. My goal is to do everything as clean as possible (and hopefully well structured).
I intend on using the server mainly for programming and data analytics, however I do plan on hosting my website in /var/www/html. I also plan on using letsencrypt/certbot to get an easy SSL. With this in mind, these are the main goals I would like to accomplish:
1) Redirect the website to ALWAYS be served through https AND www.
2) Enable HSTS for the entire website.
3) Enable clean url's (remove .php extensions and what not).
Since I would like all of these properties to be used across the entire website, should the configuration be done inside of the /etc/apache2/ folder? Or should it be done inside of .htaccess?
And if it should be done inside of apache2 configuration, which file should I add it to? And finally, how exactly should it be added? (for example vhost 80/443, inside of a mod_something section, etc).
Thank you in advance, I would appreciate and consider any advice about Apache and htaccess!
I'm trying to use Heroku's Automatic Certificate Management to set up SSL for my site. My app is on heroku at myapp.herokuapp.com, and I currently have Subdomain Forwarding set up so that http://www.myapp.com properly shows my app.
What I want is to have my site hosted at https://myapp.com.
I ran heroku certs:auto:enable, but it shows:
=== Automatic Certificate Management is enabled on myapp
Domain Status
───────────────── ───────────
www.myapp.com Failing
Running heroku domains shows:
=== myapp Heroku Domain
myapp.herokuapp.com
=== myapp Custom Domains
Domain Name DNS Target
───────────────── ───────────────────────────────
www.myapp.com www.myapp.com.herokudns.com
Right now, in Google Domains, I have a Subdomain Forward from #.myapp.com to http://www.myapp.com. I also have a Custom Resource Record with the name www, type CNAME, and data myapp.herokuapp.com..
What do I need to change in my setup so that I can host my site at https://myapp.com?
Unfortunately, Google Domains does not support the ANAME or ALIAS record. You must use one of these for your apex domain. Here's the full list supported by Google Domains.
https://support.google.com/domains/answer/3290350
Heroku has a list of DNS providers that support the ALIAS or ANAME records here: https://devcenter.heroku.com/articles/custom-domains#add-a-custom-root-domain Personally, I use DNSimple and have had great success with them.
The CNAME target needs to be www.myapp.com.herokudns.com. In your question above you only have the apex record in your DNS in myapp.com.herokudns.com. If this is not the case can you share the domain so I can dig the record for more information?
I've had the same problem with Heroku and other PaaS providers over and over: depending who provides and manages the DNS for your domain you may or may not able to use a CNAME or ALIAS record on the naked domain. That's why we've created a simple service to solve this by applying a simple SSL redirection from the naked domain to the "www" under SSL, without changing your DNS management provider: NakedSSL will give you an IP and will create and host an SSL certificate for your naked domain (https://yourdomain.com), redirecting it to the HTTPS URL that you want (most likely "https://www.yourdomain.com").
Disclaimer: I'm obviously part of the team that created NakedSSL. I hope you don't take this as self-promotion (anyway we offer it for free for 1 domain, which totally fits the needs of 95% of developers/hobbyist out there), but as a way to deal with this annoying situation in an easy way.
I'm trying to use Liferay for http and https
if I include in portal-ext.properties:
company.security.auth.requires.https=true
web.server.protocol=https
Will be working ok with https but in http is showing incorrect themes due is trying to load https://domain.com/theme
If I remove this two lines is working ok for http but not for https.
What can I do?
IMHO mixed mode, e.g. offering http as well as https never gives you what you expect: You expect security from https, but you always risk leaking session information, e.g. being vulnerable to session-hijacking attacks (ala Firesheep). My actual advice would be to go https only if you do https for security. Read on if that's not an option for you, but don't complain when you find information leaking (this is not dependent on Liferay, but for any web-based environment)
What is the exact problem that you have with the themes? (images/css through http?) Which version of Liferay are you using?
Before you specify more, you might want to configure your theme's "virtual path", this will rewrite all the URLs referring to your theme. It's typically used to serve static resources through a webserver or cdn, but it works with any kind of URL. Simply using a protocol-relative URL should work (I love this mostly unknown http feature):
Add this to your theme's liferay-look-and-feel.xml:
<look-and-feel>
<theme id="my" name="My Theme">
<virtual-path>//domain.com/myTheme</virtual-path>
</theme>
</look-and-feel>
note that the URL omits the protocol part, http: or https:, thus the browser will use the same protocol that the whole page is loaded with.
Edit: corrected the xml. Will investigate if there's a problem with protocol-relative URLs in themes.
Edit 2: Something is weird. It seems, virtual-path does not work like this, but I recall it did earlier. Do you add domain.com as cdn.host.http or cdn.host.https? (this would be concatenated)
On related stuff, please check if you're running Apache in front of your appserver. In this case you might forward some traffic for the portal (e.g. in the virtual host for http) but not forward the traffic in the https virtual host.
I have enabled SSL on my site. My problem is that https leads to a different directory. Directory should be same for SSL. I am using Parallel Plesk and not much aware about it. Can you please help to solve this issue.
Some hosting companies give you SSL, but it has it's own directory. It is expected that you'd put any pages that require SSL in that directory.
It's not the best setup, but it looks like you've got that arrangement.
I am currently building an application that I will host and will have multi-tenants (SaaS) called over the web, I would like them to be able to have subdomain.theircompany.com be able to point to subdomain.mycompany.com (or if they wish, point a full TLD to a subdomain with me).
The way I have been expecting this to work is to simply have a wildcard 'ServerAlias *.mycompany.com' in my Apache config pointing to my application, which then extracts the host being called...They then redirect via a CNAME entry on their host.
My question is, would this approach allow external subdomains to be pointed to a CNAME URL instead of IP? As this runs on one account on my system, am I able to install an SSL for a single wildcard if that customers wants to be running on SSL?
Any other suggestions/approaches would be greatly appreciated!
Thanks
A CNAME will work for the purposes of naming, but not for the purposes of a wildcard SSL cert.
Specifically, example.theircompany.com can have a CNAME record with a value of example.yourcompany.com. This will mean that example.theircompany.com will transparently resolve to your site. In other words, a browser still sees example.theircompany.com, not example.yourcompany.com.
As such, the SSL cert must be for the theircompany.com domain, not the yourcompany.com domain.