Mi Curro

Integración con Moneybookers con formulario HTML

2011-03-18T13:17:00.000-07:00

¿Quieres integrar una pasarela de pagos en tu aplicación rails? ¿Prefieres integrar con moneybookers en lugar de la típica pasarela de paypal? Pues hay dos formas: con un formulario html que describe moneybookers o con una gema para realizar el submit del formulario desde nuestro servidor rails. Ambas soluciones utilizan activemerchant.

Antes de empezar a tirar código, date de alta en moneybookers como "merchant", es decir, como vendedor. Créate también una cuenta como comprador. Luego les mandas un mail y les dices que hagan que esas cuentas sean de prueba, para que puedas empezar a integrar. Si necesitas pagos recurrentes, también tendrás que mandarles un mail. Si sólo vas a utilizar unos determinados tipos de pago, tendrás que enviarles un mail para que te habiliten el fixed split gateway... En resumen, todo por mail... y un poco lento.

Parece ser que no permiten pagos recurrentes para usuarios que no tengan cuenta de comprador en moneybookers: FAIL.

Moneybookers describe en su manual y en su página de pruebas, el contenido del formulario que se debe enviar a su servidor. Así mismo, activemerchant tiene un módulo de "integraciones" que permite generar formularios de este tipo para varias pasarelas.

En cuanto a los parámetros, hay que destacar los siguientes:

return_url_target y cancel_url_target permiten pasar el nombre de un iframe para incrustar el formulario de moneybookers en tu aplicación.
Una vez realizado el pago, moneybookers llama a la dirección especificada en notify_url para que le indiquemos si el pago ha sido validado por nosotros.
hide_login permite ocultar el formulario de login en moneybookers

Formulario HTML:

# app/helpers/payment_helper.rb

module PaymentsHelper
  include ActiveMerchant::Billing::Integrations::ActionViewHelper

end

# app/views/payments/new.html.erb

<iframe id="mb-iframe" 
        name="mb-iframe" 
        frameborder="no" 
        style="height: 600px; width:500px;" 
        scrolling = "auto">
</iframe>

<% payment_service_for @payment.transaction_id, "paytoemail@merchant.com",
                                                :amount => @payment.amount,
                                                :currency => 'EUR',
                                                :service => :moneybookers,
                                                :html => { :id => 'mb-form',
                                                           :target => 'mb-iframe' } do |service| %>

<% service.customer :first_name => @payment.owner.first_name,
                      :last_name => @payment.owner.last_name,
                      :email      => @payment.owner.email %>

<% service.billing_address :city     => @payment.owner.city,
                             :address1 => @payment.owner.street1,
                             :address2 => @payment.owner.street2,
                             :zip      => @account.owner.postal_code,
                             :country => @account.owner.country.code %>

<% service.notify_url "http://localhost:3000/payments/notify" %>
<% service.return_url url_for(:only_path => false, :action => 'done', :merchant_id => "2200220022") %>
<% service.cancel_return_url "http://localhost:3000/payments" %>

<%= hidden_field_tag :return_url_target,     "mb-iframe" %>
<%= hidden_field_tag :cancel_url_target,     "mb-iframe" %>
<%= hidden_field_tag :language,              "ES" %>
<%= hidden_field_tag :hide_login,            "1" %>
<%= hidden_field_tag :detail1_description,   "Bach Complete Collection" %>
<%= hidden_field_tag :detail1_text,          "#{@payment.amount} €" %>

<%= submit_tag "Pagar" %>

<% end %>

# app/controllers/payment_controller.rb
def notify
http_status = 500
notify = ActiveMerchant::Billing::Integrations::Moneybookers::Notification.new(request.raw_post)

if notify.acknowledge(CONFIG['moneybookers']['secret'])
    begin
      if notify.complete?
        payment = Payment.find_by_transaction_id(notify.transaction_id)

        if notify.posted_amount.to_f == payment.amount.to_f
          payment.status = notify.status
          payment.save

          http_status = 200
        else
          logger.error("Failed to verify MoneyBookers's notification parameters, please investigate")
        end
      else
        logger.error("Failed to verify MoneyBookers's notification, please investigate")
      end
    rescue Exception => ex
      logger.error(ex.message)
    end
else
    logger.error("Failed to verify MoneyBookers's notification, please investigate")
end

render :nothing => true, :status => http_status
end

Lo malo de esta opción es que el formulario está visible en el navegador del cliente, y se podría modificar el contenido. La mejor opción es utilizar el parámetro "prepare_only", que permite enviar toda esta información desde el servidor rails, y moneybookers nos contesta con un identificador de sesión en su site, así que ya puedes entrar en https://www.moneybookers.com/app/payment.pl?sid=<id de sesion> y ahí ya está toda la información necesaria. Así el navegador no tiene ningún tipo de información "sensible". Este método lo describiré en el siguiente post.

Tablas particionadas

2010-11-30T06:56:00.000-08:00

Si tienes una tabla con varios millones de registros y sabes de antemano que se va a consultar por periodos mensuales, puedes particionar la tabla por años y meses. Así cuando hagas consultas, sólo utilizarás la partición correspondiente y mejorará el rendimiento.

Al particionar por los valores de un determinado campo, es obligatorio tener dicho campo como parte de la primary key de la tabla.

A continuación una migración para crear una tabla particionada por meses y años:

class CreateHistoryAlerts < ActiveRecord::Migration

FIRST_YEAR = 2010
LAST_YEAR = 2020

def self.up
    create_table :history_alerts do |t|
      t.integer :agent_id,          :references => nil
      t.integer :alert_type_id,         :references => nil
      t.integer :country_id,            :references => nil
      t.string :reason
      t.boolean :read

      t.timestamps
    end

    sql = "ALTER TABLE `history_alerts` drop primary key, add primary key(id, created_at)"
    execute(sql);

    sql = "ALTER TABLE `history_alerts` PARTITION BY RANGE (YEAR(created_at)) \
           SUBPARTITION BY HASH (MONTH(created_at)) \
           ("

    for year in (FIRST_YEAR..LAST_YEAR)
      sql += "PARTITION p_#{year} VALUES LESS THAN (#{year}) \
              (SUBPARTITION s_jan_#{year}, \
               SUBPARTITION s_feb_#{year}, \
               SUBPARTITION s_mar_#{year}, \
               SUBPARTITION s_apr_#{year}, \
               SUBPARTITION s_may_#{year}, \
               SUBPARTITION s_jun_#{year}, \
               SUBPARTITION s_jul_#{year}, \
               SUBPARTITION s_aug_#{year}, \
               SUBPARTITION s_sep_#{year}, \
               SUBPARTITION s_oct_#{year}, \
               SUBPARTITION s_nov_#{year}, \
               SUBPARTITION s_dec_#{year}),"
    end
    sql += "PARTITION p_all VALUES LESS THAN MAXVALUE \
            (SUBPARTITION s_jan_all, \
             SUBPARTITION s_feb_all, \
             SUBPARTITION s_mar_all, \
             SUBPARTITION s_apr_all, \
             SUBPARTITION s_may_all, \
             SUBPARTITION s_jun_all, \
             SUBPARTITION s_jul_all, \
             SUBPARTITION s_aug_all, \
             SUBPARTITION s_sep_all, \
             SUBPARTITION s_oct_all, \
             SUBPARTITION s_nov_all, \
             SUBPARTITION s_dec_all))"
    execute(sql);
end

def self.down
    drop_table :history_alerts
end
end

Tabs On Rails

2010-06-07T23:48:00.000-07:00

Ya estaba cansado de ver toda la morralla de código en las vistas para pintar las pestañas, y al final he probado el plugin tabs_on_rails (http://code.simonecarletti.com/projects/tabsonrails/wiki)

Mucho más limpio y sencillo. En las vistas solemos tener un partial que pinta las pestañas. Aquí podemos poner algo como:

<% tabs_tag(:builder => MyTabBuilder) do |tab| %>
  <% if logged_in? %>
    <%= tab.home I18n.t('tabs.home'), member_dashboard_path %>    <%= tab.members I18n.t('tabs.members'),  member_profiles_path %>
  <% else %>
    <%= tab.home I18n.t('tabs.home'), root_path %>
    <%= tab.members I18n.t('tabs.members'), profiles_path %>
  <% end %>

<% end %>

Si quieres personalizar la forma de pintar las pestañas, puedes crear tu propio Builder en el directorio lib, por ejemplo:

class MyTabBuilder < TabsOnRails::Tabs::Builder
def tab_for(tab, name, options)
    cls = (current_tab?(tab) ? 'selected' : '')
    @context.content_tag(:li) do
      @context.link_to(name, options, :class => cls)
    end
end
end

Ahora en los controladores, eliges la pestaña que quieres seleccionar, pudiendo incluir lógica o diferenciar por action:

class ProfilesController < ApplicationController
  set_tab :home
  set_tab :members, :if => :my_profile?

  set_tab :posts, :only => %w(list edit)

...

  private

  def my_profile?
    !params[:id].blank? && params[:id].to_i == current_user.id
  end

end

merge_conditions

2010-02-11T09:36:00.000-08:00

Más de una vez hemos tenido que crear una query dinámicamente, en función de los parámetros que recibimos.

Una opcion es mantener el string de la condicion y una hash con los parametros:

str_conditions => "email is not null"

h_conditions = {} 

if !params[:group_ids].blank?

  str_conditions += " and group_id in (?)"

  h_conditions[:group_ids] = params[:groups_ids] 

end

if !params[:manager_id].blank?

  str_conditions += " and manager_id = ?"

  h_conditions[:manager_id] = params[:manager_id]

end

User.find :all, :conditions => [str_conditions, h_conditions]

Pero se engorrina bastante, con tanto "+=" y con tanto "and" y con tanta hash.

Otra opcion más clara es tener cada grupo de condiciones separado, y utilizar luego el metodo merge_conditions de ActiveRecord::Base.

c1=(params[:group_ids].blank?) ? [] : ["group_id in (?)", params[:groups_ids]]

c2=(params[:manager_id].blank?) ? [] : ["manager_id = ?", params[:manager_id]]

User.find :all, :conditions => merge_conditions("email is not null", c1, c2)

Configuracion de las aplicaciones

2010-01-26T04:35:00.000-08:00

Para definir los parámetros configurables de la aplicación, utilizo lo siguiente: un fichero config/config.yml y un initializer config/initializers/local_config.rb:

En el config.yml, mantengo en formato yaml los valores de los parámetros:

development:

  authentication: "restful" 

manager:

    activities:

      activate: "Activate"

create: "Create"

En local_config.rb:

APP_CONFIG = YAML.load_file("#{RAILS_ROOT}/config/config.yml")[RAILS_ENV]

Así, desde cualquier punto de la aplicación puedo hacer:

if APP_CONFIG['authentication'] == 'restful'

...

end

lst = APP_CONFIG['manager']['activities']

que devolveria una hash con:

{"create"=>"Create", "activate"=>"Activate"}

Formularios personalizados

2010-01-25T03:54:00.000-08:00

Tienes que pintar siempre el mismo tipo de formulario en la aplicacion? Por ejemplo, tienes que pintar siempre una etiqueta al lado del input?

Tienes un formulario del siguiente estilo:

<% form_for :user do |f| %>
<fieldset>
    <p>
      <label>Login</label><br/>
      <%= f.text_field :login %>
   </p>
    <p>
      <label>Password</label><br/>
      <%= f.password_field :password %>
   </p>
</fieldset>
<% end %>

Quedaría más limpio así:

<% form_for :user, :builder=>LabeledFormBuilder do |f| %>
<fieldset>
     <%= f.text_field :login, :label=>"Login" %>
     <%= f.password_field :password, :label=>"Password" %>
</fieldset>
<% end %>

Todo lo que tienes que hacer es crearte una clase en app/builders:

class LabeledFormBuilder < ActionView::Helpers::FormBuilder

  helpers = field_helpers +
            %w{date_select datetime_select time_select} +
            %w{collection_select select country_select time_zone_select} -
            %w{hidden_field label fields_for} # Don't decorate these

  helpers.each do |name|
    define_method(name) do |field, *args|
      options = args.last.is_a?(Hash) ? args.pop : {}
      label = label(field, options[:label], :class => options[:label_class])
      @template.content_tag(:p, label +'
' + super)  #wrap with a paragraph 
    end
  end

end

y añadir a tu config/environment.rb:

config.load_paths += %W( #{RAILS_ROOT}/app/builders)

Si quieres que por defecto todos tus formularios usen este builder, inicializa en application_helper o en algun initializer:

ActionView::Base.default_form_builder = LabeledFormBuilder

Controllers y Presenters

2010-01-25T00:31:00.000-08:00

Cuando nos queremos dar cuenta, tenemos los controladores llenos de código y empiezan a ser pesados y difíciles de mantener. He visto que hay un patrón de diseño que permite mantener toda esta lógica "sobrante" en otra clase, y dejar en los controladores sólo la funcionalidad de recuperar datos de los modelos y decidir el flujo de la navegación. A este patrón lo llaman Presenter.

Consiste en crear una clase donde se haga toda la recogida de datos que se hace en los controladores. Por ejemplo, antes tenia un controlador con esta acción:

def show

  @profile = Profile.active.find(params[:id])
  @friends = @profile.friends.first 12
  @recommended_profiles = @profile.recommended(:limit => 12)
  @graffities = @profile.graffities.all(:limit => 12)
  Comment.preload_wall_associations(@graffities)
 

  store_location
 

  respond_to do |format|
    format.html # show.html.erb
    format.xml { render :xml => @profile }
  end
end 

Los hay peores, pero esto se puede sustituir por:

def show
    @presenter = ProfilePresenter.new(params)
    store_location

    respond_to do |format|
      format.html # index.html.erb
      format.xml { render :xml => @presenter }
    end
end

Como se ve, en ProfilePresenter dejamos toda la lógica de recogida de datos.

class ProfilePresenter

  def initialize(params)
    @presenter_params = params
  end
  
  def profile
    @profile ||= Profile.active.find(@presenter_params[:id])
  end

  def friends
...

end

  def recommended

...

end

  def graffities

...

end

end

Asi, en las vistas, podemos utilizar @presenter.profile o @presenter.friends, etc. y dejamos los controladores claros y limpios.

Estos presenters pueden dejarse en el directorio app/presenters, por ejemplo. No te olvides de añadir a config/environment.rb la linea:

config.load_paths += %W( #{RAILS_ROOT}/app/presenters)

HTTPS POST

2009-12-17T08:47:00.000-08:00

Hace poco he tenido que hacer submit HTTPS contra otra web desde una aplicación Rails, utilizando un el método POST. El código es el siguiente:

    http = Net::HTTP.new("https://www.otraweb.com", 443)

    http.use_ssl = true

    path = "/login"

    # GET request -> so the host can set his cookies

    resp, data = http.get(path, nil)

    cookie = resp.response['set-cookie']

    # POST request -> logging in

    data = "#{login=#{@username}&password=#{@password}"

    headers = {

        'Cookie' => cookie,

        'Content-Type' => 'application/x-www-form-urlencoded'

}

    resp, data = http.post(path, data, headers)

en resp.code tendremos el código HTTP de error, y en data el HTML de la petición resultante.

Limitación de tamaño en el plugin Spreadsheet

2009-08-25T01:14:00.000-07:00

Exportando datos a excel con el plugin spreadsheet he visto que hay una limitación de tamaño, que impide generar ficheros de más de 7 megas.

Buscando y rebuscando por ahí, he encontrado un parche que lo soluciona perfectamente. Tendrás que instalar la gema ruby-ole para que funcione:

sudo gem install ruby-ole

y modificar el código del fichero workbook.rb:

require 'rubygems'
require 'ole/file_system'


  def store_ole_file
#      OLEWriter.open(@file){ |ole|
#         ole.set_size(@biffsize)
#         ole.write_header
#         ole.print(@data)
#         @worksheets.each{ |sheet|
#            ole.print(sheet.data)
#         }
#      }
     Ole::Storage.open @file, 'wb+' do |ole|
        ole.file.open 'Book', 'w' do |f|
           f.write @data
           @worksheets.each { |sheet| f.write sheet.data }
        end
     end
  end

Autenticación contra Radius

2009-08-05T07:12:00.000-07:00

Después de mucho buscar y mucho probar, he conseguido validar contra un servidor Radius de un cliente.

Partiendo de la libreria http://rubyforge.org/projects/ruby-radius/, y con un tcpdump esnifando paquetes UDP, al final he conseguido validar.

He tenido que modificar el fichero auth.rb de la libreria:

-- attr_reader :@packet
++ attr_reader :packet

y en packet.rb, en el metodo "each":

-- @attributes.each_pair {
-- |key, value|
-- yield(key, value)
-- }

++ sorted_attributes = @attributes.keys.sort_by{|item| ++@dict.attr_num(item)}
++ sorted_attributes.each{|item|
++ key = item
++ value = @attributes[key]
++
++ yield(key, value)
++ }

para que se envien ordenados los atributos del paquete Radius.

Ahora puedes hacer una clase como:

require 'radius/auth'

class RadiusAuthentication
def initialize(hostname, secret)
@hostname, @secret = hostname, secret
@dictionary = File.join(File.dirname(__FILE__), 'dictionary')
end

def authenticate(username, password, nasip=nil, timeout=nil)
nasip = nasip || '127.0.0.1'
timeout = timeout || 10
rad = Radius::Auth.new(@dictionary, @hostname, nasip, timeout)
return rad.check_passwd(username, password, @secret)
end
end

y en tu código de aplicación:

rad = RadiusAuthentication.new(RADIUS_SERVER, RADIUS_SECRET)
success = rad.authenticate(login, password)

Y así validas la password contra el servidor Radius. Utiliza tcpdump para ver los paquetes UDP enviados y recibidos:

tcpdump udp and port 1812 -vvv

Actualizar a Rails 2.3

2009-07-23T01:04:00.001-07:00

He tenido que actualizar algunas aplicaciones de Rails 1.1.6 a la version 2.3.

La forma más rápida y menos dolorosa, para que funcione todo, aunque no sea una aplicación REST y uses ajax_scaffold, es la siguiente:

instalar rails 2.3:

gem install rails -v=2.3.2 --source=http://gems.rubyonrails.org

renombrar application.rb por application_controller.rb

mv application.rb application_controller.rb

reemplazar el environment.rb por uno nuevo de la rails 2.3
reemplazar el boot.rb por uno nuevo de la rails 2.3

tendrás que reinstalar algunos plugins, e instalar algunos nuevos como classic_pagination para mantener la paginación original, y render_component:

ruby script/plugin install git://github.com/masterkain/classic_pagination.git
ruby script/plugin install git://github.com/lackac/render_component.git -r rails-edge

en las vistas, sustituir todos los:
<%= form_tag ... %>
...
<%= end_form_tag %>

por:
<% form_tag ... do %>
...
<% end %>

lo mismo para los <%= form_remote_tag ... %>

sustituir en vistas y controladores las variables @params y @flash por params y flash

sustituir todas las llamadas a Inflector por ActiveSupport::Inflector

actualizar a la versión nueva de prototype

si tenias mensajes de error de activerecord traducidos en config/initializers/active_record_error_messages.rb, tendrás que hacer lo siguiente:

rm config/active_record_error_messages.rb
vi config/i18n.rb

este fichero contiene:

I18n.load_path += Dir[ File.join(RAILS_ROOT, 'config', 'locales', '*.{yml}') ]
I18n.default_locale = "es" # default language

y en config/locales crear es.yml:

"es":
activerecord:
errors:
templates:
header:
one: "Error: el objeto {{model}} no se ha podido guardar"
other: "{{count}} no se permite guardar {{model}}"
body: "Ha habido problemas con los siguientes campos:"
messages:
accepted: "debe ser aceptado"
blank: "no puede estar en blanco"
confirmation: "no coincide con la confirmación"
...

SQLServer y Ruby

2009-07-22T02:34:00.000-07:00

Después de probar la conexion ODBC contra SQLServer desde Ubuntu, nos queda conectarnos desde rails. Estoy hablando de rails 2.3.2.

Tienes que instalar las siguientes gemas (a la derecha pongo la version que he probado):

sudo gem install activerecord-sqlserver-adapter (2.2.19)
sudo gem install dbd-odbc (0.2.5)
sudo gem install dbi (0.4.2)

Tambien tienes que instalar la libreria odbc de ruby:

sudo apt-get install libdbd-odbc-ruby

Creas una conexion en database.yml:

sqlserver_development:
adapter: sqlserver
mode: odbc
dsn: MISERVIDOR
username: david
password: david

Creas un modelo en app "mi_prueba.rb" con lo siguiente:

class MiPrueba < ActiveRecord::Base
establish_connection("sqlserver_development")
end

Puedes probar en la consola con:

MiPrueba.find :first

SQLServer y Ubuntu

2009-07-20T03:50:00.000-07:00

Acabo de conectarme con SQL Server desde Ubuntu.

Hay que instalar los siguientes paquetes:

sudo apt-get install unixodbc unixodbc-dev freetds-dev sqsh tdsodbc

Editar el fichero /etc/freetds/freetds.conf y añadir las siguientes lineas:

[MISERVIDOR]
host = 192.168.1.36
port = 2301
tds version = 7.0

el valor de "tds version" varía en función de la versión de sqlserver que se esté usando. En mi caso es un SQLExpress 2005, asi que "tds version" tiene que ser 7.0. Podeis consultar las versiones aqui:

http://www.freetds.org/userguide/choosingtdsprotocol.htm

En el fichero /etc/odbc.ini:

[MISERVIDOR]
Driver = FreeTDS
Description = ODBC connection via FreeTDS
Servername = MISERVIDOR
Database = prueba_development
Trace = No
UID = david
pwd = david

He tenido problemas porque el SQL Server del que dispongo es una version SQLExpress 2005, que no admite conexiones remotas por defecto. En el panel de control de SQL Server Configuration Manager, hay que habilitar las conexiones remotas.

Si no se accede por el browser de nombres de SQLServer, tienes que definir un puerto en SQL Server Configuration Manager => Protocols for SQLExpress => TCP/IP, en "IP All" => TCP Dynamic Ports. Ahí he definido el puerto 2301, que es el que aparece en el fichero /etc/freetds/freetds.conf.

Para probar la conexion basta con ejecutar:

sqsh -S MISERVIDOR -U david -P david

Si aparece ">1" es que te has conectado. Ahora puedes ejecutar:

use prueba_development
go
select * from mitabla
go

Con la utilidad iodbcadm-gtk, tambien puedes crear el dsn. Primero tienes que definir el driver, diciendole que el fichero del driver es:
/usr/lib/odbc/libtdsodbc.so

y el fichero de setup es:
/usr/lib/libtdsS.so

Luego defines el dsn con ese driver y pruebas la conexion.