I have followed Stripe's Rails tutorial (https://stripe.com/docs/checkout/guides/rails) exactly (copy and pasted code), but when I run rails
PUBLISHABLE_KEY=pk_foo SECRET_KEY=sk_bar rails s
and go to localhost:3000/charges/new and fill out the fields with the test card data (card number "4242 4242 4242 4242"), but I get an
Invalid API Key provided: ***********_***
Any ideas why this is happening?
You need to plug in your publishable key and secret key; pk_foo and sk_bar are placeholders. (Unlike the API docs, the Checkout tutorial doesn't use information from your account.)
You can get them from the API Keys tab of Your Account.
i.e. for a secret key of Sk123456 and a publishable key of pk_987654, you'd issue:
PUBLISHABLE_KEY=pk_987654 SECRET_KEY=Sk123456 rails s
If that still doesn't work there are a couple things to check:
Are both keys from the same environment (test or live)? Occasionally people mix the two together.
If you load a Rails console instead of a Rails server, can you access those environment variables with ENV['PUBLISHABLE_KEY'] and ENV['SECRET_KEY']?
If you're using multiple APIs, it's possible you have some kind of collision occurring; you might try adjusting the command-line and the code to STRIPE_PUBLISHABLE_KEY and STRIPE_SECRET_KEY.
another thing you might check is that the API keys you are using are actually the right ones. What happened to me is that I was scanning the keys in Stripe Dashboard and the ones in my .env file, and made a snap judgement that they were the same based on how they started and ended. They both looked like this, with every character identical, except for the 3rd character:
sk_test_******************************D6D
For whatever reason, when Stripe rolls a new key, they keep it almost the same.
In short, don't trust your eyes, and make sure the keys are actually the same.
Related
I'm currently in the process of adding two-factor authentication to a rails app. I added a process that lets users enable two-factor authentication, by using a QR code to verify themselves. I'm using this gem: https://github.com/Houdini/two_factor_authentication, which lets you generate a provisioning uri that can be turned into a QR code. The user can then scan this with apps like Authy or Google authenticator, to get a one-time password.
I'm now at the point where I need to write tests for this, and I therefore need to be able to automate the process of getting security codes from the provisioning uri, without the need to scan it with an app.
So my question is: Is it possible to get the secret key, that you would get by scanning the QR code, programmatically and if so, how?
The app is based on Ruby on rails 5.2.
When you want to test a feature from a specific gem, in the most cases you can find some clues in the original repo. Popular gems usually are well tested. Take a look here https://github.com/Houdini/two_factor_authentication/blob/master/spec/lib/two_factor_authentication/models/two_factor_authenticatable_spec.rb#L182
You have two options:
Find a way to read the QR in Ruby. This would most resemble what the user has to do, but may be hard (I don’t know — I've never done it).
Generate the 6-digit code (the "TOTP code") yourself. This feels a little more hacky (and dives into some implementation details, I suppose) but is easier to do than option 1.
For option 2, you can use the rotp gem (which Houdini uses itself) and the secret key you generate through Houdini.
secret_key = user.generate_totp_secret
# then...
totp = ROTP::TOTP.new(secret_key)
totp.now # --> the 6-digit code
(You can see how Houdini uses the rotp gem here.)
I have deployed an application to Heroku and have used the heroku config:set command to set environmental variables such as keys for certain things (Google Maps API, for example). When I view the page and inspect element, the key shows up in the url in the console. Should this be the case? I was under the impression that keys should be kept hidden to keep others from knowing what they are for security reasons. Please advise. Thank you.
You can't. Anything which is sent to the client is not secret. That includes any values used in javascript.
But don't worry - most API's like Google Maps use a public key. And applications where you use Oauth only allow a whitelist of callback domains.
In fact in the Google Maps Javascript API your API key is used in constructing the URLs used to request resources so attempting to hide it would be a true fools errand.
Some API's do however provide client secrets for calling the API from the server side. These should be kept secret and placed in an ENV var on the server.
I just got an API key for a database I wish to access and want to start building my Rails app. However I dont know where to begin with the API key. Specifically I want to use the brewerydb data and I am building an app where users can find the closest brewery to their location. Can anyone tell me how to get started? I am new to Rails and have never used an API before. I don't know where to begin. What file should I put it in, etc... I know I should probably update the GEMFILE, where else?
Thanks!
Check the documentation for the API. That's all I can say. (well... not really: )
Most API's rely on REST or SOAP, which is basically making HTTP request to certain URI's. An example may be
http://api.somewebsite.com/beers.json
Which would return, for instance, a JSON array of certain beers and their properties.
Furthermore, more often than not, you can test API's (that do not require certain HTTP headers for authentication, which makes it harder) by manually constructing the URI's and opening them in your browser. This way, you can verify that your request is okay before you try it in your Rails application an cannot figure out why it's not working.
You should use the 'figaro' gem https://github.com/laserlemon/figaro
It creates a "application.yml" file in which you can add your API key.
I'm trying to implement a ogone test account in my rails development application, but I keep getting the error message 'Merchant not active'
After some investigation I believe it has something to do with the SHA encoding?
Problem is I don't really get how this works, Ogone has multple SHA parameters to fill out and I haven't found a way in activemerchant to put it in there.
Someone with some experience in this matter?
The reason you are getting the Merchant not active error is because your account is not configured to be able to use Direct Link or several other options. To activate this you should get a higher subscription or contact their support and ask them to activate it for you.
As for SHA, you need to configure a secret passphrase by which you separate the parameters you're sending. For instance:
Passphrase: ogonepass123
Post variables: CN=JohnDoeogonepass123AMOUNT=1000ogonepass123CURRENCY=EURogonepass123PSPID=MyPSPID
Eventually you Hash your post variables to SHA-1 and add that key to your post parameters as
....ogonepass123SHASIGN=<40-characters-SHA-key>
This way you secure your data and make sure nobody can tamper with those variables.
Also make sure that when you get a response from Ogone you re-form a SHA hash using the parameters they've send you and you then compare this own-formed SHA hash with the one sent to you by Ogone. If these two match you can be sure that the parameters have not been messed with.
Hope this helps you or others who come across this question.
to work with Ogone Direct Link with an account created after Mai 10, 2010 you will need this patches : https://github.com/Shopify/active_merchant/pull/85
(This also works with accounts created before this date.)
This will also give you more details on the aliases usage, fix some issues with new updates from Ogone, ... make sure to read the inline doc within the ogone gateway code : https://github.com/ZenCocoon/active_merchant/blob/master/lib/active_merchant/billing/gateways/ogone.rb
As of today, the SHA1 is supported and to be used.
I'm trying to find my way around the OAuth spec, its requirements and any implementations I can find and, so far, it really seems like more trouble than its worth because I'm having trouble finding a single resource that pulls it all together. Or maybe it's just that I'm looking for something more specialized than most tutorials.
I have a set of existing APIs--some in Java, some in PHP--that I now need to secure and, for a number of reasons, OAuth seems like the right way to go. Unfortunately, my inability to track down the right resources to help me get a provider up and running is challenging that theory. Since most of this will be system-to-system API usage, I'll need to implement a 2-legged provider. With that in mind...
Does anyone know of any good tutorials for implementing a 2-legged OAuth provider with PHP?
Given that I have securable APIs in 2 languages, do I need to implement a provider in both or is there a way to create the provider as a "front controller" that I can funnel all requests through?
When securing PHP services, for example, do I have to secure each API individually by including the requisite provider resources on each?
Thanks for your help.
Rob, not sure where you landed on this but wanted to add my 2 cents in case anyone else ran across this question.
I more or less had the same question a few months ago and hearing about "OAuth" for the better part of a year. I was developing a REST API I needed to secure so I started reading about OAuth... and then my eyes started to roll backwards in my head.
I probably gave it a good solid day or 2 of skimming and reading until I decided, much like you, that OAuth was confusing garbage and just gave up on it.
So then I started researching ways to secure APIs in general and started to get a better grasp on ways to do that. The most popular way seemed to be sending requests to the API along with a checksum of the entire message (encoded with a secret that only you and the server know) that the server can use to decide if the message had been tampered with on it's way from the client, like so:
Client sends /user.json/123?showFriends=true&showStats=true&checksum=kjDSiuas98SD987ad
Server gets all that, looks up user "123" in database, loads his secret key and then (using the same method the client used) re-calculates it's OWN checksum given the request arguments.
If the server's generated checksum and the client's sent checksum match up, the request is OK and executed, if not, it is considered tampered with and rejected.
The checksum is called an HMAC and if you want a good example of this, it is what Amazon Web Services uses (they call the argument 'signature' not 'checksum' though).
So given that one of the key components of this to work is that the client and server have to generate the HMAC in the same fashion (otherwise they won't match), there have to be rules on HOW to combine all the arguments... then I suddenly understood all that "natural byte-ordering of parameters" crap from OAuth... it was just defining the rules for how to generate the signature because it needed to.
Another point is that every param you include in the HMAC generation is a value that then can't be tampered with when you send the request.
So if you just encode the URI stem as the signature, for example:
/user.json == askJdla9/kjdas+Askj2l8add
then the only thing in your message that cannot be tampered with is the URI, all of the arguments can be tampered with because they aren't part of the "checksum" value that the server will re-calculate.
Alternatively, even if you include EVERY param in the calculation, you still run the risk of "replay attacks" where a malicious middle man or evesdropped can intercept an API call and just keep resending it to the server over and over again.
You can fix that by adding a timestamp (always use UTC) in the HMAC calculation as well.
REMINDER: Since the server needs to calculate the same HMAC, you have to send along any value you use in the calculation EXCEPT YOUR SECRET KEY (OAuth calls it a consumer_secret I think). So if you add timestamp, make sure you send a timestamp param along with your request.
If you want to make the API secure from replay attacks, you can use a nonce value (it's a 1-time use value the server generates, gives to the client, the client uses it in the HMAC, sends back the request, the server confirms and then marks that nonce value as "used" in the DB and never lets another request use it again).
NOTE: 'nonce' are a really exact way to solve the "replay attack" problem -- timestamps are great, but because computers don't always have in-sync timestamp values, you have to allow an acceptable window on the server side of how "old" a request might be (say 10 mins, 30 mins, 1hr.... Amazon uses 15mins) before we accept or reject it. In this scenario your API is technically vulnerable during the entire window of time.
I think nonce values are great, but should only need to be used in APIs that are critical they keep their integrity. In my API, I didn't need it, but it would be trivial to add later if users demanded it... I would literally just need to add a "nonce" table in my DB, expose a new API to clients like:
/nonce.json
and then when they send that back to me in the HMAC calculation, I would need to check the DB to make sure it had never been used before and once used, mark it as such in the DB so if a request EVER came in again with that same nonce I would reject it.
Summary
Anyway, to make a long story short, everything I just described is basically what is known as "2-legged OAuth". There isn't that added step of flowing to the authority (Twitter, Facebook, Google, whatever) to authorize the client, that step is removed and instead the server implicitly trusts the client IF the HMAC's they are sending match up. That means the client has the right secret_key and is signing it's messages with it, so the server trusts it.
If you start looking around online, this seems to be the preferred method for securing API methods now-adays, or something like it. Amazon almost exactly uses this method except they use a slightly different combination method for their parameters before signing the whole thing to generate the HMAC.
If you are interested I wrote up this entire journey and thought-process as I was learning it. That might help provide a guided thinking tour of this process.
I would take a step back and think about what a properly authenticated client is going to be sending you.
Can you store the keys and credentials in a common database which is accessible from both sets of services, and just implement the OAuth provider in one language? When the user sends in a request to a service (PHP or Java) you then check against the common store. When the user is setting up the OAuth client then you do all of that through either a PHP or Java app (your preference), and store the credentials in the common DB.
There are some Oauth providers written in other languages that you might want to take a look at:
PHP - http://term.ie/oauth/example/ (see bottom of page)
Ruby - http://github.com/mojodna/sample-oauth-provider
.NET http://blog.bittercoder.com/PermaLink,guid,0d080a15-b412-48cf-b0d4-e842b25e3813.aspx