- 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 cũ
- Đ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
git statuscũ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
rust-analyzer4GB chạy hàng phút, và tạo ra thư mụctarget/debug/hơn 1GBcargo buildcoi 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ượnglsp-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ớiread-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ậtCấu hình của tôi dùng danh sách cho phép của
lsp-modenhư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úclsp-modekhở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ả backendxrefcủaCIDERlẫnclojure-lspnhư trong Clojure, tôi thường thích phíaCIDERhơn vì nó biết trạng thái runtime thực của đoạn mã đã nạpPhâ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ớilsp-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ùngxref, nhưng trong Eglot thì việc loại riêng một backendxrefcụ thể khá phiền. Một số lệnh khác có tronglsp-modecũ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ưxrefTôi đã thử
lsp-modemộ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ềuCứ 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ị
lsp-modevớ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-modelà nổi tiếng nhất, nhưng cũng có các lựa chọn khác như lspce và lsp-bridgeTô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-modesang Eglot cho Python cách đây 4 ngày và khá hài lòngTô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
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 khibasedpyrightlạ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á ổnTô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íchfido-vertical-mode,which-key-mode,global-completion-preview-mode,yasnippet,eglot-ensure,basedpyrightlà đã đủ để bắt đầuNếu
basedpyrightcó 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 configdoom 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íchevil-modethì cũng có thể quay lại phím tắt Emacs