Connected the podio file upload to attach images to item. Started getting the "Connection to Podio API failed: [92]" error. Before everything worked fine. Is it a problem on my side or on Podio's side?
Podio does not define CURLOPT_HTTP_VERSION variable in it's curl requests and therefore leaving the decision to curl client to decide.
in your case I guess cURL chooses HTTP2 version for unknown reasons ( might be due to SSL implementation ) and according to my experience with Podio, PodioFile::upload breaks when HTTP2 is used.
To solve the issue you would need to force Podio to use HTTP1.1 , This should fix your issue :
inside lib/Podio.php look for curl_setopt(self::$ch,CURLOPT_RETURNTRANSFER, true);
just beneath it add curl_setopt(self::$ch, CURLOPT_HTTP_VERSION, CURL_HTTP_VERSION_1_1);
Tip: do consider upgrading to the latest version of the package podio-community/podio-php before modifying the code and Good luck.
Related
I am currently testing the changes for version 4.0 of the protocol for PSD2 using Direct Integration.
I am running under Visual Studio using a localhost website address.
When calling the SagePay payment endpoint with ThreeDSNotificationURL set as a localhost address (http://localhost:15536/Payments/ThreeDResponse) I receive the following error '3228 : The ThreeDSNotificationURL field format is invalid.'
If I change this field to a fully qualified domain (http://www.google.com) I no longer receive the error, but can't complete my testing.
Using localhost for the termurl in version 3.0 of the protocol works as expected.
I was attempting to work locally like your self and receiving the same issue. After speaking with support they confirmed that they will not accept "localhost". Also, the documentation suggests that HTTPS is a requirement, so this might also be a blocking factor.
I think someone suggested using ngrok as a means of tunneling external requests into your localhost, which is a good method to continue development locally whilst also being visible externally to services like SagePay.
Once I got passed the above issue, I got several more errors for other missing required fields as listed here; https://www.sagepay.co.uk/support/38/psd2-under-direct-integration (note that if BrowserJavascriptEnabled is true all conditional fields are then required)
Did you URL encode the ThreeDSNotificationURL in your post?
I send it like that and it is ok:
sb.Append(HttpUtility.UrlEncode("https://www.clientdomian.com/ac/ThreeDSNotificationURL.aspx"));
I run the site on my local IIS for development.
I recently had this issue and I wanted to document it here, because searching for this issue gives very little in terms of results.
I was getting this error code when i switched my Opayo/SagePay extension (MageNest SagePay for Magento) to 3ds2.
As it turns out, the full URL wasn't being sent. It was trying to send sagepay/direct/postBack?form_key=HZuYxgiEq9w2CNFB and NOT https://www.example.com/sagepay/direct/postBack?form_key=HZuYxgiEq9w2CNFB. It's partly my fault because there was a domain field in the config which was empty (it's not like the domain can't be retrieved automatically, huh) and partly the vendors fault because it was very badly documented.
So while this is a different problem for a different platform, I hope this helps someone.
I have developed a Laravel API for my SPA. Sometimes I'm using query parameters to provide data to the API. But if there's an # sign inside the API URL the server responds with a 500 - Internal Server Error. Example...
Here I will get the error:
http://www.mywebsite.com/api/user/login?name=example.user#gmail.de&password=changeMe
Here everything works fine:
http://www.mywebsite.com/api/user/login?name=exampleUser&password=changeMe
Locally both ways are working. But when tested on the live server the error occurred.
Does anyone know what the problem is? I'm using an Apache Server with Plesk, if it helps. ;-)
Ok, I've solved the problem. If someone else has the same error:
Just set the server-sides default charset to utf-8 fixed that problem!
I am running a WordPress on an Azure Web app connecting to a MySQL server on a different Windows server. When loading the mentioned page in Chrome, it shows 2 popups 403 & Forbidden. Checking the console throws this error - ecbcc.js:2 POST /wp-admin/admin-ajax.php 403 (Forbidden)
This works fine on FireFox & IE but not on Chrome. Any ideas why?
This is because of your cache. Minified version of JS is causing the issue in chrome browser. Check or purge the cache and check for the permissions applied to cached files as well.
I faced the same issue but it took a long time for me to fix it. Because my solution was not caused by common things like cache, .htaccess, files permissions, etc. I apply all the possible solutions as described here. When nothing worked for me, then I talked with my hosting provider and the issue was on their side. Actually, the server has black-listed my IP.
Below is the reply from the support of my hosting provider:
After checking it, it looks like the issue is caused by trigger
ModSecurity rules.
ModSecurity is an Apache module that works as a web application
firewall. It blocks known exploits and provides protection from a
range of attacks against web applications. However, sometimes,
mod_security may incorrectly determine that a certain request is
malicious, while it is actually legitimate. In such a situation, we
can whitelist the triggered mod_security rule on the server, so that
you can bypass the block.
In order to properly investigate, we need you to share your IP address
with us. You can copy it from here: https://ip.web-hosting.com/
Looking forward to your response.
This error can appear for more than one reason. Except for the accepted answer, if you are using a shared hosting solution as a server then it would be best to contact the support of the service. Also if you use Plesk or Cpanel you can check the server logs to see if there is any false positive rule that from mod_security that catches the error. Then you can find the error that could look something like that:
ModSecurity: Warning. Match of "test file" against "REQUEST_FILENAME" required. [file "/etc/httpd/conf/modsecurity.d/rules/custom/006_i360_4_custom.conf"] [line "264"] [id "77140992"]
You can apply the ID on your firewall exclusion list (if this is provided by your hosting service) and then the server will not block the request anymore.
IMPORTANT: If you are not sure what you are doing, ask your hosting provider for support. Experimenting on live servers/sites is not the best option and I would strongly recommend avoiding it.
I have a node.js server using socket.io. The idea is to allow two different html files to communicate information to each other through this server. All was well with socket.io ver0.9.16 until ver 1.0 came out. Now, I receive a few errors on both the client and server side, the most apparent (to me, since I am new to this) is the ERR_NAME_NOT_RESOLVED error that I find when I start up the locally hosted server.js file and attempt to connect to it through the client html.
When I open the console in Google Chrome, I find this error which prints again to the console every second or so:
GET http://file/socket.io/?EIO=2&transport=polling&t=1406247171961-0 net::ERR_NAME_NOT_RESOLVED
What follows are snippets of places where I may have problems in my html and server.js files as well as in a js file that is used by my html file to connect to the server.
index.html
I think this bit of code gets the socket.io client code from the localhost server. This is the first place where I may think that I have a problem
<script src="http://localhost:4000/socket.io/socket.io.js "></script>
In addition, the following is where I import my index.js file which is used to connect to the server
<script type="text/javascript" src="scriptsTeacher.js" ></script>
-
server.js
This code (according to my sources) should set up a server on the localhost with port 4000 to which clients can connect and send/receive information
var io;
io = require('socket.io').listen(4000);
io.on('connection', function(socket)
{
console.log("user connected");
});
-
index.js
This code is used by the index.html which has it connect to a server listening on port 4000 using socket.io.
var socket = io.connect('localhost:4000');
-
Currently, there are two blatant errors that I can find. They are probably not the root of the problem, but they are as far as my limited debugging experience can take me.
ERR_NAME_NOT_RESOLVED: (NOTE: I have looked at socket.io ERR_NAME_NOT_RESOLVED and it was not entirely useful since that user had a typo by using http:\\ instead of http://). As stated before, when opening index.html in Google Chrome and accessing the console, I receive multiple ERR_NAME_NOT_RESOLVED errors.
There is no "Welcome to socket.io" message when accessing localhost:4000 I am certain that there should be such a message. Note that there is no 404 error, when I start up the server, I can access that webpage, but it is blank. If the server is not running, then I do get a "Webpage not found" message.
My question is this: Is there anything that I am not doing but should? As I said, I am new to this, and after some hunting around on the internet, I have a suspicion that there is some server (HTTP, Express, Express 3/4?) that I am not establishing. However, it is of note that the code worked as is in ver0.9.16 (using the .socket() and .listen() functions which were removed from my code for migration to ver1.0). If there is any information that is missing, I will do my best to provide it as soon as possible.
-
I am using:
Macintosh OS 10.6.8
Google Chrome version 36.0.1985.125
socket.io ver1.0
node.js v0.10.29
The address in the error is wrong (assuming you haven't set up a local name resolver).
The address in the error begins with:
file
When it should begin with something like:
localhost:4000
The issue is probably in some of the js-config files for the web application (not the server). Or maybe you're trying to access the file locally (eg. just open the html-file in the browser) instead of typing the address localhost:4000.
I had the same problem that running file in the browser:
eg.
"file:///C:/apppath/index.html"
Try running from the server
eg.
"http://your.app:4000/index.html"
I had the same issue - I wasn't able to connect to my socket.io server through my client on the same machine on mac. I disabled the firewall and it resolved the issue. I guess we could use xhr-polling instead and overcome this.
Vikram
I ran into a similar problem, but the solution to my problem had nothing to do with CORS. In my case, which is a Cordova 4.0.0 app using socket.io, I was using an incorrect URL for the socket server. I was using a socket server URL like this:
//socketserver.example.com:8000
This worked fine in the desktop Chrome browser, but in the Cordova webview on the phone or emulator there were many errors regarding failed GET and POST requests to a URL that started with
http://file/socket.io
The correct URL in my case turned out to be:
http://socketserver.example.com:8000
Note the complete scheme at the beginning of the URL.
I have a site running in Hostgator shared-hosting account with Google Checkout (GC) working since v1.2 - when the site first gone live, the GC works out-of-the-box.
Recently I moved the site to a VPS server and GC stopped working with this error:
Google Checkout: Invalid response from Google Checkout server
I thought it couldn’t be an issue with Magento’s Google Checkout integration but the new VPS server or maybe SSL cert that require further testing, so I moved the site back to the shared server (the GC starts working again!), and then setup a test site with a valid SSL cert, a working GC account.
3 weeks had passed still GC wouldn’t work in the VPS server; I have tried/searched/tested all possibilities along with the help from Hostgator’s support, and we have exhausted all options to a point that we believe it has nothing to do with SSL cert setup nor the server configuration.
From the above error and the log from "var/log/payment_googlecheckout" I reckon it couldn’t redirect to checkout.google.com/schema/2
<order-processing-support>
<request-initial-auth-details>true</request-initial-auth-details>
</order-processing-support>
</checkout-shopping-cart>
[dir] => out
It seems a number of people had experienced the same error before but no one seems to be able to find the cause, and I am starting to think it’s a bug lies on Magento’s Google Checkout module.
If you had this issue before and had it solved, please share. Thanks!
This person seems to have had a similar problem and it was due to an issue with their cURL installation. Have you compared versions from your shared hosting with your VPS? I'd compare: PHP versions, PHP extension versions, php.ini settings, and versions of cURL itself.
If none of that bring about any results, open up app/code/core/Mage/GoogleCheckout/Model/Api/Xml/Abstract.php and modify the _call() method like this:
// app/code/core/Mage/GoogleCheckout/Model/Api/Xml/Abstract.php
public function _call($xml)
{
// ... snip ...
$result = #simplexml_load_string($response);
if (!$result) {
// Add this...
Mage::log(var_export($response, true), null, 'google_checkout_debug.log', true);
// ... end
$result = simplexml_load_string('<error><error-message>Invalid response from Google Checkout server</error-message></error>');
}
With this, you will have the exact response from Google logged to var/log/google_checkout_debug.log. Use this to debug what might be going wrong (perhaps there is another error message embedded in the response).
Just remember to remove the code when you're done!