I signed up for a Stripe account and followed some simple steps to get up and running with Node. I just installed the package and tested a payment Intents with my test key:
const Stripe = require('stripe');
const handleStripe = async () => {
const stripe = Stripe(testKeyString);
console.log(“we make it here”);
try {
const paymentIntent = await stripe.paymentIntents.create({
amount: 1000,
currency: 'usd',
payment_method_types: ['card'],
receipt_email: 'jenny.rosen#example.com',
});
//we never make it here
console.log(paymentIntent);
}
catch(err){
//we never make it here either
console.log(err);
}
}
The console logs “we make it here”, but nothing else. The promise is never resolved.
I suspect that this might be a bug with the stripe npm package. Anybody have any thoughts on why the promise is never returned?
EDIT: sorry, I wasted everyone’s time here. I was following the docs QuickStart where it said “install a client library” and I assumed it was for the front end. So a very silly mistake on my part thinking that it was a good idea to make a payment intent from the front end with a secret key. Just getting going with the Stripe API and I’m off to a bad start. Thanks for your comments and answer
Thanks
What happens if you run it without the try/catch? Also what do you get if you try https://status.stripe.com/reachability from that server - are you sure you can reach Stripe's servers?
Related
Good morning everyone,
I am currently running into one pretty irritating issue with getting a users messages from before the bots launch. I have been able to do this in the past (a few months ago), but it seems they have replaced the Intents.FLAGS approach for GatewayIntentBits. This has not been to complicated to change, but some problems have occurred.
One of the biggest issues, and the reason for this question is that even though I contain data in my intents that would allow for reading of reactions, as well as adding partials (I read it may help online). This does not seem to fix the issue.
const client = new Client({ intents: [GatewayIntentBits.Guilds, GatewayIntentBits.GuildMessageReactions, GatewayIntentBits.GuildMessages, GatewayIntentBits.GuildMembers], partials:["Message", "Channel", "Reaction"]})
. . .
client.on('messageReactionAdd', _ => {
console.log('a reaction has been added');
});
client.on('messageReactionRemove', _ => {
console.log('a reaction has been removed');
});
I know this isn't allot to go off of, but I have tested it with barely anything in my application and I still run into this error. Is this a known issue with the change to GatewayIntentBits? I would love to continue working on this bot.
Thank you for any assistance you may be able to provide.
EDIT: I have managed to get the reactions to work on the application now. I have not even started touching those old messages, and its working. Thank you for your help. My best bet of why its working is that the messages needed to be resent with the partials and intents specified above. I dont know why this didnt work before, but whatever.
Your gateway intent bits are fine, you need to do something similar to that for the partials as well, you need to import partials from discord.js and use them like that.
const { Client, Partials } = from 'discord.js';
const client = new Client({
intents: [],
partials: [Partials.Message, Partials.Channel, Partials.Reaction]
});
I am attempting a simple example of two users connected with webrtc using a data channel. The problem I am having is after the offer step. The second client that joins my socket.io room, I have send an offer and sets its local description.
const offer = await peerConnection.createOffer();
await peerConnection.setLocalDescription(offer)
//send offer to signal server to forward to peer
socket.emit("webrtc_offer", {
roomId: roomId,
sdp: peerConnection.localDescription,
});
Then when I receive the offer I try this...
if (!offerSender) {
await peerConnection.setRemoteDescription(offer);
const answer = await peerConnection.createAnswer();
//This sets the signalingState to stable instead of have-local-pranswer
await peerConnection.setLocalDescription(answer);
console.log("sending answer to peer");
socket.emit("webrtc_answer", {
roomId: roomId,
sdp: peerConnection.localDescription,
});
}
Once I try to set the local description from the answer I create, my signalState is reset to Stable instead of have-local-pranswer. Could someone explain why that is? This then breaks the next step of trying to respond to the answer to finish the connection.
I hope someone can help me with this issue.
I'm currently working on a project in which I use firebase to create new users. So, when someone sign a new user up, firebase creates a new user, then it sends a promise to firestore, so it can create a new document in a collection called 'users', so I can access some user data, as name, last name and initials.
My problem is that, when I sign a new user up, the account is instantly created in firebase, but it takes a long time to create a new document with the user data in firestore. When I say a long time, I mean 10, 20 minutes or even more. Thus, an account is created with undefined data, until firestore decide to create new document.
The described procedure is shown in the code below:
export const signUp = newUser => {
return (dispatch, getState, { getFirebase }) => {
const firebase = getFirebase()
const firestore = getFirebase().firestore()
firebase.auth().createUserWithEmailAndPassword(
newUser.email,
newUser.password
).then(resp => {
return firestore.collection('users').doc(resp.user.uid).set({
firstName: newUser.firstName,
lastName: newUser.lastName,
initials: newUser.firstName[0] + newUser.lastName[0]
}).then(() => {
dispatch({ type: 'SIGN_UP_SUCCESS' })
})
}).catch(err => {
dispatch({ type: 'SIGN_UP_FAIL', err })
})
}
}
I'm using redux-firestore and react-redux-firebase as dependencies to connect my project to firebase. But it does not seem to be the problem, because firestore works seamlessly for other functionalities of the project, as add and delete new data to the user when its document is finally created, or when I try to delete an user, it also works fine.
So, I would be glad if someone could find an explanation for this delay and help me to overcome this problem.
I believe you're following The Net Ninja's series (I am too). If you follow what he did exactly (here) it will work. I've personally diffed yours and my implementation with his, and the only thing that was different was the semicolons. Try adding semicolons after each line. Perhaps the chaining of promises confuses the compiler?
It still won't work when you signup, then signout repeatedly. You need to refresh after each signout.
After some time I realized that the problem was not the code or firebase. The problem was something in the structure of the project it self.
In order to solve this problem, I needed to get rid of
"#testing-library/jest-dom"
"#testing-library/react"
"#testing-library/user-event"
In package.json. Then install the dependencies again.
I am running VSCode, Nodejs, Nodemailer, and Reactjs in a Windows machine, but I cannot get Nodemailer to send email. According to the instructions in the web, it should work. Finally I did the following: I created two empty folders in both of which I ran node init, installed Nodemailer, and copied the email sending code. In the other folder I also ran create-react-app. Then I edited the files just enough to get the sending code running.
In the first folder it works without problems, but in the folder with React, it does not do anything. Not even the usual following if(error)/else(success) statements get executed, they are just jumped over. However, the code before and after the transporter.sendMail (or .verify) part are executed... Anyone know why this happens or how to fix it?
This is the code I run in both cra and the non-cra folders:
const nodemailer = require("nodemailer");
const SendEmail = message => {
const transporter = nodemailer.createTransport({
service: "Gmail",
auth: {
user: "from#gmail.com",
pass: "xxxxxxxx"
}
});
transporter.verify(function(error) {
if (error) {
console.log(error);
} else {
console.log("Server is ready to take our messages");
}
});
const mailOptions = {
from: "from#gmail.com",
to: "to#gmail.com",
subject: "Subject",
text: message,
html: "<b>Html</b>"
};
transporter.sendMail(mailOptions, (err, info) => {
if (err) console.log(err);
else console.log(info.response);
});
};
module.exports = SendEmail;
Tim
Gmail has spam filter to prevent spam, so most probably, you may get it pass through sometime and not most time without proper configuration.
and it is not a good idea to send your email in your client app, such as react. Since everyone can access to your email and password to do nasty thing, which is not really a good idea.
Best practice is to request your node server to send mail.
Other than, I noticed that you used gmail to do that. There are some free mail fake stmp server that you can do spamming without the mail provider to flag you as spam user. Such as mailTrap, if you are just interested to test, is react able to send email, try it with mailtrap. I never do it, but still it is better than using your own email provider, as they might have filter rules about it, could be the reason, you are not able to send it.
I'm using gcloud-node.
createTopic api returns error 409, if that topic exist already. Is there a flag that can implicitly create a topic when publishing a message or Is there an API to check if a topic exist already?
Its easy to use getTopics API, iterate thru the response topic array and determine if a topic exist. Just wanted to make sure I dont write something, if it exists already.
Is there a flag that can implicitly create a topic when publishing a message or Is there an API to check if a topic exist already?
I believe the problem you'll run into is that if a message is published to a topic that doesn't exist, it is immediately dropped. So, it won't hang around and wait for a subscription to be created; it'll just disappear.
However, gcloud-node does have methods that will create a topic if necessary:
var topic = pubsub.topic('topic-that-maybe-exists');
topic.get({ autoCreate: true }, function(err, topic) {
// topic.publish(...
});
In fact, almost all gcloud-node objects have the get method that will work the same way as above, i.e. a Pub/Sub subscription or a Storage bucket or a BigQuery dataset, etc.
Here's a link to the topic.get() method in the docs: https://googlecloudplatform.github.io/gcloud-node/#/docs/v0.37.0/pubsub/topic?method=get
ran into this recently, and the accepted answer runs you into http 429 errors. topic.get is an administrative function which has a significantly lower rate limit than normal functions. You should only call them when neccessary eg. error code 404 during publish (topic doesn't exist), something like so:
topic.publish(payload, (err) => {
if(err && err.code === 404){
topic.get({ autoCreate: true }, (err, topic) => {
topic.publish(payload)
});
}
});
Personally use this one
const topic = pubsub.topic('topic-that-maybe-exists');
const [exists] = await topic.exists();
if (!exists) {
await topic.create();
}