I am getting introduced the wonderful world of Twilio + RoR and have so far had a pleasant experience.
However, I've noticed that if I were to make my projects public, I would exposing sensitive Twilio account information:
Account_sid
Auth_token
Twilio phone number
My question is, how can I hide these three pieces of information in a Rails application so that when pushed to GitHub, they remain unaccessible to others?
Here is some sample code below:
class SMS < ApplicationController
def text
message = params[:message]
number = params[:number]
account_sid = 'xxxxxxxxxxxxHIDExxxxxxxxxxxxxxxxx'
auth_token = 'yyyyyyyyyyyyyHIDEyyyyyyyyyyyyyy'
#client = Twilio::REST::Client.new account_sid, auth_token
#message = #client.account.messages.create({:to => "+1"+"#{number}",
:from => "zzzzHIDEzzzz",
:body => "#{message}"})
redirect_to '/index'
end
end
The answer is to not publish that information to GitHub in the first place.
When I worked with Twilio applications, I used a localsettings.py (Python, but should be the same for Ruby) file holding the sensitive information that I downloaded and distributed out-of-band.
A user-friendly interface could be a setup script to download this file from a server credentials.
Alternatively, if you must check it into github, encrypt it symmetrically with something like gnupg and decrypt it on your host machine.
In all these cases, you have to be careful not to accidentally check it in to git. Adding localsettings.rb to your .gitignore file is a great idea.
(If you've already pushed it to github, see here for how to undo that.)
a bit late my answer but you should use environment variables instead hardcoded strings.
in production you can use some tools like Vault to store it safely. here is a nice article about it https://medium.com/adessoturkey/getting-started-with-hashicorp-vault-658a3e523949
Related
We're managing an old Rails app that uses Stripe but our Stripe version 26 months behind the current API. We're looking to upgrade to the current Stripe API but because many changes will affect our system, we'd really like a way to test out the changes before we change the live API that our live site is using.
So I have two questions:
1) When working with the API we rely heavily on the distinction between Live and Test modes. Is there any way to upgrade the Test mode API only (without upgrading Live) so we can identify and correct for any breakage without actually breaking the user experience?
2) Is it possible to upgrade the API one version at a time, rather than all-at-once, to make the transition more manageable for us?
It's extremely poorly documented, but it turns out you can change the Stripe API version to any version you want on a per-request basis by setting Stripe.api_version = 'YYYY-MM-DD' before sending a request using the Ruby bindings (https://stripe.com/docs/api/ruby#versioning), or by sending a Stripe-Version HTTP header.
So we'll plan to configure our specs to use the latest API version for all requests, and test for breakage that way.
Below is one-way to override the Stripe version at a fine-grained level within your code.
This works by overriding the Stripe.api_version accessor method to look for a version in a thread local variable, or if it doesn't find one, falls back to the original behaviour. Stripe.api_version is used as the value of the Stripe-Version HTTP header in lib/stripe.rb.
Note this is for stripe gem version 1.58.0 and has not been tested with other versions:
First, create the file config/initializers/stripe_api_version_overrider.rb with contents:
module StripeAPIVersionOverrider
def api_version
Thread.current[:__stripe_api_version_override] || super
end
def with_api_version(version, &block)
original_version = api_version
Thread.current[:__stripe_api_version_override] = version
block.call
ensure
Thread.current[:__stripe_api_version_override] = original_version
end
end
Stripe.singleton_class.prepend(StripeAPIVersionOverrider)
Next, in your code where you want to use a different version of the Stripe API, wrap it in a block passed to Stripe.with_api_version:
Stripe.with_api_version "2016-07-06" do
# API versions prior to 2016-07-06 did not support
# retrieving canceled subscriptions.
Stripe::Subscription.retrieve(subscription_id)
end
Run bin/spring stop to ensure these changes will be loaded into your development environment.
I have a rails app, where every user can connect his Facebook account, and give permission to send messages from the app wich is using. So, every logged user with connected Facebook account must has one Jabber Client authorized with his Facebook-id, token etc, I'm doing it with xmpp4r GEM.
The connected facebook account with token, and facebook data is stored in Database as Mailman object.The Mailman class has also methods to control the Jabber client like run_client, connect_client, authorize_client, stop_client, get_client etc. The most important methods for me are connect_client and get_client.
class Mailman < ActiveRecord::Base
##clients = {} unless defined? ##clients
def connect_client
#some code
##clients[self.id] = Jabber::Client.new Jabber::JID.new(facebook_chat_id)
#some code
end
def get_client
##clients[self.id]
end
#other stuff
end
As you can see in the code, every Mailman object has get_client method which should return Jabber::Client object, and it's true, it is working, but only in a scope of running application, because the ##clients variable is stored only for specifc running app.
This is problem for me because I would like to use cron task to close idle clients, and the cron task is using different initalization of the app, so Mailman.find(x).get_client will return always nil, even if it returns Jabber::Client object in a production app.
How are you dealing with such issues? For example, is it possible to get a pointer to memory for Jabber::Client object and save it to database, so any other app's initalization could use it? I have no idea how to achive that. Thank you for any advice!
Even if you manage to store a "pointer to memory" in your database, it will be of no use to a cron job. The cron job is started as a new process, and the OS ensures that it won't have access to the memory space of any other process.
The best way is to create a controller to manage your running XMPP clients. This will provide a restful API to your cron job, allowing you to terminate idle clients using HTTP requests.
I use ActiveMailer with a 3rd party mailing provider. To develop my app, I want to actually see the emails that come in, as a user would, in my email client.
So in development mode, instead of disabling email, I want my app to send the mails, but change the "to" field so that every email is sent to me. Is that possible?
Update: I want to test the full route my email takes: going through my ESP, arriving in my inbox, viewing it in gmail. I'm not looking to just test that an email is created.
I personally recommend letter_opener by Ryan Bates, however, if you actually want to deliver the mail instead of just viewing it in the browser, there are a number of plugins available that others have already listed. No one, however, has mentioned that you can very easily accomplish this using Interceptors.
Create a new initializer in your config/initializers directory in your Rails app:
# config/initializers/development_mail_interceptor.rb
class DevelopmentMailInterceptor
def self.delivering_email(message)
message.subject = "[#{message.to}] #{message.subject}"
message.to = "YOUR_EMAIL#gmail.com"
end
end
ActionMailer::Base.register_interceptor(DevelopmentMailInterceptor) if Rails.env.development?
This leverages the power of an interceptor on your app. It doesn't configure anything, but rather changes the envelope on the message, altering the to and subject fields. Replace YOUR_EMAIL with the correct value.
The self.delivering_email(message) method is invoked by ActionMailer. You are hooking into that method and override the message envelope.
Finally, you register that interceptor iff we are currently in the development environment.
Be sure to restart your server, and all your mail (in Development) will actually be sent to your email.
Save yourself some trouble and run MailCatcher. MailCatcher is a simple SMTP server that just grabs outbound email and gives it to you in a simple web interface. Install MailCatcher, add this to your environments/development.rb:
config.action_mailer.delivery_method = :smtp
config.action_mailer.smtp_settings = { :host => 'localhost', :port => 1025 }
Start MailCatcher when you start your Rails server (or use Foreman or something similar to deal with it), and then go to http://localhost:1080/ to see the email that your application is sending out.
You may consider checking out something like MockSMTP (OS X); instead of modifying your "to" fields, you instead set the mail server for dev mode to the "fake" SMTP server created by the app, and from then on ALL emails (sent to anyone) go instead to the app.
I've never used it myself, but I remember seeing that the devs at 37signals use it.
On other operating systems, you may consider one of the following projects:
letter_opener by Ryan Bates - popup a new browser window when an email is sent
MailCatcher (mentioned by mu is too short) - runs a fake SMTP server and a web-based interface for viewing mail sent to it
mailtrap - similar to MockSMTP, has both a mock SMTP server and also a separate viewer program
As much as I like this answer, I went with a different option.
Use the mail_safe gem! As well as providing the functionality from sethvargo's answer, it doesn't require any work other than adding the gem, and it automatically figures out who to email from their .gitconfig.
One important note that I rarely saw mentioned when researching this is that you must use deliver, not deliver!. The latter doesnt call interceptors (though apparently it still calls observers, if that's helpful).
Scenario:
I'm a registered user of a site(a rails app).
I have my contacts in linked in whom I would like to invite to see this app(it would be followed up with their registration into this app).
For this , I would be sending them a message with a subject and body.
Rays of Hope:
I need to make use of the messaging api of linkedin and make it talk with my rails app. I can't use the connections api of linked in to retrieve the email addresses as basically any of the linkedin api's don't expose my(the registered user of linked in) contacts email.
To talk with the connections api in my rails app, I was making use of the linkedin gem. It doesn't look like this gem as of now has support for the messaging api of linkedin.
Finally:
Any ideas where can I get started on this..?. I'm kinda clueless as I have never played around with api's directly, ..yet..:).
I'm on Ubuntu 10.04 OS.
Thank you
I had the same problem with the gem lacking messaging functionality. By using the existing code as a reference, I threw this code in an initializer file (config/initializer) and it worked. Give it a try.
LinkedIn::Client.class_eval do
# options should be a hash like this:
# options = {:recipients => {:values => [:person => {:_path => "/people/~" }, :person => {:_path => "/people/USER_ID"} ]}, :subject => "Something",:body => "To read" }
def send_message(options)
path = "/people/~/mailbox"
post(path, options.to_json, "Content-Type" => "application/json")
end
end
This might not exactly answer the question, but could be of some help..
Have you looked here:
https://github.com/pengwynn/linkedin/blob/master/lib/linked_in/api/update_methods.rb
If you'll log an issue on the project repo and include some code, the
whole community can try to help:
https://github.com/pengwynn/linkedin/issues
This was provided by Wynn Netherland on contacting him. Credit goes to him..:)
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.