1 điểm bởi GN⁺ 2 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Một phần của Wandering Thoughts và CSpace sẽ hiển thị trang chặn nếu User-Agent của trình duyệt cũ bị các quy tắc chống crawler đánh dấu
  • Từ đầu năm 2025, số lượng crawler quy mô lớn đã tăng lên; một số có vẻ nhằm thu thập dữ liệu để huấn luyện LLM và sử dụng User-Agent Chrome cũ
  • Để giảm tải cho trang, đang thử nghiệm chặn User-Agent của trình duyệt cũ, và người dùng bình thường cũng có thể bị nhận diện nhầm
  • Nếu vẫn bị chặn dù đang dùng trình duyệt mới, có thể liên hệ qua trang cá nhân của Đại học Toronto và cần gửi kèm trình duyệt đang dùng cùng chuỗi User-Agent chính xác
  • Với nhóm archive.*, do dùng User-Agent Chrome cũ và IP phân tán nên khó phân biệt; vì vậy archive.org được khuyến nghị cho kho lưu trữ của Wandering Thoughts

Vì sao trang chặn được hiển thị

  • Khi truy cập Wandering Thoughts hoặc một phần của CSpace, nếu phiên bản trình duyệt bị hệ thống chống crawler của trang phân loại là đáng ngờ thì trang chặn sẽ được hiển thị
  • Tính đến đầu năm 2025, số lượng crawler quy mô lớn đã tăng lên; một số dường như nhằm thu thập dữ liệu để huấn luyện LLM và sử dụng nhiều User-Agent trình duyệt cũ, bao gồm Chrome User-Agent
  • Đang tiến hành thử nghiệm chặn User-Agent của trình duyệt cũ để giảm tải cho trang, và người dùng hợp lệ cũng có thể vướng quy tắc này
  • Nếu đang dùng trình duyệt mới mà vẫn bị chặn, bạn có thể liên hệ qua trang cá nhân của Đại học Toronto, và nếu có thể hãy gửi kèm trình duyệt đang dùng cùng chuỗi User-Agent chính xác

Lưu ý theo từng loại người dùng

  • Người dùng Inoreader

    • Trình thu thập feed của Inoreader bản thân nó không thuộc diện bị chặn và thực tế vẫn đang lấy feed định kỳ
    • Inoreader có thể dùng HTTP User-Agent trình duyệt cũ hoặc chính trình duyệt cũ để lấy feed hay trang, rồi hiển thị cho người dùng trang chặn mà nó nhận được từ kết quả đó
    • Kết quả của các yêu cầu HTTP hiện tại có thể khác nhau tùy theo HTTP User-Agent được sử dụng; nội dung liên quan có tại HTTPResultsAndUserAgents
  • Người dùng Vivaldi

    • Do cuộc tấn công đang diễn ra, ngay cả Vivaldi mới nhất cũng có thể bị chặn nếu bị nhận diện là Google Chrome
    • Có thể cần thay đổi thiết lập "User Agent Brand Masking" để Vivaldi được nhận diện là Vivaldi thay vì Google Chrome
  • Người dùng archive.*

    • Bạn có thể thấy trang chặn này thông qua archive.today, archive.ph, archive.is, v.v.
    • archive.* dùng Chrome User-Agent cũ, crawl từ các dải IP phân tán rộng và một số IP còn có bản ghi DNS ngược giả mạo tự nhận là IP của googlebot, nên rất khó phân biệt với tác nhân độc hại
    • Nếu muốn lưu trữ Wandering Thoughts, nên dùng archive.org, một crawler lưu trữ hoạt động tốt hơn

1 bình luận

 
Ý kiến trên Lobste.rs
  • Tùy ngôn ngữ, lời khuyên tự động khởi động Eglot có thể cực kỳ tệ hại. Nhiều máy chủ LSP không an toàn để dùng với mã không đáng tin cậy, và chỉ cần mở file trong một dự án Rust hoặc Elixir do kẻ tấn công kiểm soát cũng có thể khiến máy bị xâm nhập
    Trừ khi đó là ngôn ngữ có máy chủ LSP được biết là an toàn, nên tránh tự động kích hoạt LSP. Nguồn: https://rust-analyzer.github.io/book/security.html

    • Nếu phải xem mã có thể mang tính thù địch, cuối cùng bạn nên làm toàn bộ công việc bên trong một ranh giới bảo mật thực sự. Ngay cả git status cũng có thể là bề mặt tấn công: https://github.com/justinsteven/advisories/…
      Khác biệt là ở ví dụ trên, bản thân kho chứa phải có exploit, còn với LSP thì vấn đề cũng có thể phát sinh từ phía dependency. Dù vậy, nếu đã quen bật LSP theo thói quen thì có vẻ khó tránh việc trở nên chai lì trước các cảnh báo
    • Một lý do khác để tránh tự động khởi động là yêu cầu tài nguyên của một số máy chủ ngôn ngữ rất lớn. Chỉ cần mở thoáng qua một file trong dự án Rust cỡ trung bình cũng có thể làm tiến trình rust-analyzer 4GB chạy hàng phút, và tạo ra thư mục target/debug/ hơn 1GB
    • Dù sao thì ngay khi chạy cargo build coi như cũng đã xong rồi. Tất nhiên, giữa tự động nạp LSP và lệnh do người dùng chủ động chạy vẫn có khác biệt lớn, nhưng trong sử dụng thực tế có khi khác biệt lại nhỏ hơn tưởng tượng
    • Nếu muốn tự động hóa, cách tốt hơn là hỏi trước khi kích hoạt như lsp-mode, rồi thêm dự án vào danh sách cho phép. Nếu đã có hook “chạy tự động” thì chỉ cần khoảng 10 dòng với read-from-minibuffer để hỏi trước “bạn có tin cậy thư mục này không?”, và dùng thứ như projectile để lấy thư mục gốc thì có thể đạt được phần lớn lợi ích bảo mật
      Cấu hình của tôi dùng danh sách cho phép của lsp-mode nhưng xóa nó sau mỗi phiên, để mỗi lần mở lại Emacs thì phải đồng ý lại theo từng dự án. Hình như ban đầu tôi làm vậy vì hiệu năng, và có lúc lsp-mode khởi chạy nhiều tiến trình trước cả khi mở một dự án cụ thể. Rủi ro bảo mật là có thật, nhưng để tạo ra một workflow ổn thì không quá khó
  • Điều khó chịu nhất ở Eglot là nó không phơi bày phần lớn lệnh dưới dạng hàm, mà định nghĩa chúng trên các giao diện Emacs như xref. Khi có cả backend xref của CIDER lẫn clojure-lsp như trong Clojure, tôi thường thích phía CIDER hơn vì nó biết trạng thái runtime thực của đoạn mã đã nạp
    Phân tích tĩnh của clojure-lsp đặc biệt dễ lệch đồng bộ, nhất là trong workflow REPL từ xa. Với lsp-mode, bạn vẫn có thể gọi trực tiếp các chức năng như đi tới định nghĩa dưới dạng lệnh mà vẫn tiếp tục dùng xref, nhưng trong Eglot thì việc loại riêng một backend xref cụ thể khá phiền. Một số lệnh khác có trong lsp-mode cũng thiếu ở Eglot, dù thực ra chúng có thể được cung cấp qua các điểm tích hợp Emacs tương tự như xref

  • Tôi đã thử lsp-mode một lần, nhưng quá nhiều popup và thông báo gây rối nên xóa ngay. Eglot cho trải nghiệm LSP yên tĩnh hơn nhiều
    Cứ bật đó, đến khi sẵn sàng thì dùng tính năng. Cách ~cks tiếp cận từ hướng ngược lại và nhắc đến nhiều mẹo cùng lựa chọn thay thế khá thú vị

    • Tôi đang dùng lsp-mode với khá nhiều tính năng đã tắt đi nên giao diện cũng khá yên tĩnh. Tôi từng định chuyển sang Eglot nhưng lúc đó có vẻ nó thiếu các tích hợp mà tôi muốn nên không thử thêm nữa
      Điều tôi thực sự muốn tìm là một máy chủ LSP có thể xử lý kho mã rất lớn. Đây thường là giới hạn lớn nhất, và tôi từng nghĩ có lẽ phải tự làm thứ gì đó lập chỉ mục mã nguồn gần như một lần rồi tái sử dụng cho nhiều thao tác kiểu LSP, nhưng lại lo mình đang định đun sôi thêm một đại dương nữa
  • Trong các client LSP cho Emacs, Eglot và lsp-mode là nổi tiếng nhất, nhưng cũng có các lựa chọn khác như lspcelsp-bridge
    Tôi đã dùng Eglot hài lòng nhiều năm, nhưng nó có một giới hạn thiết kế có thể sẽ thành vấn đề lớn hơn về sau. Nó giả định mỗi buffer chỉ có một client, điều này hợp lý vào thời điểm Eglot ra đời, nhưng giờ ngày càng thường gặp các trường hợp muốn chạy nhiều máy chủ LSP trong một buffer. [Khuyến nghị] hiện tại là dùng một chương trình riêng làm bộ ghép kênh LSP

  • Tôi đã chuyển từ lsp-mode sang Eglot cho Python cách đây 4 ngày và khá hài lòng
    Tôi đã công khai phiên bản tối thiểu của cấu hình hiện tại ở đây: https://discuss.afpy.org/t/configuration-emacs-minimale-en-2026/3001

    • Tôi đã chuyển từ elpy sang eglot + basedpyright gần một năm trước, và tôi cũng khá hài lòng
      Tuy vậy vẫn có chút bất tiện về hoàn thành. Ví dụ, khi nhấn foo<tab><tab>, đôi khi basedpyright lại tự import thứ gì đó kỳ quặc dù có symbol phù hợp ngay trong scope hiện tại, và tôi vẫn chưa tìm ra cách chỉ hoàn thành đến chuỗi chung dài nhất. Ngoài ra thì khá ổn
  • Tôi ghen tị với những người biến Emacs thành một IDE hiện đại. Tôi dùng phím tắt Emacs, nhưng dù bỏ ra 6–8 tiếng tôi vẫn không làm được để Emacs hoạt động như IDE
    Trước đây tôi từng cố thiết lập theo FB Flow mà mình dùng thay TypeScript trong môi trường phát triển Linux và FreeBSD rồi bỏ cuộc, và cuối tuần trước lại bỏ cuộc khi cố dựng một môi trường Python đầy đủ tính năng trên Windows kèm tree-sitter. Có quá nhiều thứ phải cấu hình, lại còn phải tải riêng quá nhiều DLL như parser tree-sitter, nên để biến nó thành một IDE tử tế thì cần quá nhiều thứ. Giờ tôi không còn muốn đầu tư thời gian nữa, nhưng thỉnh thoảng gõ emacs -nw ở bất kỳ terminal nào và có ngay môi trường soạn thảo quen thuộc vẫn rất thích

    • Nếu là Python thì chỉ cần cấu hình tối thiểu với fido-vertical-mode, which-key-mode, global-completion-preview-mode, yasnippet, eglot-ensure, basedpyright là đã đủ để bắt đầu
      Nếu basedpyright có trong PATH thì bạn vẫn có hoàn thành và tô sáng cú pháp tử tế mà không cần ngữ pháp tree-sitter. Đây là bản rút gọn tối thiểu từ cấu hình đầy đủ của tôi, còn cấu hình đầy đủ ở my full config
    • Có thể thử doom emacs. Việc cấu hình rất dễ và ngay ở trạng thái mặc định thì hầu hết mọi thứ đã hoạt động tốt. Nếu không thích evil-mode thì cũng có thể quay lại phím tắt Emacs