Trong thế giới thực, điều này thật nực cười. Nhưng trong thế giới lập trình Web và API, tình huống này xảy ra thường xuyên đến mức nó trở thành “cơn đau đầu” kinh niên của giới bảo mật. Nó được gọi là IDOR (Insecure Direct Object Reference) hay BOLA (Broken Object Level Authorization).

Nếu bạn là một Backend Developer, và bạn tin rằng chỉ cần có Authentication (Đăng nhập) là hệ thống đã an toàn, thì bài viết này sẽ thay đổi tư duy lập trình của bạn. Chúng ta sẽ không chỉ nói về bề nổi, mà sẽ đi sâu vào bản chất kiến trúc của lỗi này.

1. Bản chất kỹ thuật của IDOR

IDOR (Insecure Direct Object Reference) không chỉ là một lỗi code, nó là một lỗi về thiết kế Logic (Business Logic Flaw).

Trong danh sách OWASP API Security Top 10, IDOR chính là bản chất của lỗ hổng số 1: API1: 2023 Broken Object Level Authorization (BOLA).

Hiểu sâu hơn, IDOR xảy ra khi 3 điều kiện sau hội tụ:

1. Direct Reference: Ứng dụng để lộ mã định danh nội bộ (Internal Identifier) của đối tượng (như Database Primary Key, Filename) trực tiếp ra ngoài URL hoặc Body request.
2. User Input: Ứng dụng tin tưởng và sử dụng trực tiếp đầu vào này để truy vấn dữ liệu.
3. Missing Authorization: Ứng dụng bỏ qua bước kiểm tra quyền truy cập tại thời điểm truy xuất đối tượng.

Sai lầm phổ biến: Nhiều Dev nhầm lẫn giữa Authentication (Bạn là ai?) và Authorization (Bạn được làm gì?). IDOR xảy ra khi bạn đã qua cửa Authentication, nhưng hệ thống quên kiểm tra Authorization ở mức độ đối tượng (Object-level).

2. Giải phẫu cơ chế tấn công

Hãy mổ xẻ một HTTP Request để thấy IDOR có thể lẩn trốn ở đâu. Không chỉ ở URL Parameter, nó có thể nằm ở Header hoặc Body.

Kịch bản: Ứng dụng Chat cho phép người dùng tải lại lịch sử chat.

Request bình thường:

GET /api/v1/messages/history HTTP/1.1
Host: example.com
Cookie: session_id=abc123xyz...
X-User-ID: 1005  <-- IDOR tiềm ẩn ở Header

1. Hacker quan sát: Thấy Header X-User-ID: 1005 được gửi kèm mỗi request.
2. Thử nghiệm: Hacker dùng Postman hoặc Burp Suite để chặn request, sửa X-User-ID thành 1006.
3. Kết quả: Server, thay vì lấy ID từ session an toàn (Server-side), lại tin tưởng lấy ID từ Header (Client-side) để query database SELECT * FROM messages WHERE user_id = 1006.
4. Hậu quả: Hacker đọc được toàn bộ tin nhắn của người dùng 1006.

IDOR có thể xuất hiện ở:

• URL Path: /users/100/profile
• Query Params: /invoices?id=100
• Body (JSON/XML): POST /api/change-password với body {"user_id": 100, "new_pass": "..."}

3. Tại sao IDOR lại là “Sát thủ thầm lặng”?

IDOR nguy hiểm vì tính “hợp lệ” về mặt cú pháp của nó.

• Vượt mặt WAF (Web Application Firewall): Các tường lửa thường chặn các ký tự lạ như ' OR 1=1 -- (SQL Injection) hay <script> (XSS). Nhưng với IDOR, payload chỉ là một con số: id=1006. Đối với WAF, đây là một con số hoàn toàn sạch và hợp lệ.
• Khó phát hiện bằng Automation Tool: Các máy quét (Scanner) không hiểu ngữ cảnh nghiệp vụ. Nếu máy quét gửi id=1006 và nhận về 200 OK, nó đánh dấu là “Thành công”. Nó không biết rằng dữ liệu trả về đó không thuộc về người đang gửi request. Chỉ có con người (Pentesters) hoặc Unit Test được viết kỹ lưỡng mới phát hiện ra.
• Hệ quả dây chuyền: IDOR thường là bước đệm để leo thang đặc quyền (Privilege Escalation), dẫn đến việc chiếm đoạt toàn bộ hệ thống (Account Takeover).

Sự nguy hiểm của IDOR nằm ở chỗ nó là một lỗ hổng logic, không phải lỗ hổng cú pháp. Các công cụ quét bảo mật tĩnh (SAST) truyền thống thường thất bại trong việc phát hiện IDOR vì chúng không thể hiểu ngữ cảnh “ai sở hữu cái gì” trong một ứng dụng cụ thể. Điều này dẫn đến một nghịch lý: trong khi các lỗ hổng kỹ thuật như SQL Injection đang giảm dần nhờ các framework hiện đại, IDOR vẫn tồn tại dai dẳng và chiếm tỷ lệ cao trong các chương trình săn lỗi nhận thưởng (Bug Bounty), đặc biệt là trong các lĩnh vực y tế, chính phủ và dịch vụ chuyên nghiệp.

4. Phân loại IDOR chuyên sâu.

4.1. Leo thang đặc quyền ngang (Horizontal Escalation)

Đây là dạng phổ biến nhất. Người dùng A truy cập dữ liệu của Người dùng B có cùng vai trò.

• Ví dụ: Xem đơn hàng, tải hóa đơn, xem ảnh riêng tư.
• Rủi ro: Rò rỉ thông tin cá nhân (PII Breach), vi phạm GDPR/CCPA.

4.2. Leo thang đặc quyền dọc (Vertical Escalation)

Người dùng thường (User) tìm cách gọi các API dành riêng cho Quản trị viên (Admin/Manager).

• Ví dụ:
  • Hacker tìm thấy API: POST /api/users/1001/roles.
  • Hacker gửi request với body: {"role": "ADMIN"}.
  • Nếu Backend không check xem “người gọi API này có phải là Super Admin không”, Hacker lập tức trở thành Admin.

4.3. IDOR trên File tĩnh (Static File IDOR)

Tên file thường dễ đoán.

• Ví dụ: https://example.com/uploads/receipts/receipt_001.pdf.
• Hacker viết script lặp từ 001 đến 9999 để tải toàn bộ hóa đơn của hệ thống.

5. Dẫn chứng thực tế: Khi “Ông lớn” cũng mắc sai lầm

5.1. McDonald’s & sự cố McHire (7/2025)

Link: https://research.cgu.edu/icdc/2025/07/01/mcdonalds-july-2025-breach/

Bối cảnh: Hệ thống bị ảnh hưởng là McHire, nền tảng tuyển dụng toàn cầu của McDonald’s, được vận hành bởi đối tác công nghệ bên thứ ba là Paradox.ai. Paradox.ai cung cấp giải pháp chatbot AI tên là “Olivia” để tự động hóa quy trình phỏng vấn, thu thập thông tin ứng viên và lên lịch làm việc. Sự phụ thuộc vào bên thứ ba này đã mở rộng bề mặt tấn công của McDonald’s ra ngoài hạ tầng kiểm soát trực tiếp của họ.   

Nguyên nhân chính
Sự cố xảy ra do kết hợp 2 lỗi nghiêm trọng:

1. Xác thực yếu (Weak Authentication)
   • Một tài khoản admin thử nghiệm của Paradox.ai dùng mật khẩu “123456”, không có MFA.
   • Tài khoản này tồn tại từ 2019, không bị vô hiệu hóa dù có quyền truy cập production.
2. Lỗ hổng IDOR (Missing Object Level Authorization)
   • API backend cho phép truy xuất hồ sơ ứng viên bằng applicant_id.
   • Không kiểm tra quyền truy cập → chỉ cần đổi ID là đọc được dữ liệu của bất kỳ ứng viên nào.
   • Từ 1 tài khoản → mở rộng ra 64 triệu hồ sơ toàn cầu.

Tác động

• Rò rỉ PII: tên, email, số điện thoại, địa chỉ nhà.
• Lộ dữ liệu nhạy cảm: log chat với AI (tính cách, sở thích, thông tin cá nhân).
• Lộ token phiên → có thể giả danh ứng viên.
• Nguy cơ cao cho social engineering, lừa đảo, chiếm tài khoản.

Sự kết hợp giữa quản lý tài khoản kém (tài khoản ma, không MFA) và thiếu kiểm soát quyền API (IDOR) tạo ra “cơn bão hoàn hảo” cho rò rỉ dữ liệu quy mô toàn cầu – một xu hướng cực kỳ đáng báo động trong năm 2025

5.2. Mozilla Firefox Accounts – Lỗ hổng xóa tài khoản (5/2025)

Link: https://hackerone.com/reports/3154983

Bản chất sự cố

• Lỗ hổng IDOR nghiêm trọng trong API xóa tài khoản (/v1/account/destroy).
• Cho phép xóa vĩnh viễn tài khoản người khác mà không cần tương tác từ nạn nhân (zero-click).
• Ảnh hưởng trực tiếp đến Integrity (toàn vẹn) và Availability (sẵn sàng) của dữ liệu.

Nguyên nhân kỹ thuật

• Lỗi Session Misbinding: backend không kiểm tra phiên làm việc có khớp với tài khoản bị xóa hay không.
• API tin vào payload JSON (email, authPW) thay vì session của người gửi request.
• Đây là dạng IDOR ghi/xóa, nguy hiểm hơn IDOR đọc dữ liệu.

Kịch bản khai thác

1. Kẻ tấn công tạo tài khoản Firefox, đăng nhập bằng SSO (Google).
2. Chặn request xóa tài khoản của chính mình.
3. Đổi email trong payload thành email nạn nhân (cũng dùng SSO, chưa set mật khẩu).
4. Gửi request → hệ thống xóa tài khoản nạn nhân.

Tác động

• Mất vĩnh viễn dữ liệu: mật khẩu đã lưu, lịch sử duyệt web, tab, sync data.
• Không thể khôi phục, không cần nạn nhân click hay xác nhận.
• Được đánh giá Critical trên HackerOne.

Bài học cốt lõi: IDOR không chỉ gây rò rỉ dữ liệu (read) mà còn có thể phá hủy dữ liệu (write/delete) nếu backend không ràng buộc chặt chẽ giữa session và đối tượng tài nguyên.

5.3. GitLab – Lỗ hổng Machine Learning Model Registry (2024–2025)

Link: https://hackerone.com/reports/2528293

Bối cảnh

• GitLab triển khai Machine Learning Model Registry để quản lý phiên bản mô hình AI.
• Lỗ hổng được báo cáo từ 5/2024, vá và công bố kéo dài sang 2025, cho thấy độ phức tạp của bảo mật trên nền tảng lớn.
• Sự cố ảnh hưởng trực tiếp đến tài sản trí tuệ AI (model weights, biases).

Nguyên nhân kỹ thuật

• GitLab dùng ID tịnh tiến (1,2,3,…) cho model_id thay vì UUID ngẫu nhiên.
• API tải/xem mô hình không kiểm tra quyền truy cập dự án (Missing Object Level Authorization).
• Đây là IDOR điển hình + thiết kế API kém an toàn.

Cách khai thác

• Kẻ tấn công chỉ cần tài khoản GitLab miễn phí.
• Lặp ID từ 1 → hàng triệu để liệt kê và tải mô hình của dự án khác.
• Không cần brute-force, không cần quyền dự án.

Tác động

• Rò rỉ mô hình ML độc quyền của doanh nghiệp.
• Nguy cơ mất bí mật thương mại, thiệt hại kinh tế lớn trong bối cảnh AI là tài sản cốt lõi.
• Lỗ hổng có thể bị khai thác tự động, quy mô lớn (enumeration).

Bài học cốt lõi: Không dùng ID tịnh tiến cho API công khai. Nó biến IDOR từ lỗ hổng tiềm ẩn thành thảm họa có thể khai thác hàng loạt, đặc biệt nguy hiểm với tài sản AI.

6. Ngăn chặn IDOR hiệu quả (Best Practices)

Khi một tài khoản test có thể mở khóa 64 triệu hồ sơ, một email có thể xóa tài khoản người khác, và một con số tăng dần có thể làm bay cả mô hình AI, thì rõ ràng vấn đề không nằm ở “hacker quá giỏi” — mà ở chỗ chúng ta cần chặn IDOR cho đúng cách.

“Đừng bao giờ tin tưởng Client”. Dưới đây là chiến lược phòng thủ đa lớp (Defense in Depth).

Lớp 1: Kiểm soát truy cập tại tầng Data (Data-Layer Authorization)

Đây là chốt chặn cuối cùng và quan trọng nhất. Mọi câu lệnh truy vấn liên quan đến dữ liệu người dùng phải kèm theo điều kiện về chủ sở hữu.

❌ Code rủi ro (Spring Data JPA):

// Controller
public Order getOrder(@PathVariable Long id) {
    return orderRepo.findById(id); // Chỉ tìm theo ID đơn hàng
}

✅ Code an toàn (Repository Pattern):

// Repository
// Luôn gắn kèm userId vào câu query
@Query("SELECT o FROM Order o WHERE o.id = :id AND o.owner.id = :currentUserId")
Optional<Order> findByIdAndOwner(@Param("id") Long id, @Param("currentUserId") Long userId);

// Service Layer
public Order getOrder(Long id, User currentUser) {
    return orderRepo.findByIdAndOwner(id, currentUser.getId())
        .orElseThrow(() -> new ResourceNotFoundException("Order not found or access denied"));
}

Lớp 2: Kiểm soát truy cập tại tầng Controller (Method-Level Security)

Sử dụng các Annotation bảo mật của Framework (như Spring Security) để chặn ngay từ cửa vào.

✅ Ví dụ với Spring Security (@PreAuthorize):

@GetMapping("/invoices/{id}")
// SpEL: Chỉ cho phép nếu user hiện tại là chủ sở hữu của invoice có id này
@PreAuthorize("@securityService.isOwner(authentication, #id)") 
public Invoice getInvoice(@PathVariable Long id) {
    return invoiceRepo.findById(id);
}

Cách này giúp code business logic sạch hơn, tách biệt logic bảo mật ra khỏi logic nghiệp vụ.

Lớp 3: Làm khó Hacker bằng UUID (Obfuscation)

Thay vì dùng Auto-Increment Integer (1, 2, 3), hãy dùng UUID (Random String: a0eebc99-9c0b...) hoặc các thuật toán băm ID (như Hashids).

• Lợi ích: Chặn đứng tấn công kiểu liệt kê (Enumeration Attack). Hacker không thể viết vòng lặp for (i=0; i<1000; i++) để quét dữ liệu.
• Cảnh báo: UUID KHÔNG THỂ THAY THẾ được Lớp 1 và Lớp 2. Nếu hacker bằng cách nào đó biết được UUID của nạn nhân, IDOR vẫn xảy ra nếu thiếu Authorization check. UUID chỉ là “lớp sương mù”, không phải “bức tường thép”.

Lớp 4: Kiểm thử tự động (Automated Security Testing)

Đừng đợi Pentester tìm lỗi. Hãy viết Test Case cho IDOR.

• Unit Test: Tạo 2 user (Alice, Bob). Đăng nhập bằng Alice, cố gắng request dữ liệu ID của Bob. Assert rằng kết quả trả về phải là 403 Forbidden hoặc 404 Not Found.

7. Kết luận

IDOR không phải là một lỗi kỹ thuật phức tạp, nhưng nó phản ánh sự thiếu sót trong tư duy thiết kế hệ thống.

Hãy nhớ nguyên tắc vàng: Mọi request truy cập dữ liệu đều phải trả lời được hai câu hỏi:

1. Người dùng này là ai? (Authentication)
2. Dữ liệu này có phải của họ không? (Authorization)

Nếu thiếu câu hỏi số 2, chúng ta đang mở toang cánh cửa “phòng 102” cho bất kỳ ai cầm chìa khóa “phòng 101”.

The post IDOR – Lỗ hổng “ngây thơ” nhưng chí mạng trong kiến trúc phần mềm? appeared first on Tomoshare.

Dưới đây là một giải pháp nhanh chóng với bạn có thể thử với những dòng command

brew install openssl@1.1

export PATH="$(brew --prefix)/opt/openssl@1.1/bin:$PATH"
export LDFLAGS="-L$(brew --prefix)/opt/openssl@1.1/lib"
export CPPFLAGS="-I$(brew --prefix)/opt/openssl@1.1/include"
export PKG_CONFIG_PATH="$(brew --prefix)/opt/openssl@1.1/lib/pkgconfig"

rvm autolibs disable

export RUBY_CFLAGS=-DUSE_FFI_CLOSURE_ALLOC
export optflags="-Wno-error=implicit-function-declaration"

rvm install 3.2.2 --with-openssl-dir=$(brew --prefix)/opt/openssl@1.1

Nếu đã chạy các command ở trên vẫn không được hãy thử dụng tuyệt chiêu cuối cùng với command

arch -x86_64 rvm install 3.2.2 -j 1

Tôi cũng đang sử dụng M1 và mọi thứ đã work đối với tôi.

The post Cài đặt Ruby trên M1 Mac appeared first on Tomoshare.

💎 Improvements:
1️⃣ New support query với giá trị Hash
2️⃣ Chúng ta không cần phải dùng truy vấn raw version nữa

💎 Bonus:
1️⃣ Cú pháp mới cũng support chúng ta sử dụng alias
2️⃣ Sử dụng tương tự cho ActiveRecord#reselect

# Before Rails 7.1

Post.joins(:comments)
    .select(
      "posts.id as post_id, posts.title as post_title,
      comments.id as comment_id, comments.body as comment_body"
    )
    
Post.joins(:comments).select(:id, :title, "comments.body")

# After Rails 7.1

Post.joins(:comments)
    .select(
      posts: { id: :post_id, title: :post_title },
      comments: { id: :comments_id, body: :comment_body }
    )
    
Post.joins(:comments).select(:id, :title, comments: [:body] )

The post [Rails Tips] Rails 7.1 – ActiveRecord::QueryMethods#select has added support for hash values appeared first on Tomoshare.

gem 'carrierwave'
gem 'fog-aws'

bundle install

Giả sử bạn đang cần upload avatar cho user

class User < ActiveRecord::Base
  mount_uploader :avatar, AvatarUploader
end

Tiếp theo hãy tạo file uploader cho nó

class AvatarUploader < CarrierWave::Uploader::Base
  storage :fog
end

Để biết thêm về nhiều loại ma thuật khác như thay đổi tên file hay folder chứa, vân vân và mây mây ae có thể xem tại đây
https://github.com/carrierwaveuploader/carrierwave

Tạo file carrierwave.rb trong config/initializers và cấu hình credentials

CarrierWave.configure do |config|
  config.fog_credentials = {
    provider: 'AWS',
    aws_access_key_id: 'S3_AWS_ACCESS_KEY_ID',
    aws_secret_access_key: 'S3_AWS_SECRET_ACCESS_KEY',
    region: 'us-east-1'
  }
  config.fog_directory = 'BUCKET_NAME'
end

There u go, giờ thì ae có thể upload file lên S3 r. Quá ư là đơn giản và dễ hiểu phải không 🐧🐧

The post Upload file lên Amazon S3 bằng carrierwave appeared first on Tomoshare.

• Deploy đóng vai trò quan trọng trong quá trình phát triển ứng dụng. Rails đã tích hợp webpacker từ version ~> 6.0 để quản lý tài nguyên JavaScript và CSS dễ dàng hơn

• Khi ứng dụng của bạn ngày càng lớn thì việc assets:precompile sẽ tốn nhiều thời gian và tài nguyên của server. Điều này có thể gây downtime ứng dụng trong quá trình deploy, đặc biệt là trên các servers có tài nguyên hạn chế và workload cao

• Bài viết này giới thiệu về cách dùng local precompile để tối ưu hoá hiệu suất trong quá trình deploy. Chúng ta sẽ tìm hiểu lý do tại sao việc assets:precompile trên server có thể gây nên vấn đề và giải pháp đơn giản chỉ là thực hiện precompile tại máy local

Deploy bằng phương pháp mặc định: Precompile trực tiếp trên server

• Bước đầu tiên là tạo mới một ứng dụng Rails

rails _6.0.6.1_ new local_precompile

• Kiểm tra xem ứng dụng đã hoạt động chưa

rails s

• Thay đổi root path

rails g scaffold post title:string body:text

Rails.application.routes.draw do
  root to: 'posts#index'
  resources :posts
end

• Commit code và push lên Git Repository của bạn

• Tiếp theo mình sẽ Launch Instance và chọn OS là Ubuntu

• SSH vào server và cài đặt nginx làm web server

ssh -i ~/path-to-file-key ubuntu@public-ip-address
sudo apt update
sudo apt install nginx

• Sau khi cài đặt nginx và mở được trang “Welcome to nginx!” trên trình duyệt bằng public-ip-address thì bạn đã hoàn thành nhiệm vụ 🤣

• Tiếp theo, bạn cần cài đặt các packages cần thiết để ứng dụng Rails hoạt động được trên server

• Đảm bảo cài đặt đúng version Ruby, Rails, Yarn, Node… mà bạn đã sử dụng để chạy ứng dụng ở máy local (điều này giúp tránh những lỗi không cần thiết liên quan đến version)

• Quay lại ứng dụng Rails và cấu hình deploy bằng Capistrano. Cài đặt các gems cần thiết

group :development do
  # Capistrano - easy to deployment with Ruby over SSH
  gem 'capistrano', '~> 3.18'
  # rbenv integration for Capistrano
  gem 'capistrano-rbenv', '~> 2.2'
  # Rails specific Capistrano tasks
  gem 'capistrano-rails', '~> 1.6', '>= 1.6.3'
  # Bundler support for Capistrano 3.x
  gem 'capistrano-bundler', '~> 2.1'
  # based on capistrano/npm gem
  gem 'capistrano-yarn', '~> 2.0', '>= 2.0.2'
  # nvm support for Capistrano 3.x
  gem 'capistrano-nvm', '~> 0.0.7'
end

bundle install
cap install

• Sau khi hoàn thành hai lệnh trên, hệ thống sẽ tự động tạo các files cần thiết để hỗ trợ deploy ứng dụng. Chỉnh sửa nội dụng các files sau
  

config/deploy/production.rb

server "public-ip-address", user: "ubuntu", roles: %w{app db web}

set :ssh_options,
    forward_agent: true,
    auth_methods: %w[publickey],
    keys: %w[~/path-to-your-key]

set :branch, :main

set :rails_env, :production

config/deploy.rb

# config valid for current version and patch releases of Capistrano
lock "~> 3.18.0"

set :application, "local_precompile"
set :repo_url, "your-repo-url"

# Default deploy_to directory is /var/www/my_app_name
set :deploy_to, "/home/ubuntu/sites/local_precompile"

# Default value for :pty is false
set :pty, true

# Default value for :linked_files is []
append :linked_files, "config/master.key"

# Default value for linked_dirs is []
append :linked_dirs, "log", "tmp/pids", "tmp/cache", "tmp/sockets", "public/system", "vendor", "storage"

# Default value for default_env is {}
set :default_env, { "PATH": "/home/ubuntu/.nvm/versions/node/v16.20.2/bin:$PATH" }

set :puma_pid, shared_path.join('tmp/pids/server.pid')

set :puma_bind, "unix://#{shared_path.join('tmp/sockets/puma.sock')}"

set :puma_config_path, -> { File.join(current_path, 'config', 'puma', "#{fetch(:rails_env)}.rb") }

• Thêm các modules cần thiết vào /Capfile

require "capistrano/rbenv"
set :rbenv_type, :user
set :rbenv_ruby, "2.7.0"
set :rbenv_map_bins, %w[rake gem bundle ruby rails]
set :rbenv_roles, :all

require "capistrano/bundler"
require "capistrano/rails/assets"
require "capistrano/rails/migrations"

require "capistrano/yarn"
set :yarn_flags, '--frozen-lockfile'

require "capistrano/nvm"
set :nvm_type, :user
set :nvm_node, "v16.20.2"
set :nvm_map_bins, %w[node npm yarn]

• Tạo một file puma configuration cho môi trường production như sau

config/puma/production.rb

# Puma can serve each request in a thread from an internal thread pool.
# The `threads` method setting takes two numbers: a minimum and maximum.
# Any libraries that use thread pools should be configured to match
# the maximum value specified for Puma. Default is set to 5 threads for minimum
# and maximum; this matches the default thread size of Active Record.
#
max_threads_count = ENV.fetch("RAILS_MAX_THREADS") { 5 }
min_threads_count = ENV.fetch("RAILS_MIN_THREADS") { max_threads_count }
threads min_threads_count, max_threads_count

# Specifies the `port` that Puma will listen on to receive requests; default is 3000.
#
port ENV.fetch("PORT") { 3000 }

# Specifies the `environment` that Puma will run in.
#
environment "production"

# Specifies the `pidfile` that Puma will use.
pidfile ENV.fetch("PIDFILE") { "tmp/pids/server.pid" }

tmp_path = "#{File.expand_path('../../..', __FILE__)}/tmp"
bind "unix://#{tmp_path}/sockets/puma.sock"

log_path = "#{File.expand_path('../../..', __FILE__)}/log"
stdout_redirect "#{log_path}/puma.stdout.log", "#{log_path}/puma.stderr.log", true

# Specifies the number of `workers` to boot in clustered mode.
# Workers are forked web server processes. If using threads and workers together
# the concurrency of the application would be max `threads` * `workers`.
# Workers do not work on JRuby or Windows (both of which do not support
# processes).
#
# workers ENV.fetch("WEB_CONCURRENCY") { 2 }

# Use the `preload_app!` method when specifying a `workers` number.
# This directive tells Puma to first boot the application and load code
# before forking the application. This takes advantage of Copy On Write
# process behavior so workers use less memory.
#
preload_app!

# Allow puma to be restarted by `rails restart` command.
plugin :tmp_restart

• Tạo một file puma rake task như sau

lib/capistrano/tasks/puma.rake

namespace :puma do
  desc 'Start puma'
  task :start do
    on roles(:app) do
      within current_path do
        execute :bundle, 'exec', 'puma', '--config', "#{fetch(:puma_config_path)}", '--daemon'
      end
    end
  end

  desc 'Restart puma'
  task :restart do
    on roles(:app) do
      within current_path do
        if test("[ -f #{shared_path}/tmp/pids/server.pid ]")
          execute :bundle, :exec, :pumactl, '-P', fetch(:puma_pid), 'restart', '--config', fetch(:puma_config_path)
        else
          invoke 'puma:start'
        end
      end
    end
  end

  desc 'Stop puma'
  task :stop do
    on roles(:app) do
      within current_path do
        execute :bundle, :exec, 'pumactl', '-P', fetch(:puma_pid), 'stop'
      end
    end
  end
end

namespace :load do
  task :defaults do
    after 'deploy:publishing', 'puma:restart'
  end
end

• Thêm cấu hình cho nginx

sudo vi /etc/nginx/conf.d/local_precompile.conf

upstream local_precompile {
  server unix:///home/ubuntu/sites/local_precompile/shared/tmp/sockets/puma.sock;
}

server {
  listen 80;
  server_name 54.196.84.135;

  root /home/ubuntu/sites/local_precompile/current/public;
  try_files $uri/index.html $uri @puma;

  location @puma {
    proxy_pass http://unix:/home/ubuntu/sites/local_precompile/shared/tmp/sockets/puma.sock;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
  }
}

sudo service nginx restart

• Khi tất cả đã được thiết lập xong thì chạy lệnh sau để deploy

cap production deploy

• Trong những lần deploy đầu chắc chắn sẽ có những lỗi nhỏ, tuỳ trường hợp mà các bạn có thể tự xử lý nhé 🤣

• Quan sát htop trong quá trình deploy, có thể thấy workload của CPU và Memory tăng cao rõ rệt trong lúc thực hiện yarn:install và deploy:assets:precompile

• Đó là nguyên nhân chính có thể gây downtime ứng dụng

Dùng Local Precompile

• Phát hiện vấn đề chính nằm ở yarn:install và deploy:assets:precompile

• Tiếp theo chúng ta cần chuyển hai tác vụ này về xử lý ở máy local, sau đó upload các files cần thiết lên server là xong

• Tạo một file deploy rake task như sau

lib/capistrano/tasks/deploy.rake

namespace :deploy do
  namespace :assets do
    desc 'Precompile assets locally'
    task :local_precompile do
      run_locally do
        execute "rm -rf #{fetch(:cache_dir)}"
        execute "RAILS_ENV=#{fetch(:rails_env)} bundle exec rake assets:clean"
        execute "RAILS_ENV=#{fetch(:rails_env)} bundle exec rake assets:precompile"
      end
    end

    desc 'rsync assets to web server'
    task :rsync_assets do
      on roles(:web), in: :parallel do |server|
        run_locally do
          ssh_shell   = %(-e "ssh -i #{fetch(:ssh_options)[:keys].first}")
          rsync_shell = "rsync -avz #{ssh_shell}"
          release_dir = "username@public-ip-address:#{release_path}"
          commands    = []

          commands << "#{rsync_shell} ./#{fetch(:assets_dir)} #{release_dir}/#{fetch(:assets_dir)}" if Dir.exists?(fetch(:assets_dir))
          commands << "#{rsync_shell} ./#{fetch(:packs_dir)}  #{release_dir}/#{fetch(:packs_dir)}"  if Dir.exists?(fetch(:packs_dir))
          commands << "#{rsync_shell} ./#{fetch(:cache_dir)}  #{release_dir}/#{fetch(:cache_dir)}"  if Dir.exists?(fetch(:cache_dir))

          commands.each { |command| dry_run? ? SSHKit.config.output.info(command) : execute(command) }
        end
      end
    end
  end
end

namespace :load do
  task :defaults do
    set :assets_role, 'web'
    set :assets_dir,  'public/assets/'
    set :packs_dir,   'public/packs/'
    set :cache_dir,   'tmp/cache/'

    after 'deploy:migrate', 'deploy:assets:local_precompile'
    after 'deploy:assets:local_precompile', 'deploy:assets:rsync_assets'
  end
end

• Rake task này có hai nhiệm vụ
  • Precompile assets ở local
  • Đồng bộ files lên server

• Server không cần phải thực hiện yarn:install và deploy:assets:precompile mỗi khi deploy nữa

• Clean code khi dùng local precompile

Gemfile

group :development do
  # Capistrano - easy to deployment with Ruby over SSH
  gem 'capistrano', '~> 3.18'
  # rbenv integration for Capistrano
  gem 'capistrano-rbenv', '~> 2.2'
  # Rails specific Capistrano tasks
  gem 'capistrano-rails', '~> 1.6', '>= 1.6.3'
  # Bundler support for Capistrano 3.x
  gem 'capistrano-bundler', '~> 2.1'
end

bundle install

Capfile

require "capistrano/rbenv"
set :rbenv_type, :user
set :rbenv_ruby, "2.7.0"
set :rbenv_map_bins, %w[rake gem bundle ruby rails]
set :rbenv_roles, :all

require "capistrano/bundler"
require "capistrano/rails/migrations"

• Commit code và push lên Git Repository của bạn

cap production deploy

• Quan sát htop bạn sẽ không còn thấy sự ảnh hưởng đến workload của CPU và Memory trong quá trình deploy nữa

Lời kết

• Bài viết là một trong những giải pháp liên quan đến hiệu suất server mà team mình đã từng áp dụng trong thực tế

• Chúc các bạn thực hiện thành công và có những trải nghiệm tuyệt vời trên server yêu dấu của client nhé 😆

The post Deploy Rails App: Tối Ưu Hóa Hiệu Suất Server Bằng Local Precompile appeared first on Tomoshare.

Mục đích của Sitemap

1. Hiệu suất Indexing và SEO
   Giúp công cụ tìm kiếm hiểu rõ cấu trúc và nội dung của trang web. Điều này giúp tối ưu hóa hiệu suất indexing, đặc biệt là khi trang web có nhiều nội dung hoặc cấu trúc phức tạp.
2. Ưu tiên Indexing
   Thông qua các thông tin như lastmod (thời điểm sửa đổi gần nhất), changefreq (tần suất thay đổi), và priority (độ ưu tiên), sitemap giúp bạn quyết định trang nào quan trọng hơn và nên được cập nhật thường xuyên hơn.
3. Hỗ trợ trải nghiệm người dùng
   Sitemap không chỉ hỗ trợ công cụ tìm kiếm mà còn cải thiện trải nghiệm người dùng bằng cách cung cấp các liên kết dẫn đến các trang quan trọng.
4. Điều hướng Crawl bổ sung
   Đối với các trang web có cấu trúc phức tạp, sitemap giúp điều hướng crawl bổ sung, đặc biệt là đối với các trang được tạo ra bằng JavaScript.

Sử dụng Sitemap trong ROR

# Gemfile

gem 'sitemap_generator'

# config/sitemap.rb

require 'rubygems'
require 'sitemap_generator'

SitemapGenerator::Sitemap.default_host = 'https://yourdomain.com'
SitemapGenerator::Sitemap.create do
  add '/', changefreq: 'daily', priority: 1.0
  add '/page', changefreq: 'weekly', priority: 0.8
  # Thêm các trang khác và thông tin
end

# ping công cụ tìm kiếm google và bing để thông báo về sự thay đổi của sitemap
SitemapGenerator::Sitemap.ping_search_engines

# Tạo file sitemap.xml

rake sitemap:create #=> public/sitemap.xml

# public/robots.txt

Sitemap: https://yourdomain/sitemap.xml

Lưu ý khi tạo Sitemap

• Phân chia công việc tạo sitemap thành các nhiệm vụ nhỏ để giảm gánh nặng hệ thống.
• Xác định các tiêu chí để chỉ tạo sitemap cho những trang quan trọng nhất, giảm độ lớn của sitemap.
• Tối ưu cơ sở dữ liệu để đảm bảo tìm kiếm và truy xuất dữ liệu một cách hiệu quả.
• Theo dõi quá trình tạo sitemap và lưu lại log để giám sát và điều chỉnh khi cần thiết.
• Nên tạo sitemap vào những thời điểm ít người truy cập nhất để giảm tác động đến hiệu suất hệ thống và người dùng.

Kết luận

Sitemap là chìa khóa quan trọng cho chiến lược SEO và hiệu suất web. Bằng cách đặt độ ưu tiên và tuân thủ lưu ý quan trọng, sitemap không chỉ tối ưu hóa hiệu suất hệ thống mà còn định hình một chiến lược SEO thành công.

Cảm ơn bạn đã đọc.

The post Tối ưu hóa SEO với Sitemap appeared first on Tomoshare.

Slack là một phần mềm Worksplace sử dụng thông dụng rộng rãi. Tuy nhiên, ta có thể sử dụng slack để theo dõi và giám sát hệ thống, gửi tin nhắn tự động.

Sau đây, mình sẽ hướng dẫn mọi người cách để gửi thông báo, tin nhắn … đến slack trong rails app, nó làm cho Rails Application của bạn có thể trở nên năng động và hiệu quả hơn.

Setup Slack:

Đầu tiên, bạn phải có 1 Worksplace, 1 channel nào đó rồi nhé.

• Bạn cần tạo một App Slack từ https://api.slack.com/apps, chọn Create an app → From Scratch (điền tên và chọn workspace)

• Chọn tab Incoming Webhooks bạn sẽ có:
  • Webhook URL
  • Channel

Setup Rails:

Đầu tiên, bạn tự thêm gem vào trong Gemfile và Bundle nhé.

1. Sử dụng slack-notifier

• gem "slack-notifier" https://github.com/slack-notifier/slack-notifier
• Tạo 1 module SlackNotifier để tiện cho việc gọi khi cần.
  • ENV[‘SLACK_WEBHOOK_URL’], ENV[‘SLACK_CHANNEL_SLACK’] bạn lấy ở bên trên.
  • ENV[‘SLACK_USERNAME_SLACK’] bạn đặt tự do.

#config/initializers create slack_notifier.rb

module SlackNotifier
  CLIENT = Slack::Notifier.new(
    ENV['SLACK_WEBHOOK_URL'],
    channel: ENV['SLACK_CHANNEL_SLACK'],
    username: ENV['SLACK_USERNAME_SLACK']
  )
end

SlackNotifier::CLIENT.ping "Hello Everybody!"
SlackNotifier::CLIENT.ping "TEST SLACK NOTIFICATION"

• Kết quả

• Ngoài ra, bạn có thể custom nhiều hơn nữa, xem thêm tại https://github.com/slack-notifier/slack-notifier

2. Sử dụng exception-notification

• Gem này sẽ tự động gửi exception về slack của bạn khi Rails App xảy exception. Nó giúp việc giám sát hệ thống, giúp bạn nhanh chóng kiểm tra, sửa chữa kịp thời.
• gem exception_notification https://github.com/smartinez87/exception_notification
• Nếu ở production: config/environments/production.rb

#config/environments/development.rb

Rails.application.config.middleware.use ExceptionNotification::Rack, slack: {
  webhook_url: ENV['SLACK_WEBHOOK_URL'],
  channel: ENV['SLACK_CHANNEL_NAME']
	}

• Đặt ở nơi bạn muốn push notify nhé.

rescue_from StandardError do |e|
  ExceptionNotifier.notify_exception(e, 
		data: {
			# custom message ... 
			messages: e.messages
			date: Date.current
		}
	)
end

• Kết quả

• Ngoài ra, bạn có thể custom nhiều hơn nữa, xem thêm tại https://github.com/smartinez87/exception_notification

Hi vọng bài viết sẽ giúp ích được mọi người.

Cảm ơn mọi người.

The post Setup slack notifications in Rails appeared first on Tomoshare.

Mặc dù không có nhiều thay đổi lớn về các tính năng ngôn ngữ như các phiên bản trước, nhưng trong phiên bản này, trọng tâm chính là hiệu suất và trải nghiệm phát triển. Dưới đây là một số điểm nổi bật của phiên bản này:

YJIT

YJIT, trình biên dịch JIT của Ruby, đã có những cải tiến đáng kể trong vài năm qua. Trong năm nay, nó tiếp tục trở nên nhanh hơn, đồng thời tiêu thụ ít bộ nhớ hơn.

Các công ty như Basecamp và Shopify đã sử dụng phiên bản xem trước của 3.3 trong môi trường production và đã thấy sự cải thiện khoảng 15% trong thời gian phản hồi trung bình so với phiên bản 3.3.0 không có YJIT.
Thực tế, YJIT đã rất hiệu quả trong việc tăng tốc ứng dụng Rails và nó sẽ được kích hoạt mặc định trên ứng dụng Rails mới nếu sử dụng Ruby 3.3.

Một phương thức mới, RubyVM::YJIT.enable đã được giới thiệu, cho phép bạn kích hoạt YJIT khi đang chạy. Điều này có thể hữu ích nếu bạn muốn tải ứng dụng nhanh chóng và sau đó kích hoạt YJIT sau khi nó đã khởi động. Đây chính là cách Rails sử dụng để kích hoạt JIT trong một bộ khởi tạo.

RJIT

Một trình biên dịch JIT thử nghiệm có tên là RJIT đã được giới thiệu. Được viết bằng Ruby thuần, nó thay thế MJIT, một JIT thay thế khác đã có sẵn trong Ruby 3.2. RJIT sử dụng nhiều bộ nhớ hơn so với YJIT và chỉ tồn tại cho mục đích thử nghiệm. Trong môi trường sản xuất, vẫn nên sử dụng YJIT.

IRB

Từ khi biết đến Ruby, pry là công cụ gỡ lỗi ưa thích của mình, mình đã chuyển sang sử dụng IRB gần đây, sau khi biết tới bài viết này. Trong phiên bản này, IRB và integration của nó với gem debug đã được cải thiện đến mức pry và byebug không còn cần thiết cho việc gỡ lỗi mã nguồn của bạn.

Range

Rails Range#overlaps?(range)

So sánh hai phạm vi và xem liệu chúng có trùng lặp với nhau không. overlap? trả về true nếu hai phạm vi trùng nhau nếu không thì trả về false.

(3..8).overlaps?(8..10) # => true
(2..43).overlaps?(3..5) # => true
(1..5).overlaps?(7..9) # => false

('a'..'z').overlaps?('c'..'d') # => true

(1.day.from_now..5.days.from_now).overlaps?(5.days.from_now..10.days.from_now) # => false
(1.day.from_now.to_date..5.days.from_now.to_date).overlaps?(5.days.from_now.to_date..10.days.from_now.to_date) # => true

(3...8).overlaps?(8...9) # => false
(3...8).overlaps?(7...9) # => true

# works similarly for open ranges.
(3..).overlaps?(...3) # => false

Ruby < 3.3

Không giống như Rails, Ruby không có phương thức nào để so sánh hai phạm vi và kiểm tra chúng có trùng nhau hay không.

Trước Ruby 3.3, nếu chúng ta muốn kiểm tra sự trùng lặp, chúng ta cần sử dụng phương thức cover, nó sẽ trả về true nếu hai phạm vi trùng nhau.

# Check if range1 covers any value in range2 or vice versa
range1 = (3..8)
range2 = (8..10)
range1.cover?(range2.first) || range2.cover?(range1.first) # => true

range1 = ('a'..'z')
range2 = ('c'..'d')
range1.cover?(range2.first) || range2.cover?(range1.first) # => true

range1 = (1.day.from_now..5.days.from_now)
range2 = (5.days.from_now..10.days.from_now)
range1.cover?(range2.first) || range2.cover?(range1.first) # => false

range1 = (1.day.from_now.to_date..5.days.from_now.to_date)
range2 = (5.days.from_now.to_date..10.days.from_now.to_date)
range1.cover?(range2.first) || range2.cover?(range1.first) # => true

Ruby 3.3

Ruby 3.3 giới thiệu phương thức Range#overlap?(range). Giống như Rails, chúng ta có thể sử dụng overlap? để so sánh hai phạm vi và xem chúng có trùng lặp với nhau không.

• Nó trả về true nếu hai phạm vi trùng nhau nếu không thì trả về sai.
• Nó sẽ raise TypeError nếu argument không phải kiểu range

range1 = (3..8)
range2 = (8..10)
range1.overlap?(range2) # => true

range1 = ('a'..'z')
range2 = ('c'..'d')
range1.overlap?(range2) # => true

range1 = (1.day.from_now..5.days.from_now)
range2 = (5.days.from_now..10.days.from_now)
range1.overlap?(range2) # => false

range1 = (1.day.from_now.to_date..5.days.from_now.to_date)
range2 = (5.days.from_now.to_date..10.days.from_now.to_date)
range1.overlap?(range2) # => true

(3..).overlap?(...3) # => false

(3..8).overlap?(3) # => TypeError, argument must be Range

Tham khảo

https://www.ruby-lang.org/en/news/2023/12/11/ruby-3-3-0-rc1-released/
https://railsatscale.com/2023-09-18-ruby-3-3-s-yjit-runs-shopify-s-production-code-15-faster/
https://railsatscale.com/2023-12-04-ruby-3-3-s-yjit-faster-while-using-less-memory/

The post What’s new in Ruby 3.3.0 appeared first on Tomoshare.

Trong Ruby, phương thức JSON.parse dùng để parse chuỗi JSON và chuyển đổi nó thành cấu trúc dữ liệu của Ruby, thường là hash hay array. Chúng ta cũng có thể truyền hai tham số là: object_class và symbolize_names.

• object_class: cho phép bạn chỉ định lớp sẽ được sử dụng để khởi tạo đối tượng cho JSON.
• symbolize_names: nếu bạn truyền tham số symbolize_names với giá trị là true thì key của object sau khi parse là symbol chứ không phải string như mặc định

Link code: Gist

Bài viết gốc: thamdavies.com

That’s it. Happy coding 💯

The post Hiểu thêm về JSON trong Ruby appeared first on Tomoshare.

Warning Ruby 2.7: Pattern matching is experimental, and the behavior may change in future versions of Ruby!

Pattern Matching là gì?

Pattern matching là một tính năng cho phép bạn so sánh và hiểu cấu trúc dữ liệu. Điều này được thực hiện bằng cách kiểm tra cách thông tin được tổ chức và gán các phần tương ứng cho các biến cục bộ để sử dụng sau này.

Pattern Matching được hỗ trợ thông qua cú pháp case / in. Quan trọng là không nhầm lẫn với case / when và không kết hợp chúng. Nếu không có sự phù hợp với bất kỳ biểu thức nào và không có định nghĩa else, thì một ngoại lệ NoMatchingPatternError sẽ được raise

case <expression>
in <pattern1>
  # ...
in <pattern2>
  # ...
else
  # ...
end

Pattern có thể là:

• Value: Any Ruby object (compared with the === operator, as in ‘when’).
• Array: Array pattern: [<subpattern>, <subpattern>, <subpattern>, <subpattern>, ...].
• Find: Search pattern: [*variable, <subpattern>, <subpattern>, <subpattern>, <subpattern>, ..., *variable].
• Hash: Hash pattern: {key: <subpattern>, key: <subpattern>, ...}.
• Alternative: Pattern combination with | (vertical bar).
• Variable capture: <pattern> => variable or variable.

Định nghĩa Pattern Matching

# Define a method that uses pattern matching with case/in
def process_data(data)
  case data
  in { type: "number", value: Integer => num }
    puts "Received a number: #{num}"
  in { type: "string", value: String => str }
    puts "Received a string: #{str}"
  in { type: "array", value: Array => arr }
    puts "Received an array: #{arr}"
  in { type: "hash", value: Hash => hash }
    puts "Received a hash: #{hash}"
  else
    puts "Received something else."
  end
end

# Test the method with different data structures
process_data({ type: "number", value: 42 })               # Output: Received a number: 42
process_data({ type: "string", value: "Hello, Ruby!" })   # Output: Received a string: Hello, Ruby!
process_data({ type: "array", value: [1, 2, 3] })         # Output: Received an array: [1, 2, 3]
process_data({ type: "hash", value: { key: "value" } })   # Output: Received a hash: {:key=>"value"}
process_data({ type: "unknown", value: "unknown data" })  # Output: Received something else.

Deconstruct và Deconstruct_keys

Đây là hai phương thức đặc biệt trong pattern matching: deconstruct, được gọi khi đánh giá trên một Array, và deconstruct_keys được gọi khi đánh giá trên một Hash. Hãy xem một ví dụ:

class Coordinates
  attr_accessor :x, :y

  def initialize(x, y)
    @x = x
    @y = y
  end

  def deconstruct
    [@x, @y]
  end

  def deconstruct_key
    {x: @x, y: @y}
  end
end

Khi một thể hiện của lớp Coordinate được đánh giá trên một Array

c = Coordinates.new(32,50)

case c
in [a,b]
  p a #=> 32
  p b #=> 50
end

Khi một thể hiện của lớp Coordinate được đánh giá trên một Hash

case c
in {x:, y:}
  p x #=> 32
  p y #=> 50
end

Nếu class không có 2 methods trên thì sẽ báo lỗi

#<Coordinate:0x000000010d27fb10 @x=32, @y=50>: #<Coordinate:0x000000010d27fb10 @x=32, @y=50> does not respond to #deconstruct (NoMatchingPatternError)

Tham khảo thêm tại: https://docs.ruby-lang.org/en/master/syntax/pattern_matching_rdoc.html

The post Ruby 3.0 đã chính thức hỗ trợ Pattern Matching appeared first on Tomoshare.