Paypal IPN over HTTP not working - paypal

I am trying to connect to the PayPal IPN over regular HTTP for testing purposes and I cant get my PHP script to connect. I dont have an ssl cert installed so any attempt at using ssl with port 443 fails. Here is my attempt to connect over HTTP:
$fp = fsockopen('www.sandbox.paypal.com', 80, $errno, $errstr, 30);
The response ends up coming back like so:
HTTP/1.0 302 Found
Location: https://www.sandbox.paypal.com
Server: BigIP
Connection: close
Content-Length: 0
I have read that with the new SHA-256 requirements, PayPal will still allow connection over http so am I doing something wrong or is my information incorrect?

PayPal has stopped acceptting HTTP 1.0 on IPN endpoint, you should change HTTP/1.0 to HTTP/1.1

Related

spring gateway always returns 301, how to continue processing

This is clarification of the OP
I have a spring gateway that uses eureka server to route requests to registered spring boot eureka clients.
What I am seeing is that every request results in a 301 redirect containing a Location header. It seems that because the request is received on https://my-api.io/payment/payment-intent spring-gateway looks it up based upon these rules:
server.forward-headers-strategy=framework
feign.hystrix.enabled=false
spring.cloud.config.discovery.enabled = true
....
spring.cloud.gateway.routes[11].id=orders-service
spring.cloud.gateway.routes[11].uri=lb://orders-service
spring.cloud.gateway.routes[11].predicates[0]=Path=/payment/**,/order/**
spring.cloud.gateway.routes[11].predicates[1]=Method=GET, POST
spring.cloud.gateway.routes[11].predicates[2]=Header=APIKEY, (.*)
spring.cloud.gateway.routes[11].filters[0]=AuthorizationHeaderFilter
## these next two apparently have no impact
spring.cloud.gateway.routes[11].filters[1]=RewritePath=/(?<segment>.*),/payment/$\{segment},/order/$\{segment}
spring.cloud.gateway.routes[11].filters[2]=RedirectTo=301, lb://orders-service
And then returns the Response Headers:
Server: awselb/2.0
Date: Tue, 24 Jan 2023 17:58:36 GMT
Content-Type: text/html
Content-Length: 134
Connection: keep-alive
Location: https://my-api.io:8081/payment/payment-intent
If I enable "follow redirects" in Postman or curl, then it works fine. But that won't work in a mobile app, so I really need to have spring-gateway just route the call on first pass. I don't know if this is because the routes.uri defines the as coming from the load-balancer (since ports are dynamic and there are likely multiple instances) url so it seems like a different url or what.
I am desperately trying to find a way so that the request is just processed and not bounced back with a 301.
Now that I have context around the issue it turns out the issue was not with Spring Gateway since its just a passthru (after some validation). Thanks to spencergibb I was able to rule out gateway and realize it was a forwarding issue in AWS.

REST client gives error, while HTTP looks fine

My interface (an MKR Wifi 1010 Arduino) runs a very simple REST API, but when testing it with Mulesoft's Advanced Rest Client, I get this error:
The requested URL can't be reached
The service might be temporarily down or it may have moved permanently to a new web address.
The response status "0" is not allowed. See HTTP spec for more details: https://tools.ietf.org/html/rfc2616#section-6.1.1
When I check it with telnet though, it looks fine:
[bf#localhost ~]$ telnet 192.168.178.185 80
Trying 192.168.178.185...
Connected to 192.168.178.185.
Escape character is '^]'.
GET /api/gps HTTP/1.1
Host: 192.168.178.185
HTTP/1.1 200 OK
Connection: close
Content-Length: 9
Content-Type: application/json
"Success"
Connection closed by foreign host.
My question now is, is the rest client broken, or am I missing something in my reply? Of course I want any REST client to be able to process my interface correctly.

Connect with PayPal - invalid_client Client Authentication failed with sandbox

I am implementing Connect With PayPal on my vuejs application following this documentation, but I keep getting an invalid_client error when I try to get the access token.
I have created the sandbox REST app on my account and I've enabled "Connect With PayPal". I have also set my return url in the app settings. To build the button I used the button builder and specified my client id, return url and set auth end point as "sandbox". I have added the external script in my index.html and the paypal.use() method in my component.
So now I have the connect button on my interface and when I click on it I am redirected to https://www.sandbox.paypal.com/connect/ which is normal. I can login with my two default sandbox accounts, then I am redirected to the return url that I specified in my app settings, with two url parameters : "code" and "scope" as described in the documentation.
However I am stuck at this step where I need to get an access token for the connected user.
I have tried to run this curl request with my client id / secret and the code from the url but as I said before it doesn't work and I am getting this error everytime :
HTTP/1.1 401 Unauthorized
Cache-Control: max-age=0, no-cache, no-store, must-revalidate
Content-Length: 77
Content-Type: application/json
Date: Wed, 08 Jul 2020 22:01:03 GMT
Paypal-Debug-Id: 8abaa5940b688
X-Paypal-Token-Service: IAAS
{
"error":"invalid_client",
"error_description":"Client Authentication failed"
}
I have checked my client id and secret multiple times and I can't understand why this is not working, does anyone have an idea ?
Solution for this type of error is to verify and validate everything is being sent correctly in the request, and properly encoded
curl's -u flag makes username:password header authentication easier
curl's -v flag will give visibility about the actual communication, to validate

301 moved permanently with socket.http

In python (and my browser), I am able to send a request to https://www.devrant.com/api/devrant/rants?app=3&sort=algo&limit=10&skip=0 and get a response, as expected, but with Lua, I get HTTP/1.1 301 Moved Permanently. Here is what I have tried so far:
http = require("socket.http");
print(http.request("https://www.devrant.com/api/devrant/rants?app=3&sort=algo&limit=10&skip=0")
which outputs an HTTP error page (moved permanently) and
301 table: 0x8f32470 http/1.1 301 Moved Permanently
the table's contents are:
location https://www.devrant.com/api/devrant/rants?app=3&sort=algo&limit=10&skip=0
content-type text/html
server nginx/1.10.0 (Ubuntu)
content-length 194
connection close
date Mon, 11 Dec 2017 01:41:35
Why does only Lua get this error? If I request to google, I get the google home page HTML. If I request to status.mojang.com, I get the mojang server statuses in a JSON response string, so the socket is functional for certain.
It's because you are using socket.http to request a page from https URL; since socket.http doesn't handle https, it sends the request to port 80, which gets forwarded to https URL, but socket library doesn't follow that redirect, as it doesn't "know" what to do with https, so it simply reports 301.
You need to install and use luasec and use ssl.https instead of socket.http, which will make it work.

Connecting to Gmail SMTP via socket returns different responses per server

I am trying to understand why opening a socket to Gmail's server via SSL provides different responses for different servers. This is stopping me from connecting to Gmail for sending out emails.
Below is a very simple script:
<?php
$smtp_connect = fsockopen('ssl://smtp.googlemail.com', 465,
$errno,
$errstr,
300);
var_dump(fgets($smtp_connect, 512));
?>
On server 1 [no ssl cert installed], the output of the above code is: string(57) "220 smtp.googlemail.com ESMTP s89sm726209qkl.44 - gsmtp
"
On server 2 [ssl cert installed], the output of the above code is: string(71) "220-mycompany.pro.com ESMTP Exim 4.87 #1 Wed, 26 Oct 2016 07:42:49 -0400
"
Can anyone explain why this happens, and how can I make server 2 have the same behavior as server 1?
Update: I have also tried smtp.gmail.com, the output is same as using smtp.googlemail.com.
The line you get the the SMTP welcome message. It is perfectly normal that different servers give a different welcome message. It is even normal that the response to commands you send is different. This means that when communicating with an SMTP server you should not assume fixed strings as response but implement proper parsing of SMTP. See the SMTP standard (RFC 2821) for details about this protocol.