Typo3 behind Proxy - 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.

Related

localhost refuses to connect - ERR_CONNECTION_REFUSED

I have a simple MVC web application where javascript code sends ajax requests to the controller and the controller sends back responses.
I built the app 2 years ago and everything used to work fine. Now I tried to run the app again locally and met with the following problem:
whenever an Ajax request is sent from the frontend to the controller (running on localhost), the localhost refuses to connect and I get an ERR_CONNECTION_REFUSED message in (chrome's) javascript-console. (In Safari's javascript-console I get the following error message: "Failed to load resource: Could not connect to the server.")
I'm running the app using NetBeans 11.2. My NetBeans IDE uses GlassFish as server:
I removed the Glassfish server from NetBeans IDE, deleted its folder in my home directory and then added the Glassfish server again in my NetBeans IDE (which also entailed downloading the the newest version of the Glassfish server).
Still, the server refuses to accept any requests from the frontend.
I also tried using Payara Server (version 5.193). That didn't make a difference either.
The frontend itself looks fine at first glance by the way. That is, going to http://localhost:8080/myapp loads the frontend of the app. However, any dynamic features of the app don't work because the server refuses to accept any Ajax requests coming from the frontend (and initiated through mouse clicks).
How can I fix this?
I think I found the reason for the problem:
In my javascript-file I have the following line of code:
var url = "http://localhost:8080/myapp/Controller";
The variable "url" is passed to all the AJAX requests sent to localhost.
But here is the crazy thing: the AJAX requests are not sent to "http://localhost:8080/myapp/Controller" but to "http://localhost:8081/myapp/Controller" !!!!!
What the hell is going on here?!
Did you use port 8081 before and then changed the variable "url" to the new port 8080? In this case, maybe the variable is still set to the old value in the cache. Restart your computer and see whether this fixes the problem.
If the value of the attribute http-listener is localhost, it will refuse the connection external connection.
You can verify using its value using the command
asadmin> get server-config.network-config.network-listeners.network-listener.http-listener-1.*
Information similar to the following should returned:
server.http-service.http-listener.http-listener-1.acceptor-threads = 1
server.http-service.http-listener.http-listener-1.address = 0.0.0.0
server.http-service.http-listener.http-listener-1.blocking-enabled = false
server.http-service.http-listener.http-listener-1.default-virtual-server = server
server.http-service.http-listener.http-listener-1.enabled = true
server.http-service.http-listener.http-listener-1.external-port =
server.http-service.http-listener.http-listener-1.family = inet
server.http-service.http-listener.http-listener-1.id = http-listener-1
server.http-service.http-listener.http-listener-1.port = 8080
server.http-service.http-listener.http-listener-1.redirect-port =
server.http-service.http-listener.http-listener-1.security-enabled = false
server.http-service.http-listener.http-listener-1.server-name =
server.http-service.http-listener.http-listener-1.xpowered-by = true
Modify an attribute by using the set subcommand.
This example sets the address attribute of http-listener-1 to 0.0.0.0:
asadmin> set server.http-service.http-listener.http-listener-1.address = 0.0.0.0
Reference:
https://docs.oracle.com/cd/E19798-01/821-1751/ablaq/index.html

How to rewrite specific urls in lighttpd

I moved a wiki install on lighttpd from https://www.example.com/wiki to a subdomain of https://wiki.example.com so I need to redirect anything wiki related to the new subdomain.
url.rewrite-once = (
"^/wiki" => "https://wiki.example.com",
)
This gives me an error 404 not found as the browser is still pointed to the old page.
In addition I would like to add a rule to handle pages people already have bookmarked such as sending
https://www.example.com/wiki/index.php?title=Main_Page
to
https://wiki.example.com/index.php?title=Main_Page
I ended up doing this:
url.redirect = ( "^/wiki/(.*)$ => https://wiki.example.net/$1",
"^/wiki/([^?]*)(?:\?(.*))?" => "https://wiki.example.net/index.php?title=$1&$2",
)
This works on 99% of the site. However there are a few forums threads that do not display correctly now because they are trying to redirect.
This one works and can view the forum normally
https://www.example.net/forums/showthread.php?796166-Wiki-Skins
This one breaks and tries to redirect
https://www.twcenter.net/forums/showthread.php?796105-Wiki-Extensions-amp-Gadgets
While Stackoverflow is a good resource, please also try reading the primary source documentation for the tool you are asking about. In this case, that is lighttpd documentation.
You might consider using mod_redirect to redirect the client. See documentation and examples at https://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_ModRedirect

SwiftMailer with Gmail SMTP suddenly stopped working: Connection could not be established with host smtp.gmail.com [ #0]

I have several websites that use SwiftMailer with Gmail. I haven't touched any of these sites' code, and suddenly all of them no longer work, resulting in Fatal errors: Connection could not be established with host smtp.gmail.com [ #0]
I've searched all over the internet for what may cause this, tried several solutions, but nothing works. Does anyone know if something either changed on Gmail's end (they no longer allow me to connect?) or what else could have happened?
Some things I tried:
open ports on server router (465 for SSL) - didn't help
disable firewall on server - didn't help
try the IP-address of smtp.gmail.com in stead of the domain name, using ping to find out the IP - didn't help
changing settings in the SwiftMailer program (setting certain verification options to false) - didn't help
I know this isn't a very concrete coding question, but I haven't changed anything to my code so the problem literally cannot be in my code. I'm just hoping someone knows what changed 2-3 days ago, and what I need to do to make SwiftMailer work again.
Note: the Gmail accounts' passwords or account security settings such as 2-step verification and sorts also didn't change. Also, using a different SMTP such as the one from GMX.net, the script still works just fine!
Strange hm?
I had the same issue today. I succesfully tried the workaround mentioned in this web.
Something has been changed in Gmail config. I will try a better solution but in the mean time will use this workaround.
Hope it help.
https://github.com/swiftmailer/swiftmailer/issues/544
You could disable the SSL check by modifying the function
"_establishSocketConnection" in StreamBuffer.php. Add these lines
before stream_socket_client command:
$options['ssl']['verify_peer'] = FALSE;
$options['ssl']['verify_peer_name'] = FALSE;
I would highly recommend you look into the logging plugin.
https://swiftmailer.symfony.com/docs/plugins.html#logger-plugin
It is likely to be already installed so all you need to do is follow the instructions in here and if you run the logger it will give you reasons why the email is failing.
While Toni's solution works it requires fiddling around with vendor source which is not ideal. You can also set the stream options programmatically in your code, where you use the swiftmailer $mailer instance, e.g.
$transport = $mailer->getTransport();
if($transport instanceof \Swift_Transport_EsmtpTransport){
$transport->setStreamOptions([
'ssl' => ['allow_self_signed' => true, 'verify_peer' => false, 'verify_peer_name' => false]
]);
}

Magento Paypal Error - persistent Sandbox URL in payment_paypal_direct.log

HELP! - I am trying to take a PayPal Payments Pro (Magento 1.8.1) API live and I am getting the following error:
exception 'Exception' with message 'PayPal NVP CURL connection error #35:
error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure'
in <my_root_folders>/app/code/core/Mage/Paypal/Model/Api/Nvp.php:986
In the payment_paypal_direct.log file I have the following for every error:
2014-11-08T02:12:36+00:00 DEBUG (7): Array
(
[url] => https://api-3t.sandbox.paypal.com/nvp
[DoDirectPayment] => Array
(
No matter how I set the various flags for sandbox mode, my errors all show the sandbox URL for the API. I have even double checked the paypal/wpp/sandbox_flag in the core_config table in the db and it is flipping from 0 to 1 when I change the configuration in Magento's admin.
Has anyone experienced this persistent sandbox URL?
Sandbox Mode = OFF
SSL Verification = Disabled (have tried it enabled too, no difference)
all caching is disabled (I clear cache often just in case)
I reindex entire site frequently
There were two issues effecting my website:
Our server was not configured in response to the POODLE vulnerability and PayPal was rejecting the server connection.
Sandbox setting was enabled for a child "Configuration Scope" and edits made to the "Default Config" (the parent/master config) were being overridden.
Hopefully this may help someone.
In addition to the above answer you may configure your server and disable SSLv3 by editing you Apache's httpd.conf and adding the following code:
SSLHonorCipherOrder On
SSLProtocol -All +TLSv1
You may also do this via WHM if you have a VPS or Dedicated Server:
Go to Service Configuration -> Apache Configuration -> Include Editor -> Pre Main Include
and add the above two lines.

Nginx will not stop rewriting

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.

Resources