Freecodecamp: Stripe API call is breaking all local setups

[cmoss3]

Describe your problem and - if possible - how to reproduce it

When following the instructions in the contributors guide there seems to be an unaccounted for issue.
With a fresh build, if you attempt to execute npm run develop you'll be presented with an error.
To resolve the error you have to add a valid Strip public and private key to the .env file before executing npm run build. I'm not sure if the CONTRIBUTING.md should just be updated or if freeCodeCamp/server/boot/donate.js could be updated to prevent this issue.

Here is the error:

/home/charles/development/freeCodeCamp/server/boot/donate.js:62 throw err; ^ Error: Invalid API Key provided: sk_from_*****_*****oard at Constructor._Error (/home/charles/development/freeCodeCamp/node_modules/stripe/lib/Error.js:12:17) at Constructor (/home/charles/development/freeCodeCamp/node_modules/stripe/lib/utils.js:133:13) at new Constructor (/home/charles/development/freeCodeCamp/node_modules/stripe/lib/utils.js:133:13) at IncomingMessage.<anonymous> (/home/charles/development/freeCodeCamp/node_modules/stripe/lib/StripeResource.js:164:21) at emitNone (events.js:111:20) at IncomingMessage.emit (events.js:208:7) at endReadableNT (_stream_readable.js:1056:12) at _combinedTickCallback (internal/process/next_tick.js:138:11) at process._tickDomainCallback (internal/process/next_tick.js:218:9) [08:19:31] [nodemon] app crashed - waiting for file changes before starting...

[newnewb]

the stripe secret key isn't getting accepted, you might want to get your own key for the time being

https://stripe.com/

[Mandihamza]

Thanks for opening this issue @cmoss3! Adding my own Stripe test keys worked 👍

[rachelsinclair]

If you don't want to go to the trouble of creating your own Stripe account, I found the following test keys in the Stripe documentation:

STRIPE_PUBLIC=pk_test_g6do5S237ekq10r65BnxO6S0
STRIPE_SECRET=sk_test_BQokikJOvBiI2HlWgH4olfQ2

Drop these into .env and you're good to go!

[raisedadead]

Hi,

You should not be needing to setup any keys at all other than those provided by default.

@Bouncey we would want to skip over the donate boot script API calls to actual stripe API over a "mocking" middleware or method when in development.

[cmoss3]

^ I'm going to give this change a go. I'll create a PR here shortly

[Flarp]

I believe this is related, as running npm run develop even when not testing Stripe, causes the program to raise the error

Error: Plan already exists.
    at Constructor._Error (/root/freeCodeCamp/node_modules/stripe/lib/Error.js:12:17)                                                                 
    at Constructor (/root/freeCodeCamp/node_modules/stripe/lib/utils.js:133:13)                                                                       
    at new Constructor (/root/freeCodeCamp/node_modules/stripe/lib/utils.js:133:13)                                                                   
    at Function.StripeError.generate (/root/freeCodeCamp/node_modules/stripe/lib/Error.js:57:12)                                                      
    at IncomingMessage.<anonymous> (/root/freeCodeCamp/node_modules/stripe/lib/StripeResource.js:170:39)                                              
    at emitNone (events.js:120:20)
    at IncomingMessage.emit (events.js:218:7)
    at endReadableNT (_stream_readable.js:1054:12)
    at _combinedTickCallback (internal/process/next_tick.js:138:11)
    at process._tickDomainCallback (internal/process/next_tick.js:218:9)

Any help? I see no reason there should be a Stripe API call when starting up the server.

[coymeetsworld]

@Flarp I used my own Stripe API keys and I was able to get past this issue. Try generating your own and see if that works. I also agree that the Stripe API shouldn't be referenced on starting up.

[QuincyLarson]

@Bouncey Will adding stand-in Stripe keys to the sample .env file fix this?

[raisedadead]

@QuincyLarson it would be simpler to not have calls to API when in development. These can be mocked and there is already a PR that is addressing this. Some final details are being sorted and this will be resolved soon.

[QuincyLarson]

@raisedadead OK - that sounds like an even better approach - less that we have to communicate to contributors.

Thanks for tackling this.