better_auth 0.1.1 → 0.2.0

data/.vscode/settings.json

@@ -1,22 +0,0 @@
-{
-  "rubyLsp.enabled": true,
-  "rubyLsp.formatter": "standard",
-  "rubyLsp.linters": ["standard"],
-  "editor.formatOnSave": true,
-  "editor.insertSpaces": true,
-  "editor.tabSize": 2,
-  "files.insertFinalNewline": true,
-  "files.trimTrailingWhitespace": true,
-  "[ruby]": {
-    "editor.defaultFormatter": "Shopify.ruby-lsp",
-    "editor.formatOnSave": true,
-    "editor.rulers": [120]
-  },
-  "search.exclude": {
-    "**/.bundle": true,
-    "**/vendor": true,
-    "**/coverage": true,
-    "**/doc": true,
-    "**/*.gem": true
-  }
-}

data/AGENTS.md

@@ -1,50 +0,0 @@
-# AGENTS.md - Better Auth Core Package
-
-**⚠️ CRITICAL: Always read this file when editing files in packages/better_auth/**
-
-## What is this package?
-
-This is the **core gem** of Better Auth Ruby - a Ruby port of the TypeScript [better-auth](https://github.com/better-auth/better-auth) library. It contains framework-agnostic authentication logic built on Rack.
-
-## Upstream Reference
-
-**Always check `upstream/` before implementing or modifying features.**
-
-The TypeScript implementation in `upstream/packages/better-auth/` is the source of truth. Your workflow should be:
-
-1. **Find the feature** in `upstream/packages/better-auth/src/`
-2. **Understand how it works** in TypeScript
-3. **Translate to Ruby** following Ruby/Rails best practices
-4. **Adapt idiomatically** - don't do a literal translation, make it feel native to Ruby
-
-Key upstream directories:
-- `upstream/packages/better-auth/src/` - Core auth logic
-- `upstream/packages/better-auth/src/plugins/` - Plugin implementations
-
-## Development Commands
-
-```bash
-bundle install          # Install dependencies
-bundle exec rake test   # Run tests (Minitest)
-bundle exec standardrb  # Run linter
-bundle exec standardrb --fix  # Fix linting issues
-```
-
-## Directory Structure
-
-* `lib/better_auth.rb` - Main entry point
-* `lib/better_auth/core/` - Core authentication logic
-* `test/` - Tests (Minitest)
-
-## Code Style
-
-* StandardRB for linting
-* `frozen_string_literal: true` in all files
-* snake_case for files/methods, CamelCase for classes
-
-## After Everything is Done
-
-**Unless the user asked for it, DO NOT COMMIT**
-
-* Make sure `bundle exec standardrb` passes
-* Make sure `bundle exec rake test` passes

data/CLAUDE.md

@@ -1 +0,0 @@
-AGENTS.md

data/CODE_OF_CONDUCT.md

@@ -1,173 +0,0 @@
-# Contributor Covenant 3.0
-
-## Our Pledge
-
-We pledge to make our community welcoming, safe, and equitable for all.
-
-We are committed to fostering an environment that respects and promotes the
-dignity, rights, and contributions of all individuals, regardless of
-characteristics including race, ethnicity, caste, color, age, physical
-characteristics, neurodiversity, disability, sex or gender, gender identity or
-expression, sexual orientation, language, philosophy or religion, national or
-social origin, socio-economic position, level of education, or other status.
-The same privileges of participation are extended to everyone who participates
-in good faith and in accordance with this Covenant.
-
-## Encouraged Behaviors
-
-While acknowledging differences in social norms, we all strive to meet our
-community's expectations for positive behavior.
-We also understand that our words and actions may be interpreted differently
-than we intend based on culture, background, or native language.
-
-With these considerations in mind, we agree to behave mindfully toward each
-other and act in ways that center our shared values, including:
-
-1. Respecting the **purpose of our community**, our activities, and our ways of
-   gathering.
-2. Engaging **kindly and honestly** with others.
-3. Respecting **different viewpoints** and experiences.
-4. **Taking responsibility** for our actions and contributions.
-5. Gracefully giving and accepting **constructive feedback**.
-6. Committing to **repairing harm** when it occurs.
-7. Behaving in other ways that promote and sustain the **well-being of our
-   community**.
-
-## Restricted Behaviors
-
-We agree to restrict the following behaviors in our community.
-Instances, threats, and promotion of these behaviors are violations of this Code
-of Conduct.
-
-1. **Harassment.** Violating explicitly expressed boundaries or engaging in
-   unnecessary personal attention after any clear request to stop.
-2. **Character attacks.** Making insulting, demeaning, or pejorative comments
-   directed at a community member or group of people.
-3. **Stereotyping or discrimination.** Characterizing anyone's personality or
-   behavior on the basis of immutable identities or traits.
-4. **Sexualization.** Behaving in a way that would generally be considered
-   inappropriately intimate in the context or purpose of the community.
-5. **Violating confidentiality**. Sharing or acting on someone's personal or
-   private information without their permission.
-6. **Endangerment.** Causing, encouraging, or threatening violence or other harm
-   toward any person or group.
-7. Behaving in other ways that **threaten the well-being** of our community.
-
-### Other Restrictions
-
-1. **Misleading identity.** Impersonating someone else for any reason, or
-   pretending to be someone else to evade enforcement actions.
-2. **Failing to credit sources.** Not properly crediting the sources of content
-   you contribute.
-3. **Promotional materials**. Sharing marketing or other commercial content in a
-   way that is outside the norms of the community.
-4. **Irresponsible communication.** Failing to responsibly present content which
-   includes, links or describes any other restricted behaviors.
-
-## Reporting an Issue
-
-Tensions can occur between community members even when they are trying their
-best to collaborate.
-
-Not every conflict represents a code of conduct violation, and this Code of
-Conduct reinforces encouraged behaviors and norms that can help avoid conflicts
-and minimize harm.
-
-When an incident does occur, it is important to report it promptly.
-To report a possible violation, **email [community@better-auth.com](mailto:community@better-auth.com)**
-
-Community Moderators take reports of violations seriously and will make every
-effort to respond in a timely manner.
-
-They will investigate all reports of code of conduct violations, reviewing
-messages, logs, and recordings, or interviewing witnesses and other
-participants.
-
-Community Moderators will keep investigation and enforcement actions as
-transparent as possible while prioritizing safety and confidentiality.
-
-In order to honor these values, enforcement actions are carried out in private
-with the involved parties, but communicating to the whole community may be part
-of a mutually agreed upon resolution.
-
-## Addressing and Repairing Harm
-
-If an investigation by the Community Moderators finds that this Code of Conduct
-has been violated, the following enforcement ladder may be used to determine how
-best to repair harm, based on the incident's impact on the individuals involved
-and the community as a whole.
-Depending on the severity of a violation, lower rungs on the ladder may be
-skipped.
-
-1. Warning
-   1. Event: A violation involving a single incident or series of incidents.
-   2. Consequence: A private, written warning from the Community Moderators.
-   3. Repair: Examples of repair include a private written apology,
-      acknowledgement of responsibility, and seeking clarification on
-      expectations.
-2. Temporarily Limited Activities
-   1. Event: A repeated incidence of a violation that previously resulted in a
-      warning, or the first incidence of a more serious violation.
-   2. Consequence: A private, written warning with a time-limited cooldown
-      period designed to underscore the seriousness of the situation and give
-      the community members involved time to process the incident.
-      The cooldown period may be limited to particular communication channels or
-      interactions with particular community members.
-   3. Repair: Examples of repair may include making an apology, using the
-      cooldown period to reflect on actions and impact, and being thoughtful
-      about re-entering community spaces after the period is over.
-3. Temporary Suspension
-   1. Event: A pattern of repeated violation which the Community Moderators have
-      tried to address with warnings, or a single serious violation.
-   2. Consequence: A private written warning with conditions for return from
-      suspension.
-      In general, temporary suspensions give the person being suspended time to
-      reflect upon their behavior and possible corrective actions.
-   3. Repair: Examples of repair include respecting the spirit of the
-      suspension, meeting the specified conditions for return, and being
-      thoughtful about how to reintegrate with the community when the suspension
-      is lifted.
-4. Permanent Ban
-   1. Event: A pattern of repeated code of conduct violations that other steps
-      on the ladder have failed to resolve, or a violation so serious that the
-      Community Moderators determine there is no way to keep the community safe
-      with this person as a member.
-   2. Consequence: Access to all community spaces, tools, and communication
-      channels is removed.
-      In general, permanent bans should be rarely used, should have strong
-      reasoning behind them, and should only be resorted to if working through
-      other remedies has failed to change the behavior.
-   3. Repair: There is no possible repair in cases of this severity.
-
-This enforcement ladder is intended as a guideline.
-It does not limit the ability of Community Managers to use their discretion and
-judgment, in keeping with the best interests of our community.
-
-## Scope
-
-This Code of Conduct applies within all community spaces, and also applies when
-an individual is officially representing the community in public or other
-spaces.
-Examples of representing our community include using an official email address,
-posting via an official social media account, or acting as an appointed
-representative at an online or offline event.
-
-## Attribution
-
-This Code of Conduct is adapted from the Contributor Covenant, version 3.0,
-permanently available at
-[https://www.contributor-covenant.org/version/3/0/](https://www.contributor-covenant.org/version/3/0/).
-
-Contributor Covenant is stewarded by the Organization for Ethical Source and
-licensed under CC BY-SA 4.0.
-To view a copy of this license, visit
-[https://creativecommons.org/licenses/by-sa/4.0/](https://creativecommons.org/licenses/by-sa/4.0/)
-
-For answers to common questions about Contributor Covenant, see the FAQ at
-[https://www.contributor-covenant.org/faq](https://www.contributor-covenant.org/faq).
-Translations are provided at
-[https://www.contributor-covenant.org/translations](https://www.contributor-covenant.org/translations).
-Additional enforcement and community guideline resources can be found at
-[https://www.contributor-covenant.org/resources](https://www.contributor-covenant.org/resources).
-The enforcement ladder was inspired by the work of
-[Mozilla's code of conduct team](https://github.com/mozilla/inclusion).

data/CONTRIBUTING.md

@@ -1,187 +0,0 @@
-# Contributing to Better Auth Ruby
-
-Thank you for your interest in contributing to Better Auth Ruby!
-This guide will help you get started with the contribution process.
-
-## Code of Conduct
-
-This project and everyone participating in it is governed by our
-[Code of Conduct](/CODE_OF_CONDUCT.md).
-By participating, you are expected to uphold this code.
-
-## Project Structure
-
-```
-lib/
-  better_auth.rb              # Main entry point
-  better_auth/
-    version.rb                # Version constant
-    core.rb                   # Core module loader
-    core/                     # Core authentication logic
-    rails.rb                  # Rails adapter entry
-    rails/                    # Rails-specific code
-
-test/                       # Core library tests (Minitest)
-spec/                       # Rails adapter tests (RSpec)
-```
-
-## Development Guidelines
-
-When contributing to Better Auth Ruby:
-
-* Keep changes focused. Large PRs are harder to review.
-* Follow Ruby conventions and idioms
-* Ensure all code passes StandardRB linting
-* Write tests for new features
-* Maintain backward compatibility when possible
-
-## Getting Started
-
-1. Fork the repository to your GitHub account
-
-2. Clone your fork locally:
-
-   ```bash
-   git clone https://github.com/your-username/better-auth-ruby.git
-   cd better-auth-ruby
-   ```
-
-3. Install Ruby (3.2+ required, 3.3 recommended)
-
-   We recommend using a Ruby version manager like rbenv, rvm, or asdf.
-
-4. Install dependencies:
-
-   ```bash
-   bundle install
-   ```
-
-5. Run tests to ensure everything is working:
-
-   ```bash
-   bundle exec rake ci
-   ```
-
-## Development Workflow
-
-1. Create a new branch for your changes:
-
-   ```bash
-   git checkout -b type/description
-   # Example: git checkout -b feat/oauth-provider
-   ```
-
-   Branch type prefixes:
-
-   * `feat/` - New features
-   * `fix/` - Bug fixes
-   * `docs/` - Documentation changes
-   * `refactor/` - Code refactoring
-   * `test/` - Test-related changes
-   * `chore/` - Build process or tooling changes
-
-2. Make your changes following the code style guidelines
-
-3. Run the linter:
-
-   ```bash
-   bundle exec standardrb --fix
-   ```
-
-4. Add tests for your changes
-
-5. Run the test suite:
-
-   ```bash
-   # Run all tests
-   bundle exec rake ci
-
-   # Run only core tests
-   bundle exec rake test
-
-   # Run only Rails adapter tests
-   bundle exec rspec
-   ```
-
-6. Commit your changes with a descriptive message:
-
-   ```text
-   feat(rails): add current_user helper method
-
-   fix(core): resolve token validation issue
-   ```
-
-7. Push your branch to your fork
-
-8. Open a pull request against the **main** branch
-
-## Code Style
-
-We use [StandardRB](https://github.com/standardrb/standard) for code formatting and linting.
-Before committing, please ensure your code passes:
-
-```bash
-# Check code style
-bundle exec standardrb
-
-# Auto-fix issues
-bundle exec standardrb --fix
-```
-
-### Ruby Style Guidelines
-
-* Use 2 spaces for indentation
-* Use `snake_case` for methods, variables, and file names
-* Use `CamelCase` for classes and modules
-* Use `SCREAMING_SNAKE_CASE` for constants
-* Add `frozen_string_literal: true` pragma to all Ruby files
-* Prefer single quotes for strings without interpolation
-* Avoid unnecessary Ruby features (unless they improve readability)
-
-## Testing Guidelines
-
-### Core Library (Minitest)
-
-Located in `test/` directory:
-
-```ruby
-# test/better_auth/some_feature_test.rb
-require_relative "test_helper"
-
-class SomeFeatureTest < Minitest::Test
-  def test_something
-    assert_equal expected, actual
-  end
-end
-```
-
-### Rails Adapter (RSpec)
-
-Located in `spec/` directory:
-
-```ruby
-# spec/better_auth/rails/some_feature_spec.rb
-require "spec_helper"
-
-RSpec.describe BetterAuth::Rails::SomeFeature do
-  it "does something" do
-    expect(subject).to eq expected
-  end
-end
-```
-
-## Pull Request Process
-
-1. Create a draft pull request early to facilitate discussion
-2. Reference any related issues in your PR description
-3. Ensure all tests pass and the build is successful
-4. Update documentation as needed
-5. Keep your PR focused on a single feature or bug fix
-6. Be responsive to code review feedback
-
-## Security Issues
-
-For security-related issues, please email [security@better-auth.com](mailto:security@better-auth.com).
-Include a detailed description of the vulnerability and steps to reproduce it.
-All reports will be reviewed and addressed promptly.
-For more information, see our [security documentation](/SECURITY.md).

data/Gemfile

@@ -1,12 +0,0 @@
-source "https://rubygems.org"
-
-ruby file: ".ruby-version"
-
-gemspec
-
-group :development, :test do
-  gem "standardrb", "~> 1.0"
-  gem "minitest", "~> 5.25"
-  gem "rake", "~> 13.2"
-  gem "simplecov", "~> 0.22", require: false
-end

data/Makefile

@@ -1,207 +0,0 @@
-# Better Auth Ruby - Makefile
-# Este archivo te ayuda a ejecutar comandos comunes de desarrollo
-# Cada comando tiene comentarios explicativos para aprender
-
-# Variables de color para hacer la salida más legible
-BLUE := \033[36m
-GREEN := \033[32m
-YELLOW := \033[33m
-NC := \033[0m # No Color
-
-# =============================================
-# COMANDOS PRINCIPALES DE DESARROLLO
-# =============================================
-
-# Instala todas las dependencias del proyecto
-# Equivale a: bundle install
-.PHONY: install
-install:
-	@echo "$(BLUE)📦 Instalando dependencias...$(NC)"
-	bundle install
-	@echo "$(GREEN)✓ Dependencias instaladas$(NC)"
-
-# Configuración inicial del proyecto (primer clone)
-# Ejecuta bin/setup que hace bundle install
-.PHONY: setup
-setup:
-	@echo "$(BLUE)🔧 Configurando proyecto...$(NC)"
-	bin/setup
-	@echo "$(GREEN)✓ Proyecto configurado$(NC)"
-
-# =============================================
-# COMANDOS DE CALIDAD DE CÓDIGO
-# =============================================
-
-# Revisa que el código cumpla con el estilo StandardRB
-# Muestra errores pero NO los corrige automáticamente
-.PHONY: lint
-lint:
-	@echo "$(BLUE)🔍 Revisando estilo de código...$(NC)"
-	bundle exec standardrb
-	@echo "$(GREEN)✓ Código cumple con el estilo$(NC)"
-
-# Revisa Y AUTOCORRIGE problemas de estilo con StandardRB
-# Úsalo cuando quieras formatear todo automáticamente
-.PHONY: lint-fix
-lint-fix:
-	@echo "$(BLUE)🔧 Corrigiendo estilo de código automáticamente...$(NC)"
-	bundle exec standardrb --fix
-	@echo "$(GREEN)✓ Código corregido$(NC)"
-
-# =============================================
-# COMANDOS DE TESTING
-# =============================================
-
-# Ejecuta TODOS los tests (core + rails adapter)
-# Es lo mismo que: bundle exec rake ci
-.PHONY: test
-test:
-	@echo "$(BLUE)🧪 Ejecutando todos los tests...$(NC)"
-	bundle exec rake test
-	@echo "$(GREEN)✓ Tests completados$(NC)"
-
-# Ejecuta solo los tests del core (Minitest)
-# Son los tests en el directorio test/
-.PHONY: test-core
-test-core:
-	@echo "$(BLUE)🧪 Ejecutando tests del core...$(NC)"
-	bundle exec rake test:core
-	@echo "$(GREEN)✓ Tests del core completados$(NC)"
-
-# Ejecuta solo los tests del adapter Rails (RSpec)
-# Son los tests en el directorio spec/
-.PHONY: test-rails
-test-rails:
-	@echo "$(BLUE)🧪 Ejecutando tests del adapter Rails...$(NC)"
-	bundle exec rspec
-	@echo "$(GREEN)✓ Tests de Rails completados$(NC)"
-
-# Ejecuta tests con cobertura de código
-# Genera reporte en coverage/index.html
-.PHONY: test-coverage
-test-coverage:
-	@echo "$(BLUE)📊 Ejecutando tests con cobertura...$(NC)"
-	COVERAGE=true bundle exec rake test
-	@echo "$(GREEN)✓ Reporte de cobertura en coverage/index.html$(NC)"
-
-# =============================================
-# COMANDOS DE INTEGRACIÓN CONTINUA (CI)
-# =============================================
-
-# Ejecuta TODO el pipeline de CI localmente
-# 1. Lint (StandardRB)
-# 2. Tests (Minitest + RSpec)
-# Esto es lo que corre GitHub Actions en cada PR
-.PHONY: ci
-ci:
-	@echo "$(BLUE)🔧 Ejecutando CI completo...$(NC)"
-	bundle exec rake ci
-	@echo "$(GREEN)✓ CI completado exitosamente$(NC)"
-
-# =============================================
-# COMANDOS DE DESARROLLO INTERACTIVO
-# =============================================
-
-# Abre una consola interactiva (IRB) con la gema cargada
-# Útil para probar código manualmente
-.PHONY: console
-console:
-	@echo "$(BLUE)💻 Abriendo consola interactiva...$(NC)"
-	bin/console
-
-# =============================================
-# COMANDOS DE PUBLICACIÓN (RELEASE)
-# =============================================
-
-# PASO 1: Actualiza la versión en version.rb
-# Debes hacerlo manualmente antes de release
-
-# PASO 2: Crea un git tag con la versión
-# Ejemplo: make tag VERSION=0.1.0
-.PHONY: tag
-tag:
-ifndef VERSION
-	$(error VERSION no está definido. Usa: make tag VERSION=0.1.0)
-endif
-	@echo "$(YELLOW)🏷️  Creando tag v$(VERSION)...$(NC)"
-	git add -A
-	git commit -m "chore: release v$(VERSION)"
-	git tag -a v$(VERSION) -m "Release v$(VERSION)"
-	@echo "$(GREEN)✓ Tag creado. Ahora haz: git push origin main --tags$(NC)"
-
-# PASO 3 (MANUAL): Publica la gema a RubyGems manualmente
-# Solo úsalo si NO estás usando GitHub Actions
-.PHONY: release-manual
-release-manual:
-	@echo "$(YELLOW)📦 Construyendo gema...$(NC)"
-	gem build better_auth.gemspec
-	@echo "$(YELLOW)🚀 Publicando a RubyGems...$(NC)"
-	gem push better_auth-*.gem
-	@echo "$(GREEN)✓ Gema publicada$(NC)"
-
-# =============================================
-# COMANDOS DE BASES DE DATOS (TESTING)
-# =============================================
-
-# Inicia los contenedores de Docker para testing
-# (PostgreSQL, MySQL, Redis)
-.PHONY: db-up
-db-up:
-	@echo "$(BLUE)🐳 Iniciando bases de datos...$(NC)"
-	docker-compose up -d
-	@echo "$(GREEN)✓ Bases de datos listas$(NC)"
-
-# Detiene los contenedores de Docker
-.PHONY: db-down
-db-down:
-	@echo "$(BLUE)🐳 Deteniendo bases de datos...$(NC)"
-	docker-compose down
-	@echo "$(GREEN)✓ Bases de datos detenidas$(NC)"
-
-# =============================================
-# COMANDOS DE LIMPIEZA
-# =============================================
-
-# Limpia archivos temporales y la gema compilada
-.PHONY: clean
-clean:
-	@echo "$(BLUE)🧹 Limpiando archivos temporales...$(NC)"
-	rm -rf *.gem coverage/ .bundle/
-	@echo "$(GREEN)✓ Limpieza completada$(NC)"
-
-# =============================================
-# AYUDA
-# =============================================
-
-# Muestra todos los comandos disponibles con descripción
-.PHONY: help
-help:
-	@echo "$(GREEN)Better Auth Ruby - Comandos disponibles:$(NC)"
-	@echo ""
-	@echo "$(YELLOW)Instalación:$(NC)"
-	@echo "  make install       - Instala dependencias (bundle install)"
-	@echo "  make setup         - Configuración inicial del proyecto"
-	@echo ""
-	@echo "$(YELLOW)Desarrollo:$(NC)"
-	@echo "  make console       - Abre consola interactiva (IRB)"
-	@echo "  make lint          - Revisa estilo de código"
-	@echo "  make lint-fix      - Corrige estilo automáticamente"
-	@echo ""
-	@echo "$(YELLOW)Testing:$(NC)"
-	@echo "  make test          - Ejecuta todos los tests"
-	@echo "  make test-core     - Solo tests del core (Minitest)"
-	@echo "  make test-rails    - Solo tests Rails (RSpec)"
-	@echo "  make test-coverage - Tests con reporte de cobertura"
-	@echo "  make ci            - Ejecuta CI completo (lint + test)"
-	@echo ""
-	@echo "$(YELLOW)Bases de datos (Docker):$(NC)"
-	@echo "  make db-up         - Inicia PostgreSQL, MySQL, Redis"
-	@echo "  make db-down       - Detiene contenedores"
-	@echo ""
-	@echo "$(YELLOW)Release:$(NC)"
-	@echo "  make tag VERSION=x.x.x  - Crea git tag para release"
-	@echo "  make release-manual     - Publica manualmente (NO usar con CI)"
-	@echo ""
-	@echo "$(YELLOW)Utilidades:$(NC)"
-	@echo "  make clean         - Limpia archivos temporales"
-	@echo "  make help          - Muestra esta ayuda"

data/Rakefile

@@ -1,25 +0,0 @@
-# frozen_string_literal: true
-
-require "bundler/gem_tasks"
-require "rake/testtask"
-
-Rake::TestTask.new(:test) do |t|
-  t.libs << "test"
-  t.libs << "lib"
-  t.test_files = FileList["test/**/*_test.rb"]
-end
-
-desc "Run StandardRB linter"
-task :lint do
-  sh "bundle exec standardrb"
-end
-
-desc "Auto-fix StandardRB issues"
-task "lint:fix" do
-  sh "bundle exec standardrb --fix"
-end
-
-desc "Run full CI check (lint + test)"
-task ci: [:lint, :test]
-
-task default: :ci