I am totally new to braintree and was just trying out the tutorial (javascript for client and JAVA on the server side)
I created a simple HTML file basically just wrapping the "Hello Client" example. I had also tried using both the given clientToken provided in the example and one I obtained from the sandbox account.
However, after I filled out a valid credit information and tried to submit the form, I've got this error:
"There was an error processing your request. Try again"
And this error occurred BEFORE the form submission was actually sent to the server; braintree.js seems to have intercepted the submission and did some authorization with its server, and thats where the error above came from
I looked at the chrome developer console and saw the requests were like this:
Request URL:https://client-analytics.sandbox.braintreegateway.com
Params:
authorizationFingerprint: [some fp]
sharedCustomerIdentifierType:undefined
analytics[][kind]:dropin.web.inline.add-card.fail
_meta[platform]:web
_meta[platformVersion]: [some value]
_meta[integrationType]:dropin
_meta[sdkVersion]:braintree/web/2.3.3
_meta[merchantAppId]:file:///Users/jiayaohan/Desktop/card.html
braintreeLibraryVersion:braintree/web/2.3.3
_method:POST
callback:callback_json9
And the status code itself was OK (200), but in the response, the content was:
callback_json9({status:201})
Anyone knows what might go wrong with this very simple hello-world client setup? (noted that I've tried using both the given example client Token and one derived from my own sandbox account, but the same error happened)
Thanks!
I work at Braintree.
It looks like there was a failure adding a card. Are you using the available testing card credentials?
Sandbox only accepts certain test numbers, so that could be your issue. The most commonly used test number is 4111111111111111.
Related
I'm trying to get the basic "hello world" of sendgrid working, but have so far been unsuccessful. The response returns code 202, suggesting that it will send the email, but the email never sends out. Does anyone know what's going on?
import sendgrid
sg = sendgrid.SendGridAPIClient(apikey='**my-api-key**')
data = {
"personalizations": [
{
"to": [
{
"email": "me#gmail.com"
}
],
"subject": "Hello World from the SendGrid Python Library!"
}
],
"from": {
"email": "me#gmail.com"
},
"content": [
{
"type": "text/plain",
"value": "Hello, Email!"
}
]
}
response = sg.client.mail.send.post(request_body=data)
print(response.status_code)
I just had this issue: I created an account with SendGrid and tried to get the basic example working, the API would return a 202 response, but the email was never sent, and the SendGrid web UI's activity feed showed no activity.
I submitted a SendGrid support ticket and ~8 hours later received a response saying that they had disabled my account's ability to send emails:
Hello,
Thanks for contacting SendGrid Support!
It looks like your account has been closed by our compliance team and this is the cause of the issue.
To reactivate we’d like to know a little more about the email you’ll be sending through SendGrid. Please elaborate on the following:
The nature of your business, the services you provide, and your potential customer base
Your sending frequency and volume
How you collect your recipient addresses (link to opt in page, or sign up process)
How you will allow your recipients to opt out of your emails (whether you plan to use SendGrid’s one-click unsubscribe feature, or if you have your own method)
The types of messages you will be sending (transactional or marketing)
Please reply at your earliest convenience in order to continue the activation process. Thanks for your cooperation!
~15 hours after submitting my answers, I received a response saying my account had been "activated":
Hi nathan.wailes,
Thanks for the additional information! Your SendGrid account has been
activated, and can now be used to send email. To get started, check
out our Getting Started page.
If you hit any snags while you're getting set up, you can find
solutions to common problems and FAQS in our Knowledge Base.
Let me know if you have any more questions!
Best,
Stevin O.
Associate Support Engineer
When I then ran the basic example code with my email address set up as the recipient, the email showed up immediately in my Gmail inbox.
Debug this by going to the sendgrid api log here:
https://app.sendgrid.com/email_activity
In my case, it was a DMARC receiving domain block.
The 202 Accepted Status Code returned from SendGrid does not really indicate that the message has been successfully delivered to the recipients inbox. It indicates that the message is valid and has been "Queued For Delivery". Now, it is up to the receiving server to deliver this message to the recipients inbox, or to send it to spam, or simply drop the message.
There are several reasons as to why messages that returns 202 Accepted Status code from SendGrid does not actually get delivered to the recipients inbox.
For example:
Invalid email address: The email address may no longer be valid (example, when an employee stops working at some company, their email might be removed from the company's system removing the ability to receive any email).
Blocked Emails: If the sending IP or domain is blocked or if the recipients inbox provider has some filters set up such that some specific content of your email/campaign is considered spammy and thus gets automatically blocked.
Another thing to note is that SendGrid may send the messages to spam/junk if the domain authentication has not been properly set up. So make sure that your domain is properly authenticated.
Here is the link to the documentation from SendGrid that explains these event in details. https://sendgrid.com/blog/delivered-bounced-blocked-and-deferred-emails-what-does-it-all-mean/
I had same issue and solved it by adding new api key with full access
In case someone will come across this looking for an answer to a similar problem. I solved the same problem by confirming the domain with DNS records - after that everything worked like charm.
In Sendgrind: Setting > Senders Authentication > Domain Authentication
For us, the problem was that the used dynamic template was not yet set to "active". Unfortunately no error was shown about the in the API response or the log.
Activating the email template solved this and emails are no longer dropped.
The same issue occurred when DNS is not verified and you are not using register email in from email.
Just change from email to register email.
I recently got the same issue. My e-mails were not sent without any reason, the response status was 202, e-mail activity was empty. The possible solution is to add a company details and add an unsubscribe block to e-mail. That worked for me.
I'm implementing a password reset feature and it's a little weird to have an unsubscribe block for this. I'll try to figure out what was the real reason of such silent suppression. Probably it's because I tried to send a draft debug e-mail several times which was looked like a spam. Maybe SendGrid has some smart algorithms for detecting this.
I also had this issue. I contacted sendgrid support however while waiting I changed the dummy data to real data I was calling sendgrid API with and then it started working.
in particular I changed the from email address to show my own domain.
For me the template was the issue. When using the template engine make sure to use {{variable}} instead of {{ variable }}. Afterwards I received the emails as usual.
this is my first post so please go easy on me!
I am a beginning developer working with javascript and node.js. I am trying to make a basic request from a node js file to facebook's graph API. I have signed up for their developer service using my facebook account, and I have installed the node package for FB found here (https://www.npmjs.com/package/fb). It looks official enough.
Everything seems to be working, except I am getting a response to my GET request with a message saying my appsecret_proof is invalid.
Here is the code I am using (be advised the sensitive info is just keyboard mashing).
let https = require("https");
var FB = require('fb');
FB.options({
version: 'v2.11',
appId: 484592542348233,
appSecret: '389fa3ha3fukzf83a3r8a3f3aa3a3'
});
FB.setAccessToken('f8af89a3f98a3f89a3f87af8afnafmdasfasedfaskjefzev8zv9z390fz39fznabacbkcbalanaa3fla398fa3lfa3flka3flina3fk3anflka3fnalifn3laifnka3fnaelfafi3eifafnaifla3nfia3nfa3ifla');
console.log(FB.options());
FB.api('/me',
'GET',
{
"fields": "id,name"
},
function (res) {
if(!res || res.error) {
console.log(!res ? 'error occurred' : res.error);
return;
}
console.log(res);
console.log(res.id);
console.log(res.name);
}
);
The error I am getting reads:
{ message: 'Invalid appsecret_proof provided in the API argument',
type: 'GraphMethodException',
code: 100,
fbtrace_id: 'H3pDC0OPZdK' }
I have reset my appSecret and accessToken on the developer page and tried them immediately after resetting them. I get the same error, so I don't think that stale credentials are the issue. My
console.log(FB.options())
returns an appropriate looking object that also contains a long hash for appSecretProof as expected. I have also tried this code with a number of version numbers in the options (v2.4, v2.5, v2.11, and without any version key). Facebook's documentation on this strikes me as somewhat unclear. I think I should be using v2.5 of the SDK (which the node package is meant to mimic) and making requests to v2.11 of the graph API, but ??? In any case, that wouldn't seem to explain the issue I'm having. I get a perfectly good response that says my appSecretProof is invalid when I don't specify any version number at all.
The node package for fb should be generating this appSecretProof for me, and it looks like it is doing that. My other info and syntax all seem correct according to the package documentation. What am I missing here? Thank you all so much in advance.
looks like you have required the appsecret_proof for 2 factor authorization in the advance setting in your app.
Access tokens are portable. It's possible to take an access token generated on a client by Facebook's SDK, send it to a server and then make calls from that server on behalf of the client. An access token can also be stolen by malicious software on a person's computer or a man in the middle attack. Then that access token can be used from an entirely different system that's not the client and not your server, generating spam or stealing data.
You can prevent this by adding the appsecret_proof parameter to every API call from a server and enabling the setting to require proof on all calls. This prevents bad guys from making API calls with your access tokens from their servers. If you're using the official PHP SDK, the appsecret_proof parameter is automatically added.
Please refer the below url to generate the valid appsecret_proof,and add it to each api call
https://developers.facebook.com/docs/graph-api/securing-requests
I had to deal with the same issue while working with passport-facebook-token,
I finally released that the problem had nothing to have with the logic of my codebase or the app configuration.
I had this error just because I was adding intentionally an authorization Header to the request. so if you are using postman or some other http client just make sure that the request does not contain any authorization Header.
It seems like something has changed on the Yammer side, because my app (not yet published to the Yammer Global App Directory) has stopped working, resulting in an obscure CORS error, that doesn't tell a thing about the problem.
So the workflow is very simple —
I'm ensuring that user is logged in by calling getLoginStatus() (which pops-up a window and immediately closes it. Irritating, but can live with that)
Sending a request to messages/in_group/ID.json wrapped in a yam.platform.request, as suggested by the Yammer JS SDK manual
Here's the console screenshot:
In the Yammer App settings there's a single Javascript Origin, which is https://buzztale.com, which is exactly the one, the request is made from.
This happened before, but then disappeared itself (really confusing). And now it seems to be back…
Hope somebody has any suggestions regarding this issue. In order to get to the app, here's the URL — https://buzztale.com/yammer.
Same here my dev app started failing sometime today.
It seems that all of the login end points are working as expected however the messages feed is giving me CORS errors.
yam.platform.request({
url: "https://api.yammer.com/api/v1/messages/my_feed.json",
method: "GET",
success: function (user) { //print message response information to the console
console.log("The request was successful." + user.messages);
},
error: function (user) {
console.log("There was an error with the request.");
}
});
Yeah, I'm seeing this on our end too. Seems to be just the GET requests with the messages api endpoint. Like POST / DELETE and Message POST seem to work correctly.
This issue appeared to me around 4PM PST yesterday (7/22/14).
This was a known issue with a recent change on our side, and we have
pushed a fix to production today. Please let me know if it still isn't
working for you. — Nick
So it is an issue on the Yammer side and we can just hope for it not to appear again.
I am seeing this with the notifications endpoint as well. I noticed that the CLIENT_ID is not being appended to the call
https://api.yammer.com/api/v1/streams/notifications.json?&_=xxxxxxxxxx
I am getting an error when I use JavaScript remoting and have my URLReWriter turned on on my Force.com SIte. The error does not occur when using JavaScript Remoting with the URL ReWriter turned off.
The error is as follows
Exception Error parsing json response: 'Unexpected token <'. Logged in?
I'm confused as to why this is occuring. If I have no checks for being logged in in my URL ReWriter (or visualforce page) why should this occur?
Has anyone ever come across something similar to this before? I noted the following https://salesforce.stackexchange.com/questions/4112/possible-oauth-remote-action-bug but in my case I am not using authentication on my site for the test page that I created & I'm wondering why it mentions "login".
Is it possible that URLRewriters and JavaScript Remoting currently do not work together in general?
Thanks in advance for any help on this.
Can you try debugging it server side? Add "your_site_name Guest User" to the debug logs and try the action. If you're lucky you'll see something going wrong (in the remote action? in rewriter?) and I suspect this uncaught problem causes a redirect to maintenance page (which will be HTML, not JSON)...
If not - use Firebug or similar tool to inspect request & response in detail? Or event.status?
Can it be something related to permissions? http://www.salesforce.com/us/developer/docs/pages/Content/pages_js_remoting.htm Or if you're returning html - I think you should have {escape:true}?
Does it happen in any browser? Maybe something doesn't like redirects caused by the URL rewriter. I've seen cases (not with Salesforce though) that antivirus software sometimes was adding some strange javascript at the end of certain websites and they had to be whitelisted...
The error may also happen due to parser error when page recieves status message from remote action function.
For example i tried Remote Action with attachment
#RemoteAction
public attachment attach(String body){
attachment a=new attachment();
a.body=body;
a.name='a.png'
insert a;
return a;
}
On the above code i receive error since SFDC does not parse the attachment object.SO if there are parser errors we get this message .
As a workaround i send as a wrapper .Hence i would suggest to investigate the return parameter of remote action and also wrapping it as workaround .
Hope this helps
We are participating in the Facebook Credits beta. After approval of our live app, we followed the steps from the API page to set up the demo application:
http://developers.facebook.com/docs/creditsapi
However, whenever we submit with the "Pay with Facebook" button, we are getting back error 1383008 ("The application you are using is not responding").
We've checked the server logs and confirmed that all necessary params are passing to http://apps.facebook.com/ajax/flows/?__a=1 as expected. We've also confirmed that the callback URL (callback.php from the demo app files) is never being hit.
Just to be certain this isn't a compatibility issue with the new JavaScript SDK, we set up the demo using the old JS SDK and got the same error.
Has anyone else experienced this issue with running the demo application (using either version of the SDK)? If we can't get the demo to run, we can't implement this feature in our live app.
Here is the request sent to the server (app ID removed):
deadbeef=2386512837&app_id=OUR_APP_ID&api_key&receiver=0&order_info=%7B%22title%22%3A%22BFF%20Locket%22%2C%22description%22%3A%22This%20is%20a%20BFF%20Locket...%22%2C%22price%22%3A%2210%22%2C%22image_url%22%3A%22http%3A%2F%2Fwww.facebook.com%2Fimages%2Fgifts%2F21.png%22%2C%22product_url%22%3A%22http%3A%2F%2Fwww.facebook.com%2Fimages%2Fgifts%2F21.png%22%7D&place=app&credits_purchase=false&flow_type=BuyItem&__d=1&post_form_id=57484628313c8345bd4e904f684e43e5&fb_dtsg=1GSvy&lsd&post_form_id_source=AsyncRequest
Here is the response returned:
for (;;);{"error":0,"errorSummary":"","errorDescription":"","errorIsWarning":false,"silentError":0,"payload":{"secure":false,"handler":"","title":"Application Error","userData":{"fbpayments_error":"{\"error_code\":1383008,\"error_message\":{}}"},"body":"<div class=\"pam uiBoxRed\">The application you are using is not responding.<\/div>","buttonsMessage":null,"buttons":"ok"}}
We have updated the Facebook Credits API sample application and documentation. If you are still having issues, please post your frontend code as well as your callback and we can take a look.
I was also having the same issue.. I was able to fix this. This error occurred for me was due the wrong call back url. I used my local_url
'http://localhost:3000/blabla'
instead of using
http://apps.facebook.com/application-name/