Nginx will not stop rewriting - mod-rewrite

I am attempting to configure an owncloud server that rewrites all incoming requests and ships them back out at the exact same domain and request uri but change the scheme from http to https.
This is failed miserably. I tried:
redirect 301 https://$hostname/$request_uri
and
rewrite ^ https://$hostname/$request_uri
Anyway, after removing that just to make sure the basic nginx configuration would work it as it had prior to adding the ssl redirects/rewrites it will NOT stop changing the scheme to https.
Is there a cached list somewhere in nginx's configuration that keeps hold of redirect/rewrite protocols? I cleared my browser cache completely and it will not stop.

AH HA!
in config/config.php there was a line
'forcessl' => true,
Stupid line got switched on when it received a request at the 443 port.
Turned off and standard http owncloud works and neither apache/nginx are redirecting to ssl.
Phew.

Related

Redirect http traffic to https on a non standard apache port

I have a website running at https://example.com:555
The 80 and 443 port for the same public ip have been forwarded to another server.
I only want to re-direct the url from http://example.com:555/1618/?id=877 to https://example.com:555/1618/?id=877
Right now I am getting the 400 error "Your browser sent a request that this server could not understand..."
I am using apache 2.4 on ubuntu 20.04
Any leads would be highly appreciated.
Thanks.
adding "ErrorDocument 400 https://example.com:555" in .htaccess
works but the id parameter is not passed
adding ErrorDocument in the localized-error-pages.conf in apache
works but the id parameter is not passed
configure Strict-Transport-Security
didnt work
trying different $1 , REQUEST_URI etc in .htaccess
did not work

Force HTTPS for app deployed in google app engine

If an application developed to support only HTTP. What configuration we should do in google app engine, that it force developer to have HTTPS support. We can add an entry(for handler) in "app.yaml", but in order to redirection. Just want to know anything else we can do to prevent such thing(in short should work with HTTPS only). Probably we can do something from ingress/loadbalancer/ssl etc but that's looks paid and don't want that currently.
You just have to set secure: always in app.yaml for your route handlers. Any call to your app from http will automatically get redirected to https
I was having trouble putting a whole site over HTTPS, so searching I found a solution that worked for me:
https://cloud.google.com/appengine/docs/standard/python3/config/appref
what it says is that you can change your app.yaml file and place in the handlers
- url: /.*
secure: always
redirect_http_response_code: 301
script: auto

Typo3 behind Proxy

I'm trying to get a Typo3 (6.2) instance running behind a (forwarding) proxy (squid). I have set
'HTTP' => array(
'adapter' => 'curl',
'proxy_host' => 'my.local.proxy.ip',
'proxy_port' => '8080',
)
as well as
'SYS' => array(
'curlProxyServer' => 'http://my.local.proxy.ip:8080',
'curlUse' => '1'
)
The proxy doesn't ask for credentials.
When I try to update the extension list, I get the error message
Update Extension List
Could not access remote resource http://repositories.typo3.org/mirrors.xml.gz.
If I try Get preconfigured distribution, it says
1342635425
Could not access remote resource http://repositories.typo3.org/mirrors.xml.gz.
According to the proxy log, the server doesn't even try to connect to the proxy.
I can easily download the file using wget on the command line.
Ok, I've investigated he issue a bit more and from what I can tell, the Typo3 doesn't even try to connect anywhere.
I used tcpdump and wireshark to analyze the network traffic. The site claims to have tried sending a http-Request to repositories.typo3.org so I'd expect to find either a proxy connection attempt or a DNS query followed by an attempt to connect to that IP. (Of course, the latter is known not to work.) However, none of this happens.
I've tried some slight changes in the variable curlProxyServer. The documentation clearly states
String: Proxyserver as http://proxy:port/. Deprecated since 4.6 - will be removed in TYPO3 CMS 7. See below for http options.
So I tried adding the trailing "/" and removing the "http://" - no change. I'm confident there's no problem whatsoever regarding the proxy as the proxy isn't even contacted and has been working perfectly fine for everything else for years.
The error message comes from \TYPO3\CMS\Extensionmanager\Utility\Repository\Helper::fetchFile(). This one uses \TYPO3\CMS\Core\Utility\GeneralUtility::getUrl() to get the actual file content.
According to your setting, it should use the first part of the function, because curlUse is set and the URL starts with http or https.
So what you would need to do now is to throw some debug lines in the code and check at what point the request goes wrong.
Look at the source code, three possibilities come to mind:
The curl proxy parameters does not support a scheme, thus it should be 'curlProxyServer' => 'my.local.proxy.ip:8080',.
Some redirect does not work.
Your proxy has problems with https, because the TYPO3 TER should be queried over https.

can't pass the tor and privoxy page test on CentOS7

I have successfully started the tor and privoxy. But when I came to the page test, it always said that "Privoxy is not being used" .
I followed the answer of Question 4.10 "How do I use Privoxy together with Tor?" on this page ,but failed.
I'm working on CentOS7 and used Wget to get the test page http://config.privoxy.org/show-status .
Any help would be really appreciated!
this is what I type in command line:
(myapp)[hadoop#kaiyuandao myapp]$ sudo service privoxy start
/etc/init.d/privoxy: line 97: kill: (24849) - No such process
Starting Privoxy, OK.
(myapp)[hadoop#kaiyuandao myapp]$ sudo service tor start
Starting tor...done.
(myapp)[hadoop#kaiyuandao myapp]$ wget http://config.privoxy.org/show-status
--2015-09-08 05:43:08-- http://config.privoxy.org/show-status
Resolving config.privoxy.org (config.privoxy.org)... 198.199.92.59, 162.243.226.87
Connecting to config.privoxy.org (config.privoxy.org)|198.199.92.59|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://privoxy.org/config/show-status [following]
--2015-09-08 05:43:08-- http://privoxy.org/config/show-status
Resolving privoxy.org (privoxy.org)... 216.34.181.97
Connecting to privoxy.org (privoxy.org)|216.34.181.97|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://www.privoxy.org/config/ [following]
--2015-09-08 05:43:09-- http://www.privoxy.org/config/
Resolving www.privoxy.org (www.privoxy.org)... 216.34.181.97
Reusing existing connection to privoxy.org:80.
HTTP request sent, awaiting response... 200 OK
Length: 3832 (3.7K) [text/html]
Saving to: ?.how-status.1?
100%[=======================================================================================================>] 3,832 --.-K/s in 0s
2015-09-08 05:43:09 (82.2 MB/s) - ?.how-status.1?.saved [3832/3832]
(myapp)[hadoop#kaiyuandao myapp]$ vi show-status
and this is the content I get from the test page
Privoxy is not being used
The fact that you are reading this page shows that Privoxy was not used in the process of accessing it. Had the request been made through Privoxy, it would have been intercepted and you would be looking at Privoxy's web-based user interface now.
So what went wrong? Chances are (in this order) that:
this page is in your browser's cache. You've once been here before starting to use Privoxy, and now your browser thinks that it already knows the content of this page. Hence it doesn't request a fresh copy.
Force your browser to do that. With most browsers, clicking "reload" while holding down the shift key (shift-reloading) should suffice, but you might need to manually clear the browser's cache (both memory and disk cache).
your browser is not set up to use Privoxy.
Check your browser's proxy settings and make sure that it uses 127.0.0.1, port 8118 (or, if you did a custom configuration, whatever different values you used).
when using multiple proxies in a chain, that either the chain is broken at some point before Privoxy, or that an earlier proxy serves this page from its cache.
Shift-reload, clear all caches, and if the problem still persists, trace the proxy chain starting with your browser's settings. Please refer to the forwarding chapter of the user manual for details.
Until version 2.9.13, Privoxy was also known as Internet Junkbuster. If you recently upgraded, then the web-based interface has moved - it is now at http://config.privoxy.org/ (Short form: p.p [Privoxy Proxy]).
If you have read the user manual and still have trouble, feel free to submit a support request to get help.
My main problem is that I forgot to set the http proxy.
Since I use wget to get pages, I changed /etc/wgetrc and set http_proxy=127.0.0.1 .
FYI

Nginx https redirects - stop further rules processing

I'm trying to configure http and https redirects from an old site to a new one.
According to the rewrite directive docs:
If the replacement string begins with http:// then the client will
be redirected, and any further rewrite directives are terminated.
And I'm trying to achieve the same with https to no avail.
This is my server config:
listen 80;
listen 443 ssl;
server_name mydomain.com
rewrite ^/path/resource(.*)$ $scheme://newdomain.com/newpath/resource$1 permanent;
...
return 301 http://newdomain.com/newpath/;
Using http I get what I'm looking for: if I access mydomain.com/path/resource I'm redirected to newdomain.com/newpath/resource.
However, the same with https redirects me to http://newdomain.com/newpath/.
I have rewrite_log on and in both cases the rewrite rule is matched but the https protocol does not stop further rules processing.
I have the feeling that either I'm missing something really obvious or I'm not approaching this problem properly. I wouldn't mind doing this in any different way at all if it works.
Have any of you out there any idea on how to achieve the http redirect with https too?
I usually like to use return instead of rewrite for redirects, try matching the path with a location block
location ~ /path/resource(.*) {
return 301 $scheme://newdomain.com/newpath/resource$1;
}
I think this way you know for sure there will be no further processing, because it's only 1 line, try it and tell me how it goes.
PS: This will maintain the $scheme of the request, requests to http:// will be redirected to a http:// and https:// will be redirected to https://

Resources