I have setup a subdomain rule like this:
Match https://web*.example.com/readme.txt
Forward to https://example.com/subdomain-readme.txt
But it seems to be ignored. Is this supposed to work? I know wildcard works on the path, but seems to be a fail on the host.
Yes they apparently do (though not documented so no real guarantee it will remain possible). I had a caching issue previously, but it seems to work now.
Related
I just removed some virtual hosts and restored them from backup.
I noticed that no matter what domain from the following i hit:
kidsclubpaidika.gr
ypsilandio.gr
varsa.gr
always my hit gets instantly redirected to domain kidsclubpaidika.grinstead.
Why is this happening?
I use Webmin/virtualmin btw.
here is my relevant httpd.conf https://pastebin.com/vzwbzTh8
There's a FAQ about this kind of problem: https://www.virtualmin.com/documentation/web/troubleshooting#toc-the-wrong-site-shows-up-V5JtxdKg
The short description of the problem is that when combining VirtualHosts that use IP addresses and *, the way Apache decides what to show is unintuitive (to put it mildly). Mixing * and IP-based VirtualHosts is, thus, not recommended. So, find the virtual hosts that use * and switch them to IPs, or find all the IPs and switch them to *. Don't mix and match. I usually recommend using IPs, but either works, as long as you only have one IP.
If you have a default site (e.g. 000-default on Ubuntu/Debian), disable it. In a virtual hosting environment, "default" doesn't really have the same meaning and can lead to confusing results. The Virtualmin installer will do that for you, but doing a dist upgrade will lead to config files being overwritten and that site being re-enabled.
Don't know, maybe someone had the same problem before..
I've got a correctly configured ssl certificate in my server.
If I activate prestashop ssl mode, then several pages generate an infinite redirection loop warning....
I really can't figure out why..
One thing I can say, is that in backoffice, clicking on the ssl acivation link, it does not activate it: it stays, silently, no rerrors, nothing.
So to activate ssl I had to manually change the relevant config variable on the DB.
This could maybe be a symptom of something wrong on the server?
Anyone had the same problem?
Thank you
Apart from upgrading to v1.6.0.11, the solution was to add SetEnv HTTPS On at the very top of .htaccess. That's because several prestashop functions rely on $_SERVER['HTTPS'] and/or $_SERVER['SSL'] vars to guess the urls. One of the most notable functions using them and itself used by many others is Tools::usingSecureMode(). Simply those vars weren't visible before adding SetEnv HTTPS On.
Anyway, this is not to be considered a universal solution, because for example in my local MAMP installation I didn't have the same issue: just worked. I only needed the tweak for the remote server.
Beside this, also note that in backoffice, unde url/seo prefs, I disabled the apache multiviews.
Hope it helps
I am looking for a solution which would redirect the externally facing http://mycompany.com/external/* to be redirected/proxied to http://internal-host:1234/internal/*
(the asterisk is used as a wildcard)
OK, I guess the sentence above is not enough, so here are the details:
In my intranet I have several servers, (names, addresses, ports, and context paths are obviously made-up for the sake of simplicity):
HRServer running at address 10.10.10.10:1010/hr
MailServer running at address 20.20.20.20:2020/mail
My system is accessible from internet only from ip 78.78.78.78, and the constraint here is that I can use only one port (e.g. 8080). In other words - whatever the solution of my problem is - the external address should start with 78.78.78.78:8080
What I need to do is to expose both HR and Mail services though this port.
The first thing which came to my mind was to write two simple portlets (or an HTML with two frames) and to embed them in a simple web page at 78.78.78.78:8080/
But obviously this will not work, as the portlets will redirect the browser to e.g 10.10.10.10:1010/hr which is not visible from the internet.
So my next thought was - OK, lets find a reverse proxy which has dispatching capabilities. Then I can make
78.78.78.78:8080/hr to "redirect" to the internal 10.10.10.10:1010/hr
78.78.78.78:8080/mail to "redirect" to the internal 20.20.20.20:2020/mail
I'd also expect that if let's say the mail server unread messages are seen on 20.20.20.20:2020/mail/unread the unread messages to be also accessible from internet.
Roughly speaking - I'd expect
78.78.78.78:8080/mail/* to redirect to the internal 20.20.20.20:2020/mail/* (the asterisk is used as a wildcard)
I really feel I am missing the obvious here, but honestly - I've spent quite a while in researching several proxies and I did not find the answer. I might be looking for the wrong words or something, but I could not find reverse proxy which can be configured to dispatch external path to different internal paths.
So please - if the answer is e.g. the Apache mod_proxy - please give me a hint about the parameter names that I should be looking for.
Lastly - I am going to run thin in a FreeBSD OS, but this is not a strong requirement (other *nix OSes are also fine)
Thanks!
It took quite a while, but here is the answer:
A good solution is nginx (pronounced "Engine X").
To reroute all traffic which comes to
https://mycompany.com/external/* to
http://internal-host:1234/internal/* (the asterisk is used as a wildcard) you need to have the following configuration:
location ~ ^/internal/ {
rewrite ^/internal/(.*)$ /$1 break;
proxy_pass http://internal-host:1234;
}
And this approach can be used for all the other addresses - e.g. HR portal, mail, etc.
Finally, to give you a heads up - the following configuration does not work:
location ~ ^/internal/(.*)$ {
proxy_pass http://internal-host:1234/internal/$1;
}
It turns out nginx will always proxypass the whole URI when regex is used, so the rule has to be the one above (which does url-rewrite).
I have purchased an ssl certificate, I have enabled the SSL setting in the settings and I have changed both config files to go to https but when I visit http://bit.ly/TCkEBv the first page is https the rest are not. How can I fix this?
I realize this is an old thread but considering the recent google SSL-everywhere indexing changes, i figured it was relevant. The following example will make OC use https in all links. You have to change 3 characters in system/library/url.php. They deleted this on the forums which is understandable, but we have ran it for a week of production traffic on mixed SSL multistores with no issues.
WARNING: Your mods may be different - run through them all in a test after enabling this...especially any redirect managers. Here is the tweak for 1.5.6:
Open store/system/library/url.php and find $url = $this->url; in an IF statement somewhere near line 18. Change it to $url = $this->ssl; and there ya go.
PS: Also there is a vastly untested method to send the https-preferred as a header using $response->addHeader('Strict-Transport-Security: max-age=31536000'); but i am unsure of best spot to put it besides index.php. Also, although it works in test, unsure of all-server implications. Header controller seems logical, but not all OC areas use header controller :). Experiment with best placement for that....just dont do it in the $url replicator even if it seems like it works.
As per the forum thread, this is not actually a bug just the way that the cart is set up - that is most pages are not set as HTTPS and will revert to HTTP once you click on a non HTTPS link
Let's say you have a Domain called example.org
Instead of changing the code, in Apache, you could do this...
In addition to your Domain-SSL.conf, you can copy that configuration to Domain.conf and edit it to use port 80 instead of 443
Then, add this line in the Server definitions at the top, right before DirectoryIndex...
Redirect / https://example.org
This will simply redirect every request back to the SSL configuration, adding the https:// in front of every link. No code changes required to OC.
This has been working on my busy production server for several years without a single problem.
I'm just beginning to test my usage of mod_rewrite on a local apache setup.
While rewrite rules are working fine, my problem is that a page like "localhost/foo/" is automatically redirected to "localhost/foo.php". This happens even with no rewrite rules. Is this normal? I assume not, since this does not happen on my hosted domain. How can I disable this?
Figured out what the problem was - documenting it as an answer for future searchers [is this the correct procedure?]
I had to disable MultiViews - it was redirecting localhost/foo to localhost/foo.php if it could find that file. Everything worked just fine once that was done.
Some sort of rewrite is going on. You could rename the actual module on disk to make sure its not used. In Linux it is /usr/lib/httpd/modules/mod_rewrite.so