Autenticación y Seguridad en CRUD de Posts en Rails

Clase 24 de 33 • Curso de Creación de APIs con Ruby on Rails

Resumen

¿Cómo manejar la autenticación en los métodos de creación, actualización y visualización?

La importancia de la autenticación en aplicaciones web no puede subestimarse, particularmente cuando se trata de operaciones como crear, actualizar o visualizar elementos. En este contexto, aprender a verificar si un usuario está autorizado para realizar estas acciones es crucial. Aquí exploraremos cómo implementar y mejorar las funcionalidades de autenticación para garantizar que solo los usuarios autorizados puedan llevar a cabo estas operaciones en el controlador de publicaciones.

¿Qué consideraciones hay para el método de creación?

Asociación directa con el usuario autenticado: Para que una publicación se cree correctamente, debe estar asociada al usuario que está actualmente autenticado. Esto significa que no deberíamos recibir un user ID arbitrario desde el cliente, sino utilizar el current user ya configurado en el método autenticate_user.
Uso del modelo de relación: En el modelo User, se debe definir que un usuario tiene muchas publicaciones (has_many :posts). Así, puedes utilizar métodos de asociación para crear publicaciones pertenecientes al usuario actual, como current_user.posts.create(params).

¿Cómo se verifica el propietario de una publicación en el método de actualización?

Validar la propiedad de la publicación: Al actualizar, es esencial verificar que la publicación pertenece al current_user. Utilizando current_user.posts.find(params[:id]), nos aseguramos de que solo pueda modificarse si es propiedad del usuario que está autenticado.
Revisión de parámetros de actualización: Aunque no se menciona un cambio directo en los parámetros, es bueno asegurarse que se están enviando y validando los parámetros correctos para la actualización.

¿Qué lógica implementar en el método de visualización?

Verificación de acceso: Aunque no es necesario autenticar al usuario para visualizar una publicación, debemos verificar su estado de publicación. Si el post es público, entonces se puede renderizar sin más. En caso contrario, se debe:
- Comprobar si hay un current user.
- Verificar que la publicación pertenece al current user.
Manejo de errores: Si ninguna de las condiciones se cumple, debemos renderizar un estado 404 Not Found, indicando que la publicación no está disponible para el usuario.

¿Cómo solucionar errores comunes en las pruebas?

Al correr pruebas de integración para verificar la funcionalidad, pueden surgir errores que necesitan ser depurados:

Diferencia de tipo en identificadores: Asegúrate de que tu prueba no espere un símbolo (:id) cuando el payload entrega un string ("id"). Utiliza el método with_indifferent_access para permitir el acceso flexible a valores de hash como símbolos o strings.
Depuración de métodos no definidos o errores de argumento: Asegúrate de que los métodos sean llamados correctamente y que los argumentos requeridos estén bien estipulados. Por ejemplo, si se espera un método atributo, pero se invoca como atributos, seguramente arrojará un error.

¿Qué sigue después de implementar la lógica?

Aunque ya hemos implementado la lógica dentro del controlador para gestionar la autenticación y autorización en create, update, y show, es crucial escribir pruebas para verificar los casos de creación y actualización específicamente. Estas pruebas garantizarán que la lógica implementada funcione según lo esperado, brindando confianza en la robustez y seguridad del sistema. Así que, manos a la obra en la siguiente clase. ¡Sigue creciendo en tu aprendizaje!

Armando Guzman

student•

En PostsController.rb:24 se escribió mal “Current.user.id” en el cursor aparece “Curen.user.id”…

Emilio Borraz Ortega

student•

El regex propuesto aquí acepta cadenas que inician con cualquier texto: Ejemplo:

'xyzBearer z'.match(token_regex) # hace match

Esto se puede evitar validando el inicio y fin de cadena:

new_token_regex = /^Bearer (\w+)$/

Mark Harmsen

student•

¿El método "finb_by_auth_token" de User está definido?

Alexei Teófilo Mamani Coaquira

student•

Exacto por detrás lo que sucede es que cada clase se puede controlar si un metodo no existe, entonces justo en ese momento es donde se hacen estos metodos de acuerdo a cada atributo de cada clase.

Victor Manuel Franco Cañon

student•

HashWithIndifferentAccess

Este es un muy buen articulo sobre “HashWithIndifferentAccess”

Que la magia que hace es convertir cualquier clave en formato “símbolo” en una cadena para luego poder acceder a la informacion que estamos solicitando.

Conceptos extraídos de:

http://codefol.io/posts/Deep-Rails-Understanding-HashWithIndifferentAccess-Understanding-the-Params-Hash/

Leonardo Valdivieso

student•

El debug no fue muy claro, hay otra forma de encontrar el error?

Jhonnatan Alexander Casas Leon

student•

me salen 4 errores y no 3 como en el video

private_posts_spec.rb

require "rails_helper"

RSpec.describe "Posts with Authentication", type: :request do
  let!(:user) { create(:user) }
  let!(:other_user) { create(:user) }
  let!(:user_post) { create(:post, user_id: user.id) }
  let!(:other_user_post) { create(:post, user_id: other_user.id, published: true) }
  let!(:other_user_post_draft) { create(:post, user_id: other_user.id, published: false) }
  let!(:auth_headers) { { 'Authorization' => "Bearer #{user.auth.token}" } }
  let!(:other_auth_headers) { { 'Authorization' => "Bearer #{other_user.auth.token}" } }

  describe "GET /posts/{id}" do
    context 'with valid auth' do
      context 'when requisting others author post' do
        context "when post is public" do
          before {get "/posts/#{other_user_post.id}", headers: auth_headers }

            context "payload" do
              subject { payload }
              it { is_expected.to include(:id) }
            end
            context "response" do
            subject { response }
            it { is_expected.to have_http_status(:ok) }
            end
        end
        context "when post is draft" do
          before {get "/posts/#{other_user_post_draft.id}", headers: auth_headers }

            context "payload draft" do
              subject { payload }
              it { is_expected.to include(:error) }
            end
            context "response draft" do
            subject { response }
            it { is_expected.to have_http_status(:not_found) }
            end
          end
      end
      context 'when requisting users post' do
        
      end
    end 
  end
  describe "POST /posts" do

  end
  describe "PUT /posts" do

  end
      # it "should return OK" do
      #   get '/posts'
      #  payload = JSON.parse(response.body)
      #  expect(payload).to be_empty
      #  expect(response).to have_http_status(200)
      # end

      private

      def payload
        JSON.parse(response.body).with_indifferent_access
      end
  end

controlller

class PostsController < ApplicationController
  before_action :authenticate_user!, only: [:create, :update]
#general exception
  rescue_from Exception do |e|
    render json:  { error: e.message }, status: :internal_error
  end

# exception handler
rescue_from ActiveRecord::RecordInvalid do |e|
  render json:  { error: e.message }, status: :unprocessable_entity
end
#GET /posts
def index
  @posts = Post.where(published: true)
  if !params[:search].nil? && params[:search].present?
    @posts = PostsSearchService.search(@posts, params[:search])
  end
  #includes other module like user that is relationated with posts, this made 1 query to the db 
  #solution n+1 query problem
  render json: @posts.includes(:user), status: :ok
end

#GET /posts/{id}
def show
  @post = Post.find(params[:id])
  if (@post.published? || (Current.user && @post.user_id == Current.user.id))
  render json: @post, status: :ok
  else 
    render json: { error: 'Not_Found' }, status: :not_found
  end
end

#POST /posts
def create
  @post = Current.user.posts.create!(create_params)
  render json: @post, status: :created
end

#PUT /posts/{id}
def update
  @post = Current.user.posts.find(params[:id])
  @post.update!(update_params)
  render json: @post, status: :ok
end

private

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

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

def authenticate_user!
  #Bearer 'token'
  token_regex = /Bearer (\W+)/
  #read HEADER de auth
  headers = request.headers
  #verificar que sea valido
  if ['Authorization'].present? && headers['Authorization'].match(token_regex)
    token = headers['Authorization'].match(token_regex)[1]
  #debemos verificar que el user corresponda a un user
    if (Current.user = User.find_by_auth_token(token))
        return
  end
end
render json: { error: 'unauthorized'}, status: :unauthorized
end

end

Pero no me pasan las pruebas

Diego Ortiz

student•

Debiste poner los errores que te salen en las pruebas para encontrar la respuesta más fácil. De lo que se alcanza a ver que en esos dos archivos veo:

Tú let!(:auth_headers) estás usando un user.auth.token cuando en verdad el auth_token es la columna, así que debe ser user.auth_token
La W de tu token_regex es mayúscula y no minúscula como la de Simon
En el primer if del authenticate_user tiene un ['Authorization'].present? en vez de headers['Authorization'].present?

Cristian Mendoza

student•

Por un descuido escribo mal la relación en el modelo y me sucedió lo siguiente, acá la explicación:

Como nombras en rails variables, relaciones o nombres de archivos es importante tener claro como lo haces incluso hay palabras clave que no se deberían usar para nombrar variables. Me sucedió lo siguiente con el nombre de una relación:

// models/user.rb

has_many :post

Es valido para rails a pesar que un usuario tiene muchos post, la forma correcta debería ser

 has_many :posts // en plural

Esto es un problema cuando desde el controlador quieres hacer algo como:

@post = Current.user.post.create!(create_params)

Esto lo permite el lenguaje pero no es correcto hacerlo ya que la relación es 1:N