I am using node.js bodyparser to get urlencoded string and manipulating the string to simulate a querystring with cmd=_notify-validate preceded. Whenever an IPN response is sent, I keep getting INVALID message. I am suspecting that this might have to do with encoding/decoding issue. The code below is the body part of Paypal INVALID message, that is the querystring I manipulated. Can someone verify if this is the right format to send IPN response? If not, how should I format the string?
body: 'cmd=_notify-validate&payment_type=instant&payment_date=Sat Oct 01 2016 10:15:51 GMT 0900 (%uB300%uD55C%uBBFC%uAD6D %uD45C%uC900%uC2DC)&payment_status=Completed&address_status=confirmed&payer_status=verified&first_name=John&last_name=Smith&payer_email=buyer#paypalsandbox.com&payer_id=TESTBUYERID01&address_name=John Smith&address_country=United States&address_country_code=US&address_zip=95131&address_state=CA&address_city=San Jose&address_street=123 any street&business=seller#paypalsandbox.com&receiver_email=seller#paypalsandbox.com&receiver_id=seller#paypalsandbox.com&residence_country=US&item_name1=something&item_number1=AK-1234&tax=2.02&mc_currency=USD&mc_fee=0.44&mc_gross=12.34&mc_gross_1=12.34&mc_handling=2.06&mc_handling1=1.67&mc_shipping=3.02&mc_shipping1=1.02&txn_type=cart&txn_id=939521005¬ify_version=2.1&custom=xyz123&invoice=abc1234&test_ipn=1&verify_sign=AFcWxV21C7fd0v3bYYYRCpSSRl31ACcRGK9bZMBhEskX.HORa2EqEcwh',
I ran into the same issue today.
My initial solution was to remove the date field from IPN Simulator, which made it work. So i started to investigate in the Date field.
The + sign after GMT (as you can see in your formatted string is not there).
This has to do with PayPal not encoding the '+' correctly and receiving server is translating this as a white space.
Solution:
So if i change this on my server and replace the introduced white space with a + sign instead, everything works fine. (Ugly solution indeed)
Think this is on PayPal's side to fix, as the translation of a + to white space is correct, so they need to encode the data sent correctly.
Related
In a web application I'm running, I suddenly started getting these odd tokens containing a huge string of periods at the end.
This happens even when I bypass my application code and call the function from the Google OAuth library directly.
Here's an example token:
ya29.c.Kp8BCgi0lxWtUt-_[Normal JWT stuff, redacted for security]yVvGk...............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
Could this be an upstream issue with Google OAuth? Has anyone else seen tokens like this?
Same here, it suddenly started. Had to remove them from the received token, now it works again.
I found the problem is on the Google server-side. It's actually returning the JWT with the trailing "." chars. I'm updating Chilkat to automatically trim the trailing "." chars if found before returning the JWT.
Same with me. And it leads to Error: Invalid login: 555 5.5.2 Syntax error for my nodeMailer application.
Solved with the following code:
tokensCache.access_token = tokensCache.access_token.replace(/\.+$/, '');
The problem is that clients should be able to handle the token sizes declared in https://developers.google.com/identity/protocols/oauth2#size. Also, tokens must be opaque to clients, meaning, assuming token start with "ya29.blabla" is wrong. Instead, the token must be parsed as a string encoded Web-safe base64 which standard is https://www.base64encode.org/enc/safe/
In fact the dots make no difference. You can still use the access_token to call apis. If you get an error response, you'd better check a further reason. Do you set the correct scope (https://developers.google.com/identity/protocols/oauth2/scopes)? Does the
permission of the service account is right?
I have a single page app, which has URLs like http://example.com/#!something/something/. The problem is that when I send email containing link to such url, hotmail users get them wrong (I have noticed it only in hotmail, everyone else is good).
The ! is encoded to %21 which makes the url wrong: http://example.com/#%21something/something/
Any ideas what can be done except rewriting my app :-). I am using swiftmailer to send email, but I highly doubt that this is relevant.
According to RFC3986, the "!" character is valid in the fragment (#...) component of URIs, so it should not get encoded using percent-encoding. In this sense, this seems to be an outlook.com bug.
One workaround is to use plain-text emails: based on my tests, outlook.com encodes !'s HTML email links only and plain-text emails are safe.
The real solution, however, is to do your own normalization in the client-side code. URL cracking and normalization is a really tricky business, so I'd expect issues with other email clients, too. Running JavaScript decodeUriComponent() against window.location.hash should give you the unencoded "#!/something/something" version regardless whether the exclamation mark was encoded or not. I understand this calls for modifying the web application that you wanted to avoid, but to my best knowledge this is the way to go.
I recently started using SAML for my website's authentication which is working great except 1 particular problem.
Some users (all of them are in the same domain group policy if that helps) get an error while loading the website :
A potentially dangerous Request.Form value was detected from the client
I know this error doesn't occur because of the website's code since it always worked and still works fine on 95% of the users.
I've done some reading on SAML and it seems the SAML request is transmitted via the URL by encoding an XML-like message :
<samlp:AuthnRequest>
to get this base64-encoded message :
https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=fZFfa8IwFMXfBb9DyXvaJtZ1BqsURRC2
Mabbw95ivc5Am3TJrXPffmmLY3%2FA15Pzuyf33On8XJXBCaxTRmeEhTEJQBdmr%2FRbRp63K3pL5rPhYOpkVdY
ib%2FCon%2BC9AYfDQRB4WDvRvWWksVoY6ZQTWlbgBBZik9%2FfCR7GorYGTWFK8pu6DknnwKL%2FWEetlxmR8s
BHbHJDWZqOKGdsRJM0kfQAjCUJ43KX8s78ctnIz%2Blp5xpYa4dSo1fjOKGM03i8jSeCMzGevHa2%2FBK5MNo1F
dgN2JMqPLmHc0b6WTmiVbsGoTf5qv66Zq2t60x0wXZ2RKydiCJXh3CWVV1CWJgqanfl0%2Bin8xutxYOvZL18NK
UqPlvZR5el%2BVhYkAgZQdsA6fWVsZXE63W2itrTQ2cVaKV2CjSSqL1v9P%2FAXv4C
Now, If the XML-like message was encoded, there wouldn't be a problem transmitting a few characters over the URL. I suspect the problem is that the XML-like message is being sent without being encoded resulting in illegal characters ('<', '>') in the URL.
NOTE : The first time they open the website is successful, the error occurs only after the first time. If they clear the cookies they can open the website. (again, only once, then the error occurs until they clear the cookies again)
Does anyone has any idea what could be the cause of the message not be encoded for certain users/computers? or how can I know which URL is the SAML generating (so I can find out if the XML is really not being encoded)
The problem was that the page address was :
https://ServerName.ServerDomain/AppName
and some users were using this address :
https://ServerName/AppName
This started as a question, but in the process of posting this question, I solved it. So now, this is an FYI post...
==========
At first, whenever I tried to post to this URL, I would get an error message:
https:// www.dwolla.com/oauth/rest/register --> Bad URL
There is no operation listening for
http:// phx-dwol-web1.cloudworks.com/oauth/rest/register, but there is
an operation listening for
http:// www.dwolla.com/oauth/rest/register/, so you are being
redirected there.
I fixed by appending the auth values to the post URL:
https://www.dwolla.com/oauth/rest/register/?client_id={id}&client_secret={secret}
--> Good URL
Then, I was having trouble with request formatting. To fix this, make sure that you post JSON in the BODY of the post. Do NOT append to the URL, or submit as form fields.
Lastly, when I finally got a proper response from the Dwolla API, I was getting this error:
"New user must accept terms of service."
This is because the Dwolla API is CASE SENSITIVE, so the "ACCEPTTERMS" parameter in the JSON body must be submitted as "acceptTerms" in order for it to work.
Here is the documentation I am referencing:
http://developers.dwolla.com/dev/docs/register
Happy coding!
Thanks for the answer...it ultimately led to me solving my problem as well.
For completeness, I encountered this error when sending a poorly formed request to the api, where I had left off the trailing / before the get parameter {oauth_token}.
INCORRECT:
http://www.dwolla.com/oauth/rest/users?oauth_token={oauth_token}
CORRECT:
http://www.dwolla.com/oauth/rest/users/?oauth_token={oauth_token}
This is sort of a follow-up to Why are my cookies containing JSON occasionally malformed, which we have resolved.
I have a 3-value cookie, and we're url encoding the main value. The other two values are a timestamp and a hash. It looks like this in our response header:
foo=d=634027688530013385&v=%7b%22HasDog%22%3afalse%2c%22Greeting%22%3anull%2c%22RecentRecipes%22%3a%5b%5d%2c%22Remember%22%3afalse%7d&h=ARv5QGf4Cnftc4tFaPoy/VH8Pbo=; path=/; HttpOnly
In our logs, we see cases where we can't parse the three values correctly because the entire cookie is now encoded:
Cookie looks mangled: d%3D634027653097874122%26v%3D%7B%22HasAcceptedTerms%22%3Afalse%2C%22RecipeBoxCount%22%3A0%2C%22Remember%22%3Afalse%7D%26h%3DR85mJ%2FTdA6yrVe5pVCVpfG2jumM%3D
Unfortunately, we're not capturing the user agent to see if this is related to a specific browser.
I have several options to fix this. I just think the behavior is odd enough to warrant a question.
This may not be an answer but....
This is interesting and warrants a deeper look.
I would like to see a public facing test page that shows red or green with the cookie in bold text and then run it through http://browsercam.com.
I did this when I thought I had found a bug in mozilla's native json support. turns out I was right.
Get your testpage working for sure for sure before you fill out the form for a free trial (200 shots), set the resolution to 640/480 and select all browsers/platform, 182 distinct combinations, set a delay to allow the redirection to set the cookie and track down the culprit.
Or take the time and get on http://testswarm.com/.
Please do follow up on this.