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.
Related
I have this site:
https://acad.unoesc.edu.br/academico/login.jsp
And I want to put info in the fields values and submit then, to get the next page and navigate in that site. Thats because I want to create an android app or something like that. Im using lua in first case, with luasocket(http).
I know that the input has its names, but I dont know how to set then and send then to the server. If someone can help me with this.
Thank you.
You can use POST method with luasocket. See the official documentation and a detailed example in this SO answer.
Since you seem to be doing authentication, you'll probably need to save the cookie value returned to you as part of the login response and then pass that cookie back to the server (otherwise your subsequent requests will fail as the server will reject those requests as non-authenticated).
Since you are sending this over https, you'll need to use LuaSec, which provides ssl.https module as replacement for the http module that luasocket provides. You may check my blog post for some example of how this can be done.
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.
I've coded the paypal IPN exactly the way it should be coded, including the confirmation page. Everything works perfectly in the sandbox, but in the real environment paypal keeps sending the data through GET instead of post, even after keeping the rm value =2. So I've read some articles and changed auto return on. Still it returns via GET, then again I changed auto return to off, still it returns via GET...
I need the information through POST, including the variables I've passed...Somebody please help me here....
Make sure that you do not have auto return with PDT enabled in your account. This will cause the post to be a GET. If you are passing over the return URL in your code and setting the variable "rm" to "2", it should be getting returned as a post. If, this is still not working, can you provide your button code that you are using so that I can take a look at the code and the account.
I just tested this with my account and it is working correctly.
Are you hosted with shared hosting on GoDaddy? Your host may not allow POST requests from 3rd party servers?
I've inherited some legacy Rails code (2.1.3) and there appears to be a public_cert as well as a signature. I thought PayPal used one or the other, but my configuration seems to have both:
config.app_config.pay_pal.merge!(
:password=>"WHATEVER",
:public_key=>"-----BEGIN CERTIFICATE-----\nMIICmTCCAgKgAwIBAgIDEcmhMA0GCSqGSIb3DQEBBQUAMIGZMQswCQYDVQQGEwJV\nUzETMBEGA1UECBMKQ2FsaWZvcm5pYTERMA8GA1UEBxMIU2FuIEpvc2UxFTATBgNV\nBAoTCHANGEDSTUFFqe0RzCDhQmVhgtNWZxeqzjVbVrCx80jF1\nWi/+ksJQLPViFj9+F4WS5i4MjMeCIwIDAQABow0wCzAJBgNVHRMEAjAAMA0GCSqG\nSIb3DQEBBQUAA4GBAMwavx4Eh2JCOCOc/WvL7zdRL07So48mQ9aJr4Bxdgib+/z2\nkqX0ZPJv9T6NQ1h9lcwohIuaJMXtLAysJMjvKcvPdzcHqB6Xv+OGpi2REJjUdB39\n9amutkxQVhKBfK3hCP4+8UlM1yzxejyK8SVWSJCbc5zvJFoLV4SZcbNevtw9\n-----END CERTIFICATE-----\n",
:business=>"me#site.com",
:business_id=>"4WSDFSFSDF",
:login=>"me_api1.site.com",
:cert_id=>"AAAA",
:private_key=>"-----BEGIN RSA PRIVATE KEY-----\nMIICXAIBAAKBgQDm5fXKcp6ht6+Be4Y7VOaNvEPZwVqRt0CHANGEDMORESTUFFKTF7Mozcg12qiq1VDqFYwQF\n8gteGGLFy3GKPWlpqtJzAI4xfpI07d2ivgfXkk4Q74np+P8udulM0bEA+WAoGO6e\nHZ7g0/EbutA0+H5TTSp3gUYa5xcUhSrMiYN/r6HK+aeKnNECQQD8D/oBjEsZwsAB\n2KxDLZfEcrmFiLxjqQSBKPtMJP0Lrhl7OyB2v1o3QDA5+QdbDFbRxA1RNQfw+ZXo\nPuP49DRpAkEA6oFYlNnGvNWlHxDmVob5q88HEgP/ZEWFJXzZcSsAkJNrbdyPCdSj\nxN2M0duJlegJlfsr6l9OyBeFcSXnrVSAqwJBAO7BP2FJ/zUGeJMHJpx3SkOFG9+1\nliScSy0AoZANlTcEERTd+7EfLZgaD9RJ40LF3FLTbn3WSpBiCTG0qIH+5skCQF4K\n5SU8eJC99OwScOz+UB3wdltpMwBZSN4RxXm2zxErrYdvTgWZOtv2JUT7j5+IYF+/\nTIs/EW74z9DibJh8LOUCQEsMclIUTorjVVtAgI5LiSwenDSCgf9Ra0r3CoL3dAGz\n1RskSziPqfQyA2QDFfSPkmycgxPlZvP0G8fwuBs6sjI=\n-----END RSA PRIVATE KEY-----\n",
:signature=>"AwhNvKUCHANGEDSTUFF9xveB4"
)
I'm using PayPal Payments Standard I believe with Rails ActiveMerchant.
Any help would be greatly appreciated
PayPal only allows you to use one or the other. It may have been that the previous person generated the cert or signature and added it to the code, only to switch over to the other method at a later date and never removed it from the code. If it's currently working and processing payments on the PayPal account, you could log into the PayPal account and see which one is currently active on the account. You are only going to see one or the other. Which ever one you are seeing, means the other one would not be being used. If it's not showing, it would not be valid anymore.
Another option, would be you could walk thru the code and see where the API call is being made, and check which one it is sending across to PayPal.
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