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.
Related
after upgrade to ELK 8.2.2 I can not access KIBANA from Chrome ( Chrome is up to dateVersion 105.0.5195.102 (Official Build) (64-bit) ) , it is showing me the message: "Please, upgrade your browser" , anybody has an idea how to solve this?
( I dont have this problem from Edge from same computer ... )
Kibana shows this message if a browser doesn't support content-security-policy 305.
Do you have a proxy in front of Kibana that could affect set CSP headers?
Do you have any error messages in the browser console? Try opening your browser's dev tools and report what you see. In the normal case with Chrome you should see:
Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'unsafe-eval' 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-dfwkrmf3eoeeUSOe5V/dede2c+yeadce32Oi/3fqhGsU7BE='), or a nonce ('nonce-...') is required to enable inline execution.
I am using subfission/cas for my application. I have followed all installation steps. I am using windows, if that matters. More precisely, I have configured the following:
I ran the following in my terminal
composer require "subfission/cas" "dev-master"
I configured my Kernel.php accordingly, adding the following:
'cas.auth' => 'Subfission\Cas\Middleware\CASAuth',
'cas.guest' => 'Subfission\Cas\Middleware\RedirectCASAuthenticated',
I ran the following command:
php artisan vendor:publish
I also set up my cas server in my cas.php config file:
'cas_hostname' => env('CAS_HOSTNAME', 'cas.myserver.me'),
'cas_real_hosts' => env('CAS_REAL_HOSTS', 'cas.myserver.me'),
What I want is a middleware for all my routes, so I added the following route rule in my routes:
Route::middleware(['cas.auth'])->group(function ()
{
Route::get('/', function ()
{
return view('welcome');
});
});
Basically, I want to redirect everyone who is not logged in to the login page whenever I access the main page (for now, I will add more routes in the future). What happens is that the users are redirected to the login page when they are not logged in, but after the login I receive the following error:
ErrorException (E_WARNING)
DOMDocument::loadXML(): Opening and ending tag mismatch: hr line 1 and body in Entity, line: 1
No matter what view I'm redirecting the user to. I tried the default welcome page as well as an empty view, but I still get the same error.
EDIT: I have used the dev-master branch from subfission/cas for the above error and after switching to 2.1.1, I get a different error:
session_name(): Cannot change session name when headers already sent
EDIT 2: I did some more digging and I enabled internal errors in my cas client class with:
libxml_use_internal_errors(true);
And now I get the following:
Authentication failure: SA not validated Reason: bad response from the CAS server
And the cas response is:
The thing is that I use the same cas server for another 2 projects and it works well for those (but those aren't laravel projects.
I know it's been a while, but for anyone else having issues like this, the issue is the protocol selected for which your web service communicates with your CAS(Central Authentication Service) provider. There are two main protocols used for SSO/CAS in this package:
SAML(Security Assertion Markup Language) version 1.1 & 2
CAS Protocol v3.0
[Confusingly enough, CAS protocol shares the same namespace as the service.]
The idea is to match the protocol and version with your identity provider. It sounds like your provider is using CASv3.0, which is why disabling SAML worked.
Also, if you enable debug mode, you will see further error details in your log file to help your troubleshoot.
Best of luck!
I managed to solve the issue by disabling the SAML in the cas configure file:
'cas_enable_saml' => env('CAS_ENABLE_SAML', true),
change to
'cas_enable_saml' => env('CAS_ENABLE_SAML', false),
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.
I'm trying to enable the Authorize.net DPM (Direct Post Method) on a Magento 1.11.1 production site. My test site (also Magento 1.11.1.0) works fine because the site is not secure (frontend SSL), but the live site gets an error. Turns out the reply_url sent to Authorize.net (x_reply_url) is being sent as non-ssl (e.g. http://mysite.com/authorizenet/directpost_payment/response as a POST). However, this gets a 500 error because Magento is set to require SSL on the frontend. If I send a test post using (https://mysite.com/authorizenet/directpost_payment/response as a POST) it gets a 200 response. I'm looking at this by having turned on Debug in the DPM payment method and then viewing the file var/log/payment_authorizenet_directpost.log.
So I'm looking through all the code in app/code/core/Mage/Authorizenet and have yet to pull out a section of code where it might be getting this non-ssl URL. And of course then answer the question of "Why isn't it pulling a secure URL instead?".
It looks like it originates possibly in the placeAction method of controllers/Directpost/PaymentController.php.
I was hoping I might get some informed insight here as to whether I'm on the right track and how best to log or var_dump the appropriate variables (on my test site) to verify any changes.
Resolved. This appears to be a bug in the code for the authorize.net directpost method.
Modified file: app/code/core/Mage/Authorizenet/Model/Directpost.php
Method: getRelayUrl
Old code:
return Mage::app()->getStore($storeId)->getBaseUrl(Mage_Core_Model_Store::URL_TYPE_LINK) . 'authorizenet/directpost_payment/response';
New code:
if(Mage::app()->getStore($storeId)->isCurrentlySecure()) {
return rtrim(Mage::getUrl('authorizenet/directpost', array('_secure' => true)),"/") . '_payment/response';
} else {
return Mage::app()->getStore($storeId)->getBaseUrl(Mage_Core_Model_Store::URL_TYPE_LINK) . 'authorizenet/directpost_payment/response';
}
This was in Magento Pro 1.11.1.0 (same code as Magento EE 1.11.1.0). I have not yet received access to any newer versions of Magento EE in order to see if this has been resolved in 1.12 or higher.
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.