Forem: fedeagripa

Rails review on 2023

fedeagripa — Tue, 03 Jan 2023 09:47:55 +0000

As Ruby on Rails 7 is the latest version of the popular web application framework, and it includes a number of new features and improvements. Here are some of the key features that you can look forward to when using Rails 7:

Action Mailbox: This new feature allows you to route incoming emails to controller-like mailboxes, where you can process them and take further action. This makes it easy to build applications that interact with email in a more automated way.

Action Text: This feature provides rich text editing capabilities for your applications, making it easy to create and edit formatted text. It uses the Trix editor, which is a lightweight and flexible WYSIWYG editor.

Multiple DB Support: Rails 7 now supports working with multiple databases in a single application, which can be useful in certain situations where you need to scale horizontally.

Parallel Testing: This feature allows you to run your test suite in parallel, which can significantly reduce the time it takes to run your tests.

Action Cable Testing: Action Cable is a feature that allows you to build real-time features into your applications, and Rails 7 now includes support for testing these features.

Custom Action Options: You can now define custom options for your controller actions, which can be used to specify additional behavior or requirements.

Time Zone Support: Rails 7 includes improved support for working with time zones, including the ability to set a default time zone for your application.

Overall, Rails 7 includes a number of new features and improvements that make it easier to build and maintain high-quality applications. If you're using an earlier version of Rails, upgrading to Rails 7 is definitely worth considering.

AWS Bad decisions: impossible to migrate

fedeagripa — Tue, 22 Feb 2022 17:08:58 +0000

TLTR: Due to so many restrictions AWS is generating a downtime of 3-4+ hours in my production site due to needed maintenance/migration.

I'm in a situation where as a founder I need to transition my AWS infrastructure from my personal account to a company domain one. You may say this is only my problem, but let say you need to migrate a bucket or a site from one account to other, now that sounds more casual, right?

Well, the thing is my infrastructure is a static web site hosted in AWS in a bucket. On top of that I have CloudFront & Cloudflare so my guess for a production site was that last two were going to be the problematic ones.

Unfortunately Amazon made the amazing decision to tight buckets to the creator account and don't provide any way to migrate or provide others ownership. On top of that they have the terrible restriction that bucket names are unique worldwide, so on top of I need to create buckets with the domain name to work properly now I'm completely blocked.

The only solution Amazon support provides me is to create a new bucket with a silly name in the new account, erase the old one and wait an unknown amount of hours for replicas to see the bucket was erased. So that means I will be working 3+ hours on a super simple migration and the production site will be down with all the implications that have for a content delivery company.

Thoughts? My thinking is that AWS is making so many wrong decisions and they are taking the wrong track about how to provide service to tech companies.

They need to provide flexibility just as they claim internally

Rails 7 - Sneak Peek [part1]

fedeagripa — Fri, 03 Sep 2021 20:58:06 +0000

New method

# replaces the common pattern of finding sibling objects without one self:
relation.excluding(post, another_post)

Lets see how we can use it

A simple example for this shows can you simply filter other posts in your usually built onboarding project and it seems quite cool

class Post
  def simliar_posts
    user.posts.excluding(self)
  end
end

Lets actually think if it useful in a common place

But wait a second... we have a really messy implementation of BROADCAST in ActionCable where we need to filter our own sent messages everytime, and this new friend may look promising to use.
What if we implement a MULTICAST, or even add a parameter to our usual broadcast_to method in ActionCable making it look like this source:

def broadcast(message, exclude_self: true)
  server.logger.debug { "[ActionCable] Broadcasting to #{broadcasting}: #{message.inspect.truncate(300)}" }

  payload = { broadcasting: broadcasting, message: message, coder: coder }
            ActiveSupport::Notifications.instrument("broadcast.action_cable", payload) do
  encoded = coder ? coder.encode(message) : message
    if exclude_self
      server.pubsub.exclude(self).broadcast broadcasting, encoded
    else
      server.pubsub.broadcast broadcasting, encoded
    end
  end
end

THOUGHTS??

ActiveStorage - default conf is wrong?

fedeagripa — Fri, 14 May 2021 17:20:26 +0000

Lately I been working a lot with ActiveStorage and I found that every-time I try to edit my content (images, videos, etc) they are overwritten O_o, yes WHAT?

But if you just change your config to:
config.active_storage.replace_on_assign_to_many = false

Now you have what I understand as a normal behaviour, you can do a standard Update according CRUD.

I believe this was done like this just because it was simple, but do you consider it wrong also?

Reports performance improvement

fedeagripa — Thu, 20 Aug 2020 14:42:18 +0000

Are you tired of fighting with the performance of your reports and overloading your database?

Well, here I bring you a really simple Rails 6 solution!

Use new Rails6 Multiple Databases configuration
To do so you can check my other post
Switch your reports to use the replica database

As an extra you can also use readonly_slow:

ActiveRecord::Base.connected_to(database: { readonly_slow: :replica }) do
  # runs a long query while connected to the +replica+ using the readonly_slow role.
  User.run_a_huge_query
end

Voila, that's all!

Rails 6 - Multiple Databases

fedeagripa — Wed, 19 Aug 2020 19:19:34 +0000

Rails 6.0 came up with this amazing enhancement, but for most people, I'm aware they think that is a new feature.
In my opinion, both are correct, because the actual state of multiple databases before rails 6.0 was not even useful to consider it a completed feature.

Let's dive into Rails < 6 state, Rails 6 introduced changes and the current roadmap.

Rails 5 state

ActiveRecord supports multiple databases, but Rails < 6 doesn't provide a way to manage them.
As said you needed to handle everything (yes, everything) in a really manual way, having to create your own tasks for seeds, db:prepare, db:migrate, etc.
Then you needed to create a sort of generator to handle your secondary database migrations following conventions. And finally, as if you hadn't done enough custom work, create an initializer to config your connection to the new database.

So yes, ActiveRecord supported multiple databases, but it was a complete and real mess you didn't want to get into unless really necessary.

Rails 6.0 state

New stuff

Multiple primary databases and a replica for each

This is amazing, now you can easiliy configure it in your database.yml like this

development:
  primary:
    database: my_primary_database
    user: root
    adapter: sqlite3
  primary_replica:
    database: my_primary_database
    user: root_readonly
    adapter: sqlite3
    replica: true
  animals:
    database: my_animals_database
    user: animals_root
    adapter: sqlite3
    migrations_paths: db/animals_migrate
  animals_replica:
    database: my_animals_database
    user: animals_readonly
    adapter: sqlite3
    replica: true

Check how you can define your migration paths for each database, and how seem to have the power to have multiple adapters (still working on a POC for this assumption).
An example migration with this would be: rails g migration CreateCats name:string --database animals with this output

  Running via Spring preloader in process 97210
    invoke  active_record
    create    db/animals_migrate/20200819181625_create_cats.rb

Automatic connection switching for the model you're working with

You just need to activate it in your middleware for automatic switching:

config.active_record.database_selector = { delay: 2.seconds }
config.active_record.database_resolver = ActiveRecord::Middleware::DatabaseSelector::Resolver
config.active_record.database_resolver_context = ActiveRecord::Middleware::DatabaseSelector::Resolver::Session

You can also manually decide your connection context:

ActiveRecord::Base.connected_to(role: :reading) do
  # all code in this block will be connected to the reading role
end

Automatic swapping between the primary and replica depending on the HTTP verb and recent writes

As we are used to in Rails, this comes standardized:

“If the application is receiving a POST, PUT, DELETE, or PATCH request the application will automatically write to the primary. For the specified time after the write, the application will read from the primary. For a GET or HEAD request, the application will read from the replica unless there was a recent write.“

Rails tasks for creating, dropping, migrating, and interacting with the multiple databases

First big comment, the usual rails db:create will now create both databases, as so the usual rails db:migrate will migrate both databases too.
You need to specify which database you want to work with like rails db:create:primary or rails db:migrate:secondary if you want to just modify one.

So for your custom tasks you may need to also specify the desired database you are working with.

Pending ones

Sharding
Right now there are some gems to accomplish this, so until is integrated onto Rails we should keep using gems (no real deal with it)
Joining across clusters
This is what Rails state:
“Applications cannot join across databases. Rails 6.1 will support using has_many relationships and creating 2 queries instead of joining, but Rails 6.0 will require you to split the joins into 2 selects manually.“

So we just need to wait for rails 6.1!

Load balancing replicas
This seems an interesting feature, so I hope to see upcoming news for this.
Dumping schema caches for multiple databases
Right now this is what is stated:
“If you use a schema cache and multiple databases you'll need to write an initializer that loads the schema cache from your app. This wasn't an issue we could resolve in time for Rails 6.0 but hope to have it in a future version soon“

So seems like a trivial issue to solve in upcoming versions

Rails 6.1 upcoming state

As you may know, rails 6.1 is almost there so I will double-check what was stated to be released for this new version, and what is actually going to be released

Nice open PRs right now:

So the summary would be:

Sharding is now a WIP thing and we may hope to see it live in Rails 6.1
Still waiting for the Joining across clusters (or I missed it in my review)
Still waiting for load balancing
Schema caches are now a thing!

Some personal ideas

I'm a huge fan of non-relational databases, so I would love to see some mixins of MongoDB + Postgres for example. And with this introduced changes I think that the road is prepared enough to start working on a way to properly work with it.
My doubts are more into "Should ActiveRecord really support non-relational databases?" or "Is something more rails work outside ActiveRecord?". Leave your thoughts and I will be more than happy to chat over it :)

Full Stack developer

fedeagripa — Fri, 24 Jul 2020 21:30:14 +0000

Is this an actual role nowadays? Are they real or just unicorns? When are you really full-stack?

We just released a podcast chapter about this at Rootstrap Full Stack podcast - Friendly spoiler, is in Spanish :)

Besides being a company podcast, we want it to be developer friendly (from developers to developers)
I will be happy to hear any opinion/feedback/experiences :)

GROWTH - Data-Driven Decisions

fedeagripa — Fri, 24 Jul 2020 19:42:25 +0000

Have you ever said one of these tricky phrases?

I'm sure this feature is going to rock!
We need this feature before going live, it is a must!
Users will use this for sure!

Well, if you found yourself saying any of those without any numbers that support you, you may probably be making a lot of assumptions.
So is like you are playing roulette, due to lacking data to prove your hypothesis.
Give growth a try! And find out how to move smarter with your development team along with really learning what your users want!

What's GROWTH?

I see growth as a way of working around data analysis based decisions. So first let's explain a bit what data analysis is:

Data analysis is defined as a process of cleaning, transforming, and modeling data to discover useful information for business decision-making. The purpose of Data Analysis is to extract useful information from data and taking the decision based upon the data analysis

You may see that the word data came up a lot, that's not because I want to be redundant but because I want to emphasize it as a really important concept. Nowadays the more data you have the more power you have to make better decisions.

How to start?

As I mentioned before, start gathering data, it doesn't need to be super high-quality data, you will start learning from your users and your business reality and improve step by step.
A simple step you can take at a really low cost is adding some forms and analytics to your landing page. This way you will start getting feedback from users and also start knowing your user's interactions and interests.

First, see an initial approach on how you should approach your changes:

You will start building something as small as possible to lessen the number of mistakes you can make.
Then you measure it by testing it with users since they are the only ones with the truth on whether it will succeed or not.
Finally, learn from your measures and keep building, but now with a clearer idea of what users want.

To plan what to build you can follow this simple process, also to manage each specific change.

Write down your hypothesis based on your business goals
Plan tests on your product to validate your hypothesis
Measure
Verify your numbers against what you thought

The most important step at the end is to make decisions based on your learnings, adjusting your upcoming features/hypothesis based on learnings.

Common mistakes

First and most usual mistake: assuming you know how users will behave

You will probably be wrong, instead of that write a hypothesis and try to prove it. It can be as simple as "I want to prove that I get more sales if I place the BUY button at the top with a brighter color" or more complex like "I think users are tempted to buy if I offer discounts after 10 minutes of looking at items in my store"

Misread data

Actually is really easy to fall on this error, as you have an idea in your mind and naturally, you want it to end up with that being truth.
So my proposal for this is to again write down your ideas based on hypothesis and set up expected metrics for each of them, so you can properly check against something objectively.

Here are some tips to prevent falling into misreading data:

Write down your findings, don't make decisions on the go (just reading data)
Do multiple rounds of data check (like reading something multiple times before releasing)
- First round: check the more granular data
- Second one: try to detect patterns or contradictions between previous deductions
- Third one: take into account the "big picture", you are analyzing data and users under a certain context, so think about how your context may compromise your data
- Last one: remember you are evaluating a subset of your universe, so consider you may have some deviation and so don't make absolute decisions

Think you have finished

This is a continuous delivery process that never ends. User preferences changes and you can always detect new opportunities or tends to look at data.
I see this as a simple process that prevents you to take wrong decisions, so you only can win from using it.

Do I need an engineer?

Actually you don't, but having one will provide you a different perspective from a structured data result mindset. Let's see what does this means...
You as a product owner, sales manager, investor, etc. will probably be the one with the most knowledge about users and your product, but, do you know how to measure your product performance and record your user's interactions over your app? Probably not.
So here is where an engineer can help you:

Adding metrics on your app
Recording user journeys to provide you a better understanding of their experience
Crossing information from different inputs (social media, ads, etc)
Generating reports
Processing data so you can take more time on your business instead of the product development

And honestly depending on the level of expertise of the engineer I can continue providing good reasons to work with one of them.
So my recommendation for you is to look for a well-rounded engineer, not just a developer. That will help you look at your business from more points of view.

Conclusions

Mindset

Be curious, be analytical, and try to validate as much as possible as you introduce changes.

Changes

Changes are good! Make them as much as possible so you learn more, but keep them organized so it doesn't become anarchic.

Organization

"Diversity is a source of wealth" we all know that, so the only problem to deal with is how to work with other roles while keeping an open mindset.
Invest some time explaining your team what you want and why. People understanding what they are doing is way more effective.

ActionText, bringing rich text content management to Rails Core

fedeagripa — Wed, 10 Jun 2020 20:31:26 +0000

ActionText is a new feature developed in Rails 6 that aims to solve managing rich text content on apps on an easy way following conventions. At first sight, this may seem like a trivial and insignificant feature, but you will see that inside of it you have some exciting things that may do your coding easier.

The purpose of this post is to introduce this new feature, explaining the specific case it was build for and the provide a personal opinion about the potential of it.

“Action Text brings rich text content and editing to Rails. It includes the Trix editor that handles everything from formatting to links to quotes to lists to embedded images and galleries. The rich text content generated by the Trix editor is saved in its own RichText model that’s associated with any existing Active Record model in the application. Any embedded images (or other attachments) are automatically stored using Active Storage and associated with the included RichText model.” [1]

But… what actually is this all about?

The most straightforward implementation (and what it was first build for) is to manage content on web apps as you are used in Word (or Open Office) :

This may seem trivial at first sight, but trust me you will have a lot of headaches with the many cases you should consider and the time it will consume. With ActionText you will just spend 10 minutes.

How do I implement it?

# Use ActiveStorage variant
gem 'image_processing'

You need image_processing to deal with blobs automatically, this is another amazing thing provided here!. After running bundle this will generate 3 new tables: action_text_rich_texts, active_storage_attachments, active_storage_blobs.

Your model:

class Post < ApplicationRecord
  has_rich_text :content
end

After running migrations this will just generate a string column on your model, but don’t worry, it will use the previous tables too.

Your controller

def post_params
  params.require(:post).permit(:title, :content)
end

Your view

<div class="field"></div>

And that’s it, you have an app capable of storing chat messages, posts, images and any other rich text implementation you want with just a few lines.

And… what happens if I’m just a backend developer?

You will tend to think that there is just value in has_rich_text :content, because if you actually try to expose the content param your Front-end developer will have to generate something like this:

The solution provided up to now to solve this is to make your API accept attachments markup in canonicalized form (e.g. ) instead of the full Trix-compatible markup (like above). To achieve this you would need Basecamp Doc

Conclusion

This is a handy feature if you are building a full-stack Rails app, and for API development you would need to ask your Front-end developer to provide some specific information, anyway, it seems extremely useful as you are dealing with all content types automatically then.

Last but not less important, this is a feature under development yet so there will be some changes and improvements in the near future.

References

[1] https://github.com/rails/actiontext

Online payments made SIMPLE - How to work with Stripe

fedeagripa — Tue, 09 Jun 2020 16:22:41 +0000

Online payments made SIMPLE - How to work with Stripe

In this blog post, you’ll learn how to start working with Stripe and quickly have fully functioning online payments in your apps.

1) Why Stripe?

Pros

Easy to implement and use
Fast to develop, so your client will be happy
Solves most of your usual payment problems, so you don't lose time or clients (even worst)
Amazing dashboard with a lot of capabilities so your clients financial team can work along with you

Cons

Expensive (high % fee)

2) INSTALLATION

This post assumes you already created a Stripe account and so you have access to dashboard and its configuration.

RAILS

Add these two gems:
- Stripe to achieve the integration
- Stripe Testing to test your integration, you don't want to end up writing lots of mocking classes, right?
Configure your keys & version from the Stripe dashboard

# config/intializers/stripe.rb
Rails.configuration.stripe = {
  publishable_key: ENV['STRIPE_PUBLISHABLE_KEY'],
  secret_key: ENV['STRIPE_SECRET_KEY']
}
Stripe.api_key = Rails.configuration.stripe[:secret_key]

REACT

Add this package Stripe
Configure your App to use the same api key as for rails (make sure it is the same, as you start moving between envs you may forget it). Remember that there is a testing key and a live one.

Add an env file to store your keys

# .env.dev

STRIPE_KEY="pk_test_TYooMQauvdEDq54NiTphI7jx"

Add your Stripe wrapper

import React from 'react';
import { Elements, StripeProvider } from 'react-stripe-elements';

const withStripe = (WrappedComponent) => {
  const Stripe = props => (
    <StripeProvider apiKey={process.env.stripe_key}>
      <Elements
        fonts={[{
          cssSrc: 'https://fonts.googleapis.com/css?family=Roboto:300,300i,400,500,600'
        }]}
      >
        <WrappedComponent {...props} />
      </Elements>
    </StripeProvider>
  );

  return Stripe;
};

export default withStripe;

3) START USING PAYMENTS WITH STRIPE

CREDIT CARDS

REACT - DO YOURSELF A FAVOR AND USE THE EXISTING COMPONENT

I'm not a fan of reinventing the wheel by any means, the design these components provide is more than enough for 99% of the apps you will be building. But if you insist, be prepared to spend 2 weeks dealing with details instead of 2 days.

import {
  CardNumberElement,
  CardExpiryElement,
  CardCVCElement,
  injectStripe
} from 'react-stripe-elements';
import uuid from 'uuid/v1';

/* Your other imports for a usual form */

class BillingForm extends Component {
  constructor() {
    super();
    this.state = {
        cardInputKey: uuid()
      };
    this.onSubmit = this.onSubmit.bind(this);
  }
  async onSubmit(result) {
    const { stripe, submitBilling, shopId, initialValues } = this.props;
    const data = result.toJS();

    /* AT THIS POINT THE CC IS CREATED AT STRIPE AND YOU NEED TO TELL YOUR BACKEND ABOUT IT */
    const { token, error } = await stripe.createToken(decamelizeKeys(data));

    if (error) {
      throw new SubmissionError({
        _error: error.message
      });
    }

    /* HERE WE WERE SUBMITING AND LENDING THE INFO TO THE BACKEND */
    await submitBilling(shopId, camelizeKeys(token), initialValues.get('name'));
  }

  render() {
    /* all your consts */
    return (
      ....
      <form onSubmit={handleSubmit(this.onSubmit)} className="p-3">
        /* The rest of your user profile form */
        /* CC real info */
        <div className="col-lg-3 offset-1">
          <div className="form-group">
            <label className="form-control-label">Card On File</label>
            <div>{brand && last4 ? `${brand} ending in ${last4}` : 'none'}</div>
          </div>
          <div className="form-group">
            <label className="form-control-label">Card Number</label>
            <CardNumberElement key={`cardNumber${cardInputKey}`} className="form-control" />
          </div>
          <div className="form-group">
            <label className="form-control-label">Expiry</label>
            <CardExpiryElement key={`cardExpiry${cardInputKey}`} className="form-control wd-80" />
          </div>
          <div className="form-group">
            <label className="form-control-label">CVC</label>
            <CardCVCElement key={`cardCvc${cardInputKey}`} className="form-control wd-80" />
          </div>
        </div>
      </form>
    )
  }
}

export default injectStripe(reduxForm({
  ...
})(BillingForm));

RAILS - DON'T TRY TO STORE ALL THE INFO (IT'S ILEGAL)

You will tend to store more credit card info that you need. The only info that you need to store in your database (for basic usage) is:

customer_id : Stripe customer identifier that you will store in your User for example
card_id : Stripe card identifier

The token_id you will get from your frontend is a short lived token that is only needed for an atomic operation.

Add a customer_id field to your user (or Shop in next example).
Add a card_id to your user (or Shop in next example).

Now take this service example (Shopify page example):

# app/services/stripe_service.rb

require 'stripe'

class StripeService
  class StripeException < StandardError
  end

  attr_reader :shop

  def initialize(shop)
    @shop = shop
  end

  def add_card(token_id, email, name)
    create_customer(email, name) unless customer.present?
    card = customer.sources.create(source: token_id)
    shop.update!(card_id: card.id)
  end

  def credit_card_info
    card = shop.stripe_token
    customer.sources.retrieve(card) if card
  end

  def update_credit_card(token_id)
    card = customer.sources.create(source: token_id)
    card.save
    card_id = card.id
    customer.default_source = card_id
    customer.save
    shop.update!(card_id: card_id)
  end

  def customer
    customer_id = shop.customer_id
    return unless customer_id.present?

    @customer ||= Stripe::Customer.retrieve(customer_id)
  end

  private

  def create_customer(email, name)
    customer_params = {
      email: email,
      description: "#{shop.name} #{name}"
    }
    @customer = Stripe::Customer.create(customer_params)
    shop.update!(customer_id: @customer.id)
  end
end

And this simple controller:

# app/controllers/api/v1/credit_cards_controller.rb
module Api
  module V1
    class CreditCardsController < Api::V1::ApiController
      helper_method :shop

      def index
        service = StripeService.new(shop)
        @card = service.credit_card_info
        @customer = service.customer
      end

      def create
        StripeService.new(shop).add_card(token_id, email, customer_name) if token_id
        head :no_content
      end

      def update
        begin
          StripeService.new(shop).update_credit_card(token_id)
        rescue StripeService::StripeException => ex
          return render_not_found(ex.message)
        end
        head :no_content
      end

      private

      def shop
        @shop ||= current_shop
      end

      def token_json
        params[:token]
      end

      def token_id
        token_json['id']
      end

      def email
        token_json['email']
      end

      def customer_name
        token_json['name']
      end
    end
  end
end

And that's all! You can start charging your users now!

All fraud detections and customer service actions can be managed directly from Stripe's dashboard.

SUBSCRIPTIONS

To create a subscription you need to define it, then create a product in Stripe (this last one is really clear looking at the dashboard, so I'm not going to explain it)

CREATING THE SUBSCRIPTION

# app/models/subscription.rb
class Subscription < ActiveRecord::Base
  belongs_to :user
  belongs_to :purchase_plan # this can be optional if you have annual or monthly plans for example
  has_many :subscription_items, dependent: :destroy # I'm going to explain this later

  enum status: ['define_your_possible_statuses']
end

In that model you will store attributes like: expires_at, type or even provider if later you want to extend to other providers like PayPal or Apple Pay

Finally to create them on Stripe is quite simple:

# app/services/stripe_service.rb

def create_subscription
  Stripe::Subscription.create(
    customer: customer.id,
    plan: subs_plan_id, # this is the id of your plan (eg: monthly, annual, etc)
    coupon: discount_code # if you have any (check COUPONS section below to understand them in more detail)
  )
end

COUPONS

Coupons are the abstract concept of 30% off for example, when you apply that coupon to a user that's called a discount.
So you should define some discounts on Stripe and store their ids in your database to apply them to users.
There are two types of coupons percentage & fixed amount, and any of them can be one time only or have the capability to be applied multiple times. So when you try to apply a coupon to a subscription, for example, remember that it can fail if you reached the maximum usage number.

Another useful case that is worth mentioning is to apply a coupon to a user, this means that they will have a positive balance for any future invoice (be careful if you charge users with multiple products)

SUBSCRIPTION ITEMS

These are your billing items, so for the case of a web subscription, you will just have 1 subscription item. For specific cases like an amazon cart or any complicated use case (where you have multiple items being added to purchase) is where you have to start considering adding some specific logic to your app.
I won't get really into detail about this, I just wanted to show the general concept behind this, maybe I will write more in detail in a future post.

RENEWALS

Don't overthink it, there is a webhook for most of your use cases. But for this specific need you can configure the following events:

customer.subscription.updated
This event happens every time a susbscription is updated according to this documentation
customer.subscription.deleted
As simple as it sounds, it tells you when a subscription is canceled so you can take the actions needed in your app (possibly disable the associated account)
invoice.payment_succeeded
This is a really important one! It tells us when payment is actually accepted by the credit card provider (some times there can be fraud or the payment could get declined)

WEBHOOKS

There are a lot of them and they will solve most of your problems, the only downcase is the headache trying to understand which exactly to use.
I'm sorry to disappoint you if you reached here trying to answer this question but up to now I only know this page that explains the different existing webhooks and what they do. The other option is when you go to create a webhook from the developer's Stripe dashboard, they explain a bit more in detail what each event does.

4) SPECIAL RECOMMENDATIONS FOR FURTHER PAYMENT IMPLEMENTATION

Keep these Stripe documentation pages as your friends:

Sometimes there are two or even three ways of solving a problem, so consider this and take your time to analyze each requirement properly before you start coding.

5) CONCLUSIONS

You can easily add online payments to your app and test it in just 1 week (or so), that's amazing! The other amazing thing is that you can start managing most of the daily based situations like fraud of disputes just from the dashboard (you don't need to keep coding).

The difficult part of this is when you start adding more concrete and detailed transactions and supporting multiple transfer types (like bank account transfers instead of just Visa or MasterCard). So if you liked this post and want to know more don't hesitate to leave some comments asking for it! or even text me :)

Active Admin 2FA with OneLogin

fedeagripa — Mon, 08 Jun 2020 23:40:00 +0000

ActiveAdmin 2FA with OneLogin

In this blog post, you’ll learn how to configure two factor authentication with OneLogin for your admin panel.

1) Some key concepts to security

SLO (Single log out): SLO is a process that allows users to be logged out in one place and spread it over multiple applications
SSO (Single sign in): SSO is a process that allows users to authenticate into multiple services after logging into a primary service
Callback URL: It is a local URL in your app where a third party auth provider sends you auth data like confirmations or logout requests

2) How to start implementing two factor authentication?

First take a look at this lovely gem, you will notice that all the examples are for the User class, but don't worry we will show some examples for admin specifically

The specific lines you need to add are just a few ones:

First add the devise saml_authenticable module from our choosen gem, this will inject most of the needed capabilities.

# app/models/admin_user.rb

devise :recoverable, :rememberable, :trackable, :validatable, :lockable, :saml_authenticatable

Then tell saml_authenticable module which SAML fields you want to map to your model ones

# config/attribute-map.yml

"urn:mace:dir:attribute-def:email": "email"

Add some configuration to your devise initializer to configure the communication between your third party provider and devise.
You can customize the named routes generated in case of named route collisions with other Devise modules or libraries. Set the saml_route_helper_prefix to a string that will be appended to the named route.
If saml_route_helper_prefix = 'saml' then the new_user_session route becomes new_saml_user_session

# config/initializers/devise.rb

config.saml_route_helper_prefix = 'saml'
callback = Rails.env.development? ? 'http://localhost:3000' : ENV['SAML_CALLBACK_ADDRESS']
# SAML configuration
config.saml_create_user = true
config.saml_update_user = true
config.saml_default_user_key = :email
config.saml_session_index_key = :session_index
config.saml_use_subject = true
config.idp_settings_adapter = nil
config.saml_configure do |settings|
  settings.assertion_consumer_service_url     = "#{callback}/admin/saml/auth"
  settings.assertion_consumer_service_binding = "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
  settings.name_identifier_format             = "urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
  settings.issuer                             = "#{callback}/admin/saml/metadata"
  settings.authn_context                      = ""
  settings.idp_slo_target_url                 = "https://company.onelogin.com/trust/saml2/http-redirect/slo/#{Rails.env.development? ? '1234' : ENV['SLO_TARGET']}"
  settings.idp_sso_target_url                 = "https://company.onelogin.com/trust/saml2/http-post/sso/#{Rails.env.development? ? 'you_sso_string' : ENV['SSO_TARGET']}"
  settings.idp_cert_fingerprint               = Rails.env.development? ? 'your_cert_fingerprint' : ENV['IDP_CERT_FINGERPRINT']
  settings.idp_cert_fingerprint_algorithm     = 'http://www.w3.org/2000/09/xmldsig#sha256'
end

Finally, we need to modify devise to use our new login strategy. To achieve this we will modify session management so it redirects to our third party provider like this:

# app/controllers/admin_users/sessions_controller.rb

module AdminUsers
  class SessionsController < Devise::SessionsController
    # As you are overwriting devise session controller you need this to allow to login with user & pass (dev mode)
    prepend_before_action :require_no_authentication, only: [:new, :create]

    layout 'active_admin_logged_out'
    helper ::ActiveAdmin::ViewHelpers

    def new
      unless Rails.env.development? || Rails.env.test?
        return redirect_to :new_saml_admin_user_session
      end

      super
    end
  end
end

# config/initializers/active_admin_devise.rb
module ActiveAdmin
  module Devise
    def self.controllers
      {
        sessions: "admin_users/sessions",
        passwords: "active_admin/devise/passwords",
        unlocks: "active_admin/devise/unlocks",
        registrations: "active_admin/devise/registrations",
        confirmations: "active_admin/devise/confirmations"
      }
    end

    def self.controllers_for_filters
      [
        ::AdminUsers::SessionsController,
        SessionsController,
        PasswordsController,
        UnlocksController,
        RegistrationsController,
        ConfirmationsController,
      ]
    end
  end
end

Well.... not really, sorry for getting you excited ¯\(ツ)/¯

As you can see in the initializer there are some conditionals for development, that's because there is no dev out there that wants to do a 2FA every time they want to access ActiveAdmin locally.
So we still need to add some code to conditionally enable 2FA depending on the environment, and a flag (because we don't want to block access to admin if something happens to OneLogin also)

We need to check:

Usual admin login page works in development
Turning the feature off uses the old admin login and it works
How logout works

To perform the first two points I ended up adding the next lines to our overridden sessions_controller, seems that they are lost from super as you override it

# app/controllers/admin_users/sessions_controller.rb

prepend_before_action :require_no_authentication, only: [:new, :create]
prepend_before_action :allow_params_authentication!, only: :create
prepend_before_action :verify_signed_out_user, only: :destroy
prepend_before_action(only: [:create, :destroy]) { request.env["devise.skip_timeout"] = true }

How logout works

At this point you have 3 options to logout:

destroy your app session
destroy saml session
force logout from your third party auth partner

For this specific case, we needed to perform the first one only, because logging someone out of OneLogin means they will be logged out of a lot of apps, and that was not desired.
Actually it was a pain in the neck to do this, because devise_saml_authenticable gem adds routes using class_eval approach directly to Devise engine, leaving you with almost no way to configure which routes you really want or not. You will be asking yourself Why would I like to remove a route?, well... that's because at this point you have 2 admin/logout routes in your app, and we know this is not a good practice at all.
I ended up with this solution as the "cleanest":

# config/initializers/devise.rb

ActionDispatch::Routing::Mapper.class_eval do
  protected
  def devise_saml_authenticatable(mapping, controllers)
    if ::Devise.saml_route_helper_prefix
      prefix = ::Devise.saml_route_helper_prefix
      resource :session, only: [], controller: controllers[:saml_sessions], path: '' do
        get :new, path: 'saml/sign_in', as: "new_#{prefix}"
        post :create, path: 'saml/auth', as: prefix
        get :metadata, path: 'saml/metadata'
        match :idp_sign_out, path: 'saml/idp_sign_out', as: "idp_destroy_#{prefix}", via: [:get, :post]
      end
    else
      resource :session, only: [], controller: controllers[:saml_sessions], path: '' do
        get :new, path: 'saml/sign_in', as: 'new'
        post :create, path: 'saml/auth'
        get :metadata, path: 'saml/metadata'
        match :idp_sign_out, path: 'saml/idp_sign_out', via: [:get, :post]
      end
    end
  end
end

You can add last lines at the end of your devise initializer, or even better create a new initializer that run after devise one.

3) Conclusions

A project that was estimated to last over a month or so, ends up tacking only 2 weeks because we found a great gem that solves most of our problems (besides some gem implementations not being done in the best way).
Work does not end here, besides sharing this I'm planning to contributing back to this awesome gem to improve its quality and support missing points we mentioned. And my goal with this post besides showing how to solve a security problem is to encourage others to contribute back when you see you can do it, without contributions like this, this gem wouldn't exist and neither would this post.