I have set up mozpay in my app. When I send the signed jwt with the post-back URL to the app, and then the app uses it with mozpay, during simulation, the post-back URL gets hit 6 times. I wanted to know if that's intended. If so i can work around it, but if its not intended i would rather fix that problem.
Is it possible that the 6 post-backs only occur during simulation?
Also is this any different in the charge-back URL?
Is there a setting that I can set in the signed jwt to change this?
If there is some documentation on this, I haven't been able to find it, and I would greatly appreciate a link.
What you describe is expected behavior. Since your postback URL was not responding correctly, Mozilla's server retried the post 5 additional times before giving up. As you mention, when you fixed the transaction response you no longer saw so many requests.
There was an answer here, but I dont see it anymore. The answer was fairly correct.
We were sending back "webpay: {transactionID}" what we didnt realize is that {transactionID} includes the text "webpay:" So all we had to do was send back "{transactionID}" instead.
I would set as the answer the person who posted, but i no longer see the post. Thanks.
Related
For the past several months I have a native iOS application that uses the embedded signing API to generate an embedded signing URL. My parameter for returnUrl uses a URL with a custom scheme, say, for example, foo. I was using this custom scheme to intercept when the signing is complete and transition to another part of my application. This is now broken and get the following response:
{
"errorCode": "INVALID_REQUEST_PARAMETER",
"message": "The request contained at least one invalid parameter. 'returnUrl' parameter must be an absolute URL."
}
When I try using the schemes http or https the request works just fine. For example:
https://docusign/complete works
http://docusign/complete works
foo://docusign/complete broken
bar://docusign/complete broken
This is in the dev sandbox and I am not aware of this being broken in production. Is this change intentional or a bug? If intentional, why are you breaking the behavior of the client being able to choose their own URL for redirection? Using this custom scheme, I am able to unequivocally determine that my application is responding to a completion event, without having to introspect any other parts of the URL.
This breaking change is a bug that was introduced by mistake. Thank you for your report on it. I'm escalating it.
This issue is now tracked internally as DocuSign IM-32736
Please contact DocuSign customer support and ask them to add your contact information to IM-32736. Thank you.
This bug has now been declared as a release blocker. It will not go to production. The bug is being fixed and tested. It will probably arrive on demo.docusign.net sometime on Friday. I will update this answer as more progress is made.
Update
The bug has been fixed and the fix has been pushed to demo.docusign.net.
Please advise if this is still an issue. Thank you again for reporting it.
I am having a lot of troubles getting verification emails to work, when a user signs up with parse-server (using MailGun & Heroku).
The verification link sent to the user has this form:
https://myapp.herokuapp.com/apps/.............
but it does not work/
I get this, when clicking it:
Cannot GET /apps/.......
And even if I type only this in the web browser:
https://myapp.herokuapp.com/apps/
I still get this:
Cannot GET /apps/
At one point I was suspecting I could have made some confusion between parse-server-mailgun and parse-server-simple-mailgun-adapter (I am in fact not fully aware of the difference between the two), so I tried both but I still got the same kind of error.
Since, I can reach the point where a user account is actually created and a verification email is sent, I suppose I must have only made some detail mistake in my settings; but I can't see where. Any help or relevant hint from some experienced person would be highly apreciated.
In case someone think I should share some code because the explanation above is not enough, please tell me what you need to know to clarifly my point. And I will provide the necessary information.
You should see your publicServerURL to https://myapp.heroku.com/parse
The _actions_on_google_ context stopped appearing in the contexts section, and I think this may be a clue to what's gone wrong.
It's just stopped doing anything, it'll get the required parameter then the JSON says it's sent it to webhook but there's only the 'secure' context in that (I remember seeing an actions on google one by default). When I remove my custom context it doesn't help, and I've updated firebase.
How do I get this back?
I think the issue was that I had deleted something in the code, maybe the }); at the end.
If you have the same issue, go OCD through your code and match everything together to check it's all good.
I'm trying to follow the instructions at https://developer.paypal.com/docs/classic/mass-pay/integration-guide/MassPayUsingAPI/#id101DEJ0100A for paying a customer. https://www.paypal.com/us/cgi-bin/webscr?cmd=_profile-api-signature# tells me the API username, API password and and signature. I paste those values directly into my program, and POST those parameters (as well as other parameters) to https ://api-3t.paypal.com/nvp and I get this response back:
TIMESTAMP=2015%2d05%2d06T23%3a58%3a01Z&CORRELATIONID=6eef131f4a296&ACK=Failure&VERSION=2%2e3&BUILD=16566018&L_ERRORCODE0=10002&L_SHORTMESSAGE0=Security%20error&L_LONGMESSAGE0=Security%20header%20is%20not%20valid&L_SEVERITYCODE0=Error
Any tips for troubleshooting what might be going on here?
Thanks in advance!
Kevin
That error means the API credentials you're using are not accurate. Double the check the values themselves and make sure you didn't miss any characters or add any extra white space on the ends of the values. Also, make sure you're not sending sandbox credentials to the live PayPal server or vice-verse. That's usually what's happening when people run into this.
I'm writing a bot in node.js using node-xmpp. So far it's pretty straight forward except I'm having an issue with figuring out how google Talk handles it's user authorization (when dealing with requesting to chat with someone NOT on your roster).
I'm catching all stanzas coming through and logging them to the console but there is no data coming from the user that is requesting authorization.
Any explanations of what I should be looking for or if this event even happens over the jabber protocol.
[appended] I know that technically when a subscription request is made a presence stanza is sent with the subscription request. I can't see these coming over the wire using node-xmpp for some reason. Also, I need to find out a way to determine what presence requests are "pending" when my bot logs in. I thought (innacurrately) that they would be listed in the roster with some sort of flag, but that's not correct.
Any help with finding out where to go from here would be useful.
Ok, I finally figured out how to get the subscription requests after they have been made. There isn't much info on it out there so I'll put together a blog post, but I feel that answering it here might be good as well.
I found that if I did a google roster query based on the below information:
http://code.google.com/apis/talk/jep_extensions/roster_attributes.html
example stanza:
<iq from="username#gmail.com/D2D4E5A8" type="get" id="google-roster-1"><query xmlns="jabber:iq:roster" xmlns:gr="google:roster" gr:ext="2"/></iq>
The server would respond first with your pending server subscription "presence" stanzas
ex:
<presence type="subscribe" from="pendinguser#gmail.com" to="namehere#gmail.com/D2D4E5A8" xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client"/>
and then the rest of your roster's "presence" stanzas. It's important to note that your subscription "presence" stanzas don't get sent to you from the server unless you do a roster query. I'm not sure why this is and why it's not documented somewhere is beyond me. Anyways, at least I can get the list of people trying to get access to my bot now.
Note: This is not my area of knowledge just an interest of mine. I have not got practical experience just a bit of research. This would have been a comment however doing some more searching on the topic, I have come up with some more things that might help.
Here's a google chat chat room homepage http://partychapp.appspot.com/ you can get the source http://code.google.com/p/partychapp/
Those links came from http://xmpp.org/2010/02/xmpp-roundup-13-services/ which has quite a few other resources that might be helpful.
http://code.google.com/p/node-xmpp-bosh/ has some code about that, I've not done it but the topic is interesting.
I hope if you do find the answer your after you write up a blog post and or a project and share it. It would be of interest to me.