Thảo luận kỹ thuật: có thể gọi hàm DLL 64-bit từ VBA/VB6 32-bit thông qua bridge WOW64 không (2 người xem)

Người dùng đang xem chủ đề này

Tôi tuân thủ nội quy khi đăng bài

phuongnam366377

Thành viên thường trực
Tham gia
25/10/19
Bài viết
276
Được thích
243
Rảnh mở chủ đề này xem có ai ý kiến gì không và cũng thử xem trên này có nhiều thành viên lý thuyết kinh điển lắm tham gia bà tám chơi thôi

Keo ChatGPT viết bài sau ... Copy nội dung y trang ChatGPT viết dưới

Thảo luận kỹ thuật: có thể gọi hàm DLL 64-bit từ VBA/VB6 32-bit thông qua bridge WOW64 không​

Chào các anh/chị,

Mình đang tìm hiểu về WOW64 và khả năng tương tác giữa tiến trình 32-bit với môi trường 64-bit trên Windows.

Khi tìm kiếm thì đa số tài liệu đều nói:

  • process 32-bit không thể load trực tiếp DLL 64-bit
  • VBA/VB6 32-bit không thể gọi native x64 DLL theo cách thông thường
  • giải pháp thường là:
    • COM out-of-process
    • EXE trung gian
    • .NET bridge
    • IPC / Named Pipe / RPC
Tuy nhiên mình thấy có một ví dụ khá thú vị:

https://github.com/thetrik/Vb64BitDllUsage

Ví dụ này có vẻ sử dụng kỹ thuật WOW64 transition / thunking để gọi một số hàm 64-bit từ VB6/VBA 32-bit.

Mình muốn hỏi thêm về hướng kỹ thuật này:

  1. Bản chất kỹ thuật ở đây thực sự là gì?
    • thunk?
    • heaven gate?
    • WOW64 transition?
    • shellcode bridge?
    • hay một dạng trampoline đặc biệt?
  2. Về lý thuyết có thể mở rộng thành:
    • gọi dynamic nhiều hàm x64 khác nhau
    • marshal tham số Unicode/structure
    • đọc PEB64
    • resolve export table
    • generic invoke engine
      được không?
  3. Những giới hạn lớn nhất của hướng này là gì?
    • stack alignment?
    • x64 calling convention?
    • SEH?
    • crash IDE VBA/VB6?
    • DEP/CFG?
    • antivirus/EDR?
  4. Có ai từng thấy project nào public theo hướng này chưa?
    Ngoài ví dụ của thetrik thì mình tìm Google hầu như chỉ thấy:
    • câu hỏi lý thuyết
    • trả lời “không thể”
    • hoặc giải pháp dùng process trung gian.
  5. Theo các anh/chị, nếu triển khai thật thì:
    • hiệu năng có quá tệ không?
    • có ổn định không?
    • có phù hợp production không?
    • hay chỉ nên xem như proof-of-concept nghiên cứu?
Mình chủ yếu muốn tìm hiểu thêm về:

  • WOW64 internals
  • Windows loader
  • thunking giữa 32-bit ↔ 64-bit
  • khả năng mở rộng của VBA/VB6
Rất mong được nghe thêm các góc nhìn kỹ thuật và phản biện từ mọi người.

Tham khảo bài viết của Raymond Chen


Các Link tham khảo




Keo ChatGPT phân tích thấy dòng hay

1778820907803.png
ChatGPT kết luận

1778821227745.png
 
Lần chỉnh sửa cuối:
lang thang google tìm ý tưởng thấy link sau cho ai thích thì tham khảo

Kỹ thuật này sử dụng tốt có thể kéo dài vòng đời VB6 hay ứng dụng 32 bít sống thêm một thời gian nữa nhưng nó sẽ phát sinh lỗi khi sử dụng DLL ngoài hạng nặng các phụ thuộc nhiều còn nếu gọi các API 64 bít của Ms rất tốt

Mới dựa vào phương pháp đó viết DLL được 10 ngày thì nay nhìn lại thấy lạc hậu rồi .. và nhờ có ý tưởng đó viết hệ thống tương thích ngược phân tán đa luồng hay hơn

VB6 32 bít hay ứng dung 64 bit dùng chung tốt và không lỗi khi sử dụng DLL với các hàm xử lý dữ liệu lớn

như vậy Vô tình kéo dài vòng đời VB6 khi tái sử dụng DLL 64 bít do người dùng tự định nghĩa lên gần như vô hạn nếu người dùng vẫn thích VB6
vì không còn lệ thuộc kỹ thuật Hack của Thetrix nữa

Thông qua AI vô tình khám phá ra và biết về thuật Ngữ ABI .... còn Copilot mô tả như sau
API là giao diện ở mức mã nguồn, còn ABI là giao diện ở mức mã máy sau khi biên dịch. API dành cho lập trình viên sử dụng trực tiếp, trong khi ABI quan trọng với trình biên dịch, hệ điều hành và khả năng tương thích nhị phân giữa các phần mềm.

Sự khác biệt chính​

Tiêu chíAPI (Application Programming Interface)ABI (Application Binary Interface)
Mức độMã nguồn (source level)Mã máy/nhị phân (binary level)
Đối tượng sử dụngLập trình viên viết codeTrình biên dịch, hệ điều hành, thư viện
Định nghĩaTập hợp hàm, lớp, phương thức, cấu trúc dữ liệu mà lập trình viên có thể gọiQuy ước nhị phân: cách tham số được truyền, giá trị trả về, cách gọi hàm, bố cục dữ liệu trong bộ nhớ
Ví dụThư viện C++ có hàm printf() trong header fileQuy ước gọi hàm x86: tham số truyền qua stack hay thanh ghi, giá trị trả về nằm ở đâu
Tính ổn địnhThay đổi API buộc lập trình viên sửa codeThay đổi ABI có thể khiến chương trình biên dịch chạy sai hoặc crash dù code không đổi
Mục tiêuTạo giao diện dễ dùng, dễ đọc cho con ngườiĐảm bảo các chương trình nhị phân khác nhau có thể chạy cùng nhau trên cùng nền tảng

Ví dụ minh họa​


  • API: Trong Java, bạn gọi List<String> getStrings(). Đây là cách bạn tương tác với thư viện ở mức mã nguồn.

  • ABI: Sau khi biên dịch, cả List<String>List<Integer> có thể được biểu diễn giống nhau trong bytecode do cơ chế type erasure. Đây là ABI – cách dữ liệu và hàm được biểu diễn ở mức nhị phân. Baeldung Stack Overflow vi.wikipedia.org

Khi nào quan trọng?​


  • API: Khi bạn viết ứng dụng, dùng thư viện, hoặc thiết kế framework.

  • ABI: Khi bạn muốn phần mềm biên dịch trên một hệ thống có thể chạy trên hệ thống khác mà không cần sửa đổi (ví dụ: Linux giữ ABI ổn định để các ứng dụng binary chạy lâu dài).
Tóm lại: API dành cho lập trình viên, ABI dành cho máy tính. Nếu API thay đổi, bạn phải sửa code; nếu ABI thay đổi, chương trình có thể không chạy được dù code không đổi.
Bạn có muốn mình lấy thêm ví dụ cụ thể trong ngôn ngữ C/C++ để thấy rõ sự khác biệt giữa API (header file) và ABI (cách hàm được gọi ở mức assembly)?
 
[Copilot]
Loạt thảo luận này trên GiaiphapExcel xoay quanh một chủ đề kỹ thuật rất “nặng đô”: làm sao để gọi hàm DLL 64-bit từ môi trường VBA/VB6 vốn chỉ chạy 32-bit, thông qua cơ chế WOW64. Đây là một vấn đề phức tạp, thường được coi là “không thể” theo cách thông thường, nhưng có một số proof-of-concept và dự án thử nghiệm đã chứng minh có thể làm được bằng các thủ thuật đặc biệt.

Nội dung chính của chủ đề​

  • Người khởi xướng: phuongnam366377, đặt câu hỏi về khả năng gọi DLL 64-bit từ VBA/VB6 32-bit.
  • Bối cảnh kỹ thuật:
    • Windows có cơ chế WOW64 để cho phép ứng dụng 32-bit chạy trên hệ điều hành 64-bit.
    • Tuy nhiên, tiến trình 32-bit không thể load trực tiếp DLL 64-bit.
    • Giải pháp thường thấy: dùng process trung gian (COM out-of-process, .NET bridge, IPC, RPC).
  • Điểm mới: tác giả tìm thấy một ví dụ trên GitHub (thetrik/Vb64BitDllUsage) cho thấy có thể dùng kỹ thuật “WOW64 transition/thunking” để gọi một số hàm 64-bit từ VB6/VBA.

Các hướng thảo luận nổi bật​

  • Khái niệm kỹ thuật:
    • “Thunking”, “Heaven’s Gate”, “Shellcode bridge”, “Trampoline” – các cơ chế chuyển ngữ cảnh giữa 32-bit ↔ 64-bit.
    • Các giới hạn: stack alignment, calling convention x64, SEH, DEP/CFG, antivirus/EDR.
  • Ví dụ thực tế:
    • Dự án X64Bridge trên GitHub cho phép gọi DLL 64-bit từ VB6/VBA 32-bit bằng “WOW64 Segment Trick”.
    • Một proof-of-concept khác: WoW64Injection – tiêm DLL 64-bit vào ứng dụng 32-bit.
  • Ứng dụng:
    • Có thể kéo dài vòng đời của VB6/VBA bằng cách tận dụng DLL 64-bit.
    • Nhưng rủi ro cao: dễ crash IDE, không ổn định, khó dùng trong môi trường production.
  • Khái niệm ABI vs API:
    • Copilot giải thích: API là giao diện ở mức mã nguồn (hàm, lớp, cấu trúc dữ liệu).
    • ABI là giao diện ở mức nhị phân (cách tham số truyền qua stack/thanh ghi, cách giá trị trả về được lưu).
    • Thay đổi API buộc sửa code; thay đổi ABI có thể khiến chương trình biên dịch chạy sai dù code không đổi.

⚖️ Nhận xét tổng hợp​

  • Điểm mạnh: Chủ đề này rất sâu, hiếm khi được bàn trong cộng đồng Excel. Nó mở ra hướng nghiên cứu cho những ai muốn “hack” giới hạn của VBA/VB6.
  • Điểm yếu: Tính thực tiễn thấp, chủ yếu là proof-of-concept. Khó áp dụng cho sản phẩm thương mại vì rủi ro crash và bảo mật.
  • Ý nghĩa: Giúp thành viên hiểu rõ hơn về cơ chế WOW64, sự khác biệt giữa API và ABI, và lý do tại sao Microsoft khuyến nghị chuyển sang .NET hoặc môi trường 64-bit native.
Nói ngắn gọn: Đây là một loạt thảo luận rất chuyên sâu, thiên về nghiên cứu và thử nghiệm, hơn là giải pháp thực tế cho Excel. Nó cho thấy cộng đồng GPE vẫn có những thành viên thích “đi tới tận cùng” của kỹ thuật, dù đa số người dùng chỉ cần giải pháp an toàn và ổn định.

Bác Sa có muốn tôi rút gọn thành 3–4 ý chính dễ nhớ (kiểu “chốt hạ” cho người không chuyên) để bác đọc nhanh mà vẫn nắm được tinh thần của loạt thảo luận này không?
 
[Copilot]
Loạt thảo luận này trên GiaiphapExcel xoay quanh một chủ đề kỹ thuật rất “nặng đô”: làm sao để gọi hàm DLL 64-bit từ môi trường VBA/VB6 vốn chỉ chạy 32-bit, thông qua cơ chế WOW64. Đây là một vấn đề phức tạp, thường được coi là “không thể” theo cách thông thường, nhưng có một số proof-of-concept và dự án thử nghiệm đã chứng minh có thể làm được bằng các thủ thuật đặc biệt.

Nội dung chính của chủ đề​

  • Người khởi xướng: phuongnam366377, đặt câu hỏi về khả năng gọi DLL 64-bit từ VBA/VB6 32-bit.
  • Bối cảnh kỹ thuật:
    • Windows có cơ chế WOW64 để cho phép ứng dụng 32-bit chạy trên hệ điều hành 64-bit.
    • Tuy nhiên, tiến trình 32-bit không thể load trực tiếp DLL 64-bit.
    • Giải pháp thường thấy: dùng process trung gian (COM out-of-process, .NET bridge, IPC, RPC).
  • Điểm mới: tác giả tìm thấy một ví dụ trên GitHub (thetrik/Vb64BitDllUsage) cho thấy có thể dùng kỹ thuật “WOW64 transition/thunking” để gọi một số hàm 64-bit từ VB6/VBA.

Các hướng thảo luận nổi bật​

  • Khái niệm kỹ thuật:
    • “Thunking”, “Heaven’s Gate”, “Shellcode bridge”, “Trampoline” – các cơ chế chuyển ngữ cảnh giữa 32-bit ↔ 64-bit.
    • Các giới hạn: stack alignment, calling convention x64, SEH, DEP/CFG, antivirus/EDR.
  • Ví dụ thực tế:
    • Dự án X64Bridge trên GitHub cho phép gọi DLL 64-bit từ VB6/VBA 32-bit bằng “WOW64 Segment Trick”.
    • Một proof-of-concept khác: WoW64Injection – tiêm DLL 64-bit vào ứng dụng 32-bit.
  • Ứng dụng:
    • Có thể kéo dài vòng đời của VB6/VBA bằng cách tận dụng DLL 64-bit.
    • Nhưng rủi ro cao: dễ crash IDE, không ổn định, khó dùng trong môi trường production.
  • Khái niệm ABI vs API:
    • Copilot giải thích: API là giao diện ở mức mã nguồn (hàm, lớp, cấu trúc dữ liệu).
    • ABI là giao diện ở mức nhị phân (cách tham số truyền qua stack/thanh ghi, cách giá trị trả về được lưu).
    • Thay đổi API buộc sửa code; thay đổi ABI có thể khiến chương trình biên dịch chạy sai dù code không đổi.

⚖️ Nhận xét tổng hợp​

  • Điểm mạnh: Chủ đề này rất sâu, hiếm khi được bàn trong cộng đồng Excel. Nó mở ra hướng nghiên cứu cho những ai muốn “hack” giới hạn của VBA/VB6.
  • Điểm yếu: Tính thực tiễn thấp, chủ yếu là proof-of-concept. Khó áp dụng cho sản phẩm thương mại vì rủi ro crash và bảo mật.
  • Ý nghĩa: Giúp thành viên hiểu rõ hơn về cơ chế WOW64, sự khác biệt giữa API và ABI, và lý do tại sao Microsoft khuyến nghị chuyển sang .NET hoặc môi trường 64-bit native.
Nói ngắn gọn: Đây là một loạt thảo luận rất chuyên sâu, thiên về nghiên cứu và thử nghiệm, hơn là giải pháp thực tế cho Excel. Nó cho thấy cộng đồng GPE vẫn có những thành viên thích “đi tới tận cùng” của kỹ thuật, dù đa số người dùng chỉ cần giải pháp an toàn và ổn định.

Bác Sa có muốn tôi rút gọn thành 3–4 ý chính dễ nhớ (kiểu “chốt hạ” cho người không chuyên) để bác đọc nhanh mà vẫn nắm được tinh thần của loạt thảo luận này không?
hiếm khi thấy bác sa tham gia chủ đề của Mạnh

câu trả lời là làm được mọi cái từ không thể thành có thể nha Bác ( nếu không có AI hổ trợ thì quá khó luôn )

1/ lấy ý tưởng của Thetrik viết cũng đã sử dụng tốt VB6 là 32 bít gọi các hàm API 64 bit rất tôt .. tuy nhiên chỉ tốt khi gọi API của Ms còn các hàm có trong DLL 64 do người dùng tự định nghĩa là lỗi Crash chắc chắn luôn ( bài số 3 có nói qua )

2/ dựa trên ý tưởng đó Tôi phat triển thêm một thư viện mới BridgeInvoker64.dll và BridgeHost.exe làm cầu nối trung gian chạy trên máy chủ Windows 64 bít còn máy khách không phân biệt ngôn ngữ hay 32 và 64 bít điều có thể gọi các hàm 64 bít tốt từ bất kỳ ngôn ngữ nào viết DLL 64 bít như Go, C++/C++Builder Delphi vvv dựa trên kỹ thuật

có thể tham khảo các linh sau


1780995979340.png




và nhiều linh khác với từ khoá



3/ tại làm biếng úp lên đây ... nếu Bác sa có muốn phụ Mạnh thử mã thì ngày mai hay mốt mạnh úp lên đây nhờ bác test dùm xem sao

yêu cầu máy chủ sử dụng là Windows64 bít còn thử tại máy luôn cho máy khách là 32 hay 64 bit hoạt động tốt

hay các máy khác trong internet không phân biệt hệ điều hành hay ngôn ngữ , 32 hay 64 bít miễm kết nối đúng Fornat là gọi hàm DLL 64 bít tốt

4/ thực tế trên máy mạnh thử các môi trường 32 hay 64 bít tốt và thử trên VB6 gọi hàm 64 bit tôt

Bác thấy sao nếu đồng ý test dùm thì mai hay mốt mạnh úp lên đây
 
Lần chỉnh sửa cuối:
còn bài Sau do ChatGPT giải thích tạm ổn cho thành viên có vẽ học hành code code trường lớp

Tôi xin nói rõ thêm một chút vì có lẽ nhiều anh em đang nhầm giữa hai giai đoạn khác nhau của quá trình nghiên cứu.

Đúng là ban đầu tôi dựa trên ý tưởng của Thetrik và các tài liệu liên quan đến WOW64 Transition / Heaven's Gate.

Repo của Thetrik có giá trị rất lớn vì nó chứng minh được một điều:

Tiến trình VB6/VBA 32-bit hoàn toàn có thể chuyển sang ngữ cảnh 64-bit và thực thi code 64-bit.

Nói cách khác, câu hỏi:

"VB6 có thể gọi code 64-bit hay không?"

đã được trả lời từ lâu là:

"Có thể."

Tuy nhiên khi bắt tay vào làm thực tế, tôi gặp một vấn đề khác.

Các ví dụ demo thường thành công với một số API 64-bit của Microsoft hoặc các hàm rất đơn giản.

Nhưng khi thay bằng DLL 64-bit do chính người dùng tự phát triển thì bắt đầu xuất hiện hàng loạt vấn đề:

  • ABI
  • Struct
  • Unicode
  • Callback
  • Memory ownership
  • Exception
  • Alignment
  • Lifetime management
Lúc đó việc "gọi được" không còn là vấn đề nữa.

Vấn đề là "gọi ổn định".

Sau một thời gian thử nghiệm tôi nhận ra rằng:

X64Bridge chỉ giải quyết được bài toán chuyển ngữ cảnh x86 ↔ x64.

Nó chưa giải quyết triệt để bài toán vận hành DLL 64-bit tùy biến trong môi trường thực tế.

Vì vậy tôi tiếp tục phát triển theo hướng khác:

VB6/VBA (32-bit)

BridgeInvoker64.dll

BridgeHost.exe (64-bit)

DLL 64-bit

Ở kiến trúc này:

  • DLL 64-bit chạy native 64-bit
  • Không phụ thuộc vào việc chuyển segment cho từng lời gọi
  • Có thể chuẩn hóa ABI
  • Có thể kiểm soát lỗi
  • Có thể mở rộng cho nhiều ngôn ngữ khác nhau
  • Lỗi DLL không làm sập trực tiếp VBA/VB6
Do đó nếu nhìn vào GitHub của tôi và chỉ kết luận:

"Đây là một bản khác của Heaven's Gate"

thì chưa hoàn toàn chính xác.

Heaven's Gate hay WOW64 Segment Trick chỉ là điểm xuất phát.

Điều tôi quan tâm hơn là xây dựng một lớp bridge ổn định giữa thế giới 32-bit và 64-bit.

Nói cách khác:

Thetrik giúp chứng minh rằng cánh cửa tồn tại.

Còn phần lớn công việc sau đó là tìm cách biến cánh cửa đó thành một con đường có thể sử dụng được trong thực tế.
 
Gửi Bác SA và các anh em quan tâm thử nghiệm thực tế.

Tôi cung cấp:

  • Mã nguồn mở Plugin DLL mẫu.
  • Mã VBA/VB6 đơn giản nhất làm máy khách.
  • File thử nghiệm sẵn để kiểm chứng hoạt động thực tế.
Mục đích là để mọi người có thể tự kiểm tra toàn bộ cơ chế RPC từ đầu đến cuối, sau đó dựa trên mã VBA/VB6 để viết máy khách bằng các ngôn ngữ khác như Delphi, C/C++, C#, Go, Python hoặc ngôn ngữ khác tùy nhu cầu.

  1. Cài đặt Server
  • Copy thư mục "Bridge RPC Server" vào vị trí bất kỳ trên máy.
  • Chạy BridgeHost.exe để thử nghiệm nhanh.
  • Nếu muốn chạy như dịch vụ Windows thì sử dụng BridgeSvc.exe.
  1. Chạy Client Demo
  • Mở file BridgeRPC_VBA_x32_x64_Demo.xlsb.
  • Chạy các Sub thử nghiệm đã có sẵn.
  • Hoặc sử dụng các project VB6 mẫu 32-bit đi kèm.
  1. Lưu ý quan trọng
Trong mã mẫu đang sử dụng đường dẫn DLL tuyệt đối. Cần sửa lại cho đúng với máy của mình.

Ví dụ:

Private Const DLL_TEST As String = "C:\BridgeServer_Test\TestDll64.dll"

Đường dẫn này phải tồn tại thực tế trên máy chạy Bridge RPC Server.

Nếu thay đổi vị trí thư mục hoặc tên DLL thì cần sửa lại hằng số tương ứng.

  1. Mã nguồn Plugin DLL
Kèm theo mã nguồn đầy đủ của TestDll64.dll viết bằng Delphi 13.1 Win64.

Người dùng có thể:

  • Tự build lại DLL từ mã nguồn.
  • Tự thêm hoặc sửa hàm.
  • Tự triển khai các DLL nghiệp vụ riêng.
  • Tự kiểm chứng kết quả khi gọi từ VBA/VB6.
Các hàm mẫu hiện có:

  • AddIntegers
  • DoubleValue
  • GetGreeting
  • FillBuffer
  • MyTickCount
  • Sum16Integers
  • ComplexCalc
  • SearchFilesToBuffer
  • SumArray
  • SumArrayF64
Các hàm này minh họa nhiều kiểu dữ liệu khác nhau:

  • Int64
  • UInt64
  • Double
  • Chuỗi Unicode
  • Buffer xuất dữ liệu
  • Mảng số nguyên
  • Mảng số thực
  • Hàm nhiều tham số
  1. Khả năng mở rộng đa ngôn ngữ, đa nền tảng
Mã VBA/VB6 chỉ là ví dụ tối giản để mọi người dễ kiểm chứng.

Nếu tuân thủ đúng Format Request/Response và quy ước ABI của hệ thống thì hoàn toàn có thể tự viết máy khách bằng:

  • Delphi
  • C/C++
  • C#
  • Go
  • Python
  • Java
  • Rust
  • Node.js
  • PHP
  • Các ngôn ngữ khác
Máy khách không bắt buộc phải chạy trên Windows.

Về nguyên tắc, bất kỳ hệ điều hành nào có thể:

  • Kết nối TCP/IP tới Bridge RPC Server
  • Đóng gói Request đúng Format
  • Phân tích Response đúng Format
đều có thể xây dựng máy khách tương thích.

  1. Kết quả mong đợi
Sau khi cấu hình đúng:

  • Client kết nối được tới Bridge RPC Server.
  • Gọi thành công các hàm trong TestDll64.dll.
  • Nhận được kết quả trả về từ server.
  1. Hỗ trợ kiểm tra lỗi
Nếu gặp lỗi, vui lòng gửi:

  • Log phía Client.
  • Log BridgeHost hoặc BridgeSvc.
  • Mã nguồn thử nghiệm tối thiểu.
Mô hình như sau
1781061550395.png
để mọi người cùng kiểm tra và đối chiếu.
 

File đính kèm

Lần chỉnh sửa cuối:
sẽ nâng cấp dự án mã này lên sử dụng Token ... thời đại AI một mét vuông vài tay đạo tặc

Viết Server + Client thiếu bảo mật thì chỉ dùng nội bộ trong LAN thôi

máy chủ cấp cấu hình .json cho máy khách như sau và mã hoá token

cli_547375a0.json

Mã:
{
  "type"      : "bridge_client",
  "version"   : 2,
  "client_id" : "cli_547375a0",
  "key_id"    : "kid_28bf",
  "api_key"   : "22252f53387a4ae1d09357f09454f47bbd61e675141e2a7a036587ff799bb0a8",
  "server"    : "127.0.0.1",
  "port"      : 9000
}
 
sau một ngày định hình thành công ... tài liệu BridgeRPC_V4_Guide.html như sau

ai quan tâm mã nguồn hay tham gia phát triển dự án từng phần có thể liên hệ phát triển nâng tầm thành hệ sinh thái quanh BridgeCore.dll

Tôi xem xét hổ trợ

1/ Gọi bất kỳ hàm trong DLL 64 bít nào có trên Windows ( DLL người dùng tự định nghĩa hay gọi API của Ms )

Ví dụ máy khách trên hệ điều hành khác viết Client theo mô tả bài #7 thì vẫn có thể sử dụng các thư viện API của Ms trên Windows cho hệ điều hành khác tốt

2/ đọc ghi dữ liệu từ xa vào Data.accdb tốt có thể mở rộng các Puligin.dll theo chuyên đề

3/ Tải file và úp file hai chiều máy chủ máy khách tốt

4/ Viết các Puigin.dll theo chuyên đề do người dùng tự định nghĩa theo chuẩn Format mô tả bài số 7

5/ bản nâng cấp này hổ trợ bảo mật Token theo máy khách khi máy khách lộ token thì máy chủ người quản trị xoá token đó và các máy khác không ảnh hưởng vì token cấp theo từng máy khách nhau và duy nhất

1781138887911.png

Thiết kế dữ liệu Json để tương thích với đa số dữ liệu json mà các Web đang sử dụng ... người dùng tự định nghĩa phân tách Json trên VBA hay bất kỳ ngôn ngữ nào nếu thích

Thử lấy dữ liệu Access trả về JSON cho máy khách trên VB6 vậy là từ bất cứ hệ điều hành nào hay ngôn ngữ nào viết máy khách điều có thể sử dụng hàm trên máy chủ Windows 64 bít tốt dựa vào mã VBA/VB6 bài số 7 là viết tốt máy khách theo sở thích

1781140863149.png
 

File đính kèm

Lần chỉnh sửa cuối:
Trình quản lý hệ thống máy chủ với Token đã hình thành nhờ sự hổ trợ từ AI

Nhờ từ công bố của Thetrik và sự hổ trợ của AI một hệ sinh thái mới hình thành tương thích ngược và từng bước hiện đại hoá theo thời gian

1/ Dashboard
1781339574712.png

2/ Client List
1781339620178.png

3/ Client Startus
1781339685641.png

4/ Audit Viewer ( Log máy khách nào gọi hàm từ DLL nào phía máy chủ )
1781339768143.png

5/ Doctor ( Kiểm tra hệ thống )
1781339882552.png

Có lẽ nên tập trung nâng cấp hệ thống hiện tại lên kiến trúc hoàn chỉnh hơn.
Các hệ thống WebServer/TCP/IP hiện tại chưa tích hợp authentication và token-based security nên chưa phù hợp để đưa vào môi trường production.
Có thể tạm thời tách riêng và bổ sung lớp bảo mật sau khi kiến trúc ổn định.

Việc vận hành hệ thống qua Excel hoặc môi trường mạng không có security layer tương đương việc triển khai trong môi trường không kiểm soát, tiềm ẩn rủi ro cao về an toàn dữ liệu.
 
quản lý máy chủ tự động hoá theo Windows Services

1781432916106.png

Thời đại AI viết mọi cái rất dễ và đơn giản .... xa xưa sử dụng Excel làm máy chủ giải pháp tình thế thời cổ xem như tạm OK
ai đó vô tinh mở Excel nhiều file xong tắt đi xem như các máy khách tịt sạch

Copy dòng trên cho ChaGPT trả lời theo ngữ cảnh Chat ... Nguyên văn chatGPT viết như sau

Đúng là nhìn lại thì nhiều hệ thống "enterprise tự chế" ngày xưa khá hài hước
Thời chưa có cloud, REST API, message queue, database server giá rẻ..., nhiều nơi lấy ngay Excel làm máy chủ dữ liệu:
  • Một file Excel đặt trên share network.
  • VBA chạy như business logic.
  • Các máy khách mở file đó để đọc/ghi dữ liệu.
  • Có nơi còn dùng Excel làm "database", "report server", "workflow engine" cùng lúc.
Lúc demo thì:
"Nhanh, rẻ, chạy được rồi."
Nhưng khi vận hành thực tế:
  • Ai đó mở file Excel rồi bấm Save As → hệ thống lỗi.
  • Ai đó mở nhiều file rồi quên đóng → lock file.
  • Excel hiện hộp thoại hỏi lưu hay không → VBA treo.
  • Người dùng tắt Excel → toàn bộ client mất kết nối.
  • Windows Update reboot máy chứa file → cả công ty đứng hình.
  • Một macro lỗi runtime → dữ liệu nửa ghi nửa không.
Đó chính là khác biệt giữa:
Giải pháp tình thếHệ thống thực sự
Chạy đượcChạy ổn định
1 người dùngNhiều người dùng
Không lỗi khi demoKhông lỗi lúc 3 giờ sáng
Excel/VBADatabase + Service
State nằm trong ứng dụngState nằm trong server
Ngày nay AI giúp viết code cực nhanh nên những giải pháp kiểu:
  • Excel làm server
  • Access làm ERP
  • File TXT làm message queue
  • Shared folder làm database
dần không còn lý do tồn tại nữa.
Ngày xưa làm một service Windows, API server hay database wrapper là cả dự án. Bây giờ bảo AI:
"Viết cho tôi Windows Service bằng Go, expose HTTP API, lưu SQLite/PostgreSQL, có log rotation và auto restart"
thì vài phút là có khung chạy được.
Nói vui thì:
Thời xưa: Excel được dùng như một database vì viết server quá khó.
Thời nay: Viết server dễ đến mức dùng Excel làm server lại trở thành phương án khó bảo trì hơn cả việc viết server thật.
 
BridgeAdmin V4 đã hoàn thành.

Một công cụ quản trị và vận hành dành cho Bridge RPC Server, hỗ trợ:

• Quản lý Client và Token/Key
• Audit và theo dõi lịch sử gọi hàm từ xa
• Giới hạn truy cập theo IP, quota và rate limit
• Backup / Restore dữ liệu
• Quản lý Master Key và xác thực
• Kiểm tra sức khỏe hệ thống (Doctor Check)
• Điều khiển và giám sát Windows Service

Mục tiêu là giúp việc vận hành máy chủ RPC tập trung, trực quan và an toàn hơn.

1781767156349.png

Quản lý Client và cấp Token/Key

1781767242031.png

Tra cứu máy khách sử dụng khi cần thiết

1781767342665.png
 
Tôi đã xây dựng thêm một plugin server-side GoogleSvc.dll viết bằng Go, hoạt động như một execution module trong hệ thống RPC Bridge.

Module này tích hợp Google Sheets, Gmail và Google Drive, đồng thời tự động quản lý toàn bộ vòng đời authentication (OAuth, token refresh, session).

Máy khách không trực tiếp làm việc với Google API mà chỉ gửi request RPC từ xa. Toàn bộ logic, bảo mật và logging được xử lý tập trung trên máy chủ, giúp hệ thống đảm bảo an toàn, dễ mở rộng và tách biệt hoàn toàn client với external services.


-------------------------------
cấu hình máy chủ đảm bảo hệ thống chạy 24/7 khi các Client RPC hàm từ xa qua các DLL liên tục và máy chủ tự động giải phóng DLL theo cấu hình
thời gian cho trước

1782047199231.png

Trình xem thông tin Client nào gọi DLL nào và tên hàm gọi

1782046678211.png

quản lý cấp Token cho Client, giới hạn , chặn và xoá Client và mỗi Client một file token .json duy nhất

1782046955183.png

Thống kê Client gọi hàm

1782047340072.png

Thông tin máy khách và Key đã cấp

1782047399940.png
 
Lần chỉnh sửa cuối:
GoogleSvc.dll là plugin tích hợp các dịch vụ Google phổ biến gồm Google Sheets, Gmail và Google Drive trong một thư viện duy nhất.

Giải pháp được thiết kế cho cả hệ thống máy chủ và người dùng cá nhân, cho phép triển khai nhanh chóng mà vẫn đảm bảo quyền kiểm soát hoàn toàn thuộc về người sử dụng.

Người dùng tự tạo và quản lý credential theo chuẩn chính thức của Google. Chỉ với vài phút cấu hình trên Google Cloud Console và tải về tệp JSON credential, người dùng có thể bắt đầu sử dụng các dịch vụ Google mà không cần phụ thuộc vào bên thứ ba quản lý khóa truy cập.

GoogleSvc.dll tự động quản lý toàn bộ vòng đời xác thực, bao gồm OAuth, lưu trữ token, làm mới token và duy trì phiên làm việc. Người dùng chỉ cần thực hiện đăng nhập và cấp quyền trong lần sử dụng đầu tiên. Các lần sử dụng tiếp theo được xử lý tự động mà không cần đăng nhập lại.

Đặc điểm nổi bật:

• Tích hợp Google Sheets, Gmail và Google Drive trong một DLL duy nhất.
• Sử dụng cơ chế xác thực OAuth chính thức của Google.
• Người dùng tự sở hữu và quản lý credential của mình.
• Tự động xử lý access token và refresh token.
• Không yêu cầu lưu trữ hoặc chia sẻ khóa truy cập cho bên thứ ba.
• Phù hợp cho ứng dụng desktop, dịch vụ máy chủ, hệ thống RPC và các giải pháp tự động hóa doanh nghiệp.
• API thống nhất, dễ tích hợp vào các hệ thống hiện có.

GoogleSvc.dll giúp đơn giản hóa việc kết nối với hệ sinh thái Google trong khi vẫn duy trì tính bảo mật, tính minh bạch và quyền kiểm soát hoàn toàn thuộc về người sử dụng.


1782097073278.png

Giao diện đăng nhập lần đầu tuỳ chọn mail của chính bạn

1782097568496.png

Giao diện lần hai của Google như sau

1782097711653.png


Mọi đăng nhập tuân thủ bảo mật của Google
 
đang hoàn thiện từng cung đoạn một cho GoogleSvc.dll sử dụng cho máy chủ hay cá nhân sử dụng hoạt động như nhau

chỉ khác máy chủ tập chung xử lý logis mọi cái trên Server còn Máy khách chỉ gửi request RPC từ xa.

Toàn bộ logic, bảo mật và logging được xử lý tập trung trên máy chủ, giúp hệ thống đảm bảo an toàn, dễ mở rộng và tách biệt hoàn toàn client với external services.

 
hai ngày viết xong bản cho Free .......... cho ai đó sử dụng với mọi mục đích


xong viết bản cho máy chủ của chủ đề này sau và tách ra chủ đề khác ...

Khi máy chủ chạy thì các máy khách trong Internet viết trên bất cứ ngôn ngữ nào hay hệ điều hành nào cũng gửi dữ liệu về cho máy chủ đọc và gi dữ liệu lên Google Sheet tốt mọi logis xử lý Token và làm mới máy chủ tự động xử lý còn máy khách không cần thiết Token hay .json

Mã cho máy khách gọi hàm máy chủ cho các dịch vụ google đơn giản lắm không cần .json hay token

Tạm xem như sau

Mã:
Option Explicit

' ==========================================================
' modGoogleSvc.bas - Goi GoogleSvc.dll qua RPC Bridge V4
'
' Duong di: VBA -> modBridgeAuth (BridgeVba.dll) -> mang (TCP)
'           -> BridgeSvc/BridgeHost -> BridgeInvoker64.dll
'           -> GoogleSvc.dll (GBridgeExecute) -> Google API
'
' YEU CAU: module nay phu thuoc modBridgeAuth.bas (phai co trong
' cung project) - dung OpenBridge()/RpcCallBuf/PtrToStr tu module do.
'
' TEN DLL TREN MAY CHU: GoogleSvc.dll phai nam dung thu muc BridgeSvc/
' BridgeHost quet DLL (cung thu muc voi BridgeCore.dll, hoac thu muc
' da cau hinh) - chi can goi bang TEN NGAN, khong can duong dan day du,
' giong cach goi TestDll64.dll truoc day.
'
' VE auth.login (GLogin_RPC):
'   QUAN TRONG - chi goi duoc qua BridgeHost.exe (chay trong session
'   nguoi dung co desktop), KHONG goi duoc qua BridgeSvc.exe (Windows
'   Service, Session 0 Isolation - khong co desktop de mo browser).
'   Quy trinh dung 1 lan cho moi account:
'     1. Dung BridgeSvc neu dang chay (BridgeSvc /stop)
'     2. Mo BridgeHost.exe tren may chu (co desktop)
'     3. Goi GLogin_RPC tu VBA - browser tu mo TREN MAY CHU
'     4. Dang nhap xong, token da luu (ma hoa DPAPI) - dong BridgeHost
'     5. Khoi dong lai BridgeSvc (BridgeSvc /start) - doc duoc token
'        ngay vi DPAPI scope MACHINE
'   Sau buoc nay, moi request khac (sheets/gmail/drive) goi qua
'   BridgeSvc binh thuong, khong can dang nhap lai.
' ==========================================================

' ==========================================================
' PHAN 0 - CAU HINH
' ==========================================================
Private Const GOOGLESVC_DLL As String = "GoogleSvc.dll"

' Kich thuoc buffer mac dinh cho ket qua tra ve (so ky tu UTF-16).
' Sheets/Drive list co the can buffer lon hon mac dinh - dung
' GBridgeCallAdv neu can chi dinh rieng.
Private Const DEFAULT_BUF_CHARS As Long = 65536

' ==========================================================
' PHAN 1 - HAM GOI GOC (dung chung cho moi action)
' ==========================================================

' GBridgeCall: goi 1 action JSON qua GoogleSvc.dll::GBridgeExecute,
' tra ve JSON response dang String. Day la ham goc - moi wrapper
' Sheets/Gmail/Drive ben duoi deu xay tren ham nay.
'
'   reqJson  : JSON request day du, vd {"action":"ping"}
'   bufChars : kich thuoc buffer ky tu UTF-16 cho ket qua (mac dinh
'              DEFAULT_BUF_CHARS neu truyen 0)
'
' Luu y: GoogleSvc.dll dung out-buffer pattern - neu bufChars qua nho,
' KHONG tu cap lai duoc qua RPC (khac voi goi truc tiep in-process),
' vi moi lan goi RPC la 1 round-trip rieng. Neu nghi ket qua dai (vd
' doc nhieu dong Sheet, list nhieu file Drive), tang bufChars khi goi.
Public Function GBridgeCall(ByVal reqJson As String, _
    Optional ByVal bufChars As Long = 0) As String
    If bufChars <= 0 Then bufChars = DEFAULT_BUF_CHARS

    Dim h As LongLong
    h = OpenBridge()
    If h = 0 Then
        GBridgeCall = "{""ok"":false,""error"":""khong ket noi duoc Bridge (kiem tra BridgeSvc/BridgeHost dang chay)""}"
        Exit Function
    End If

    Dim args As String
    args = "wstr=" & reqJson & "|wbuf=" & CStr(bufChars) & "|i64=" & CStr(bufChars)

    Dim respPtr As LongPtr
    respPtr = RpcCallBuf(h, StrPtr(GOOGLESVC_DLL), StrPtr("GBridgeExecute"), StrPtr(args), 0)

    If respPtr = 0 Then
        GBridgeCall = "{""ok"":false,""error"":""RpcCallBuf tra ve NULL - kiem tra ket noi hoac log BridgeSvc""}"
        Exit Function
    End If

    GBridgeCall = PtrToStr(respPtr)
    If Len(GBridgeCall) = 0 Then
        GBridgeCall = "{""ok"":false,""error"":""khong nhan duoc response (rong) - tang bufChars neu ket qua co the dai""}"
    End If
End Function

' ==========================================================
' PHAN 2 - AUTH
' ==========================================================

' GLogin_RPC: dang nhap Google qua RPC. CHI goi duoc qua BridgeHost.exe
' (xem ghi chu o dau file). Block toi 300s ben may chu trong luc cho
' nguoi dung hoan tat OAuth tren browser may chu.
Public Function GLogin_RPC(Optional ByVal account As String = "default") As String
    Dim req As String
    req = "{""action"":""auth.login"",""account"":""" & account & """}"
    ' Dang nhap co the mat thoi gian - dung buffer nho la du (response
    ' chi la 1 JSON status ngan), khong can tang bufChars.
    GLogin_RPC = GBridgeCall(req)
End Function

Public Function GPing_RPC() As String
    GPing_RPC = GBridgeCall("{""action"":""ping""}")
End Function

' ==========================================================
' PHAN 3 - SHEETS
' ==========================================================

' GSheetRead_RPC: doc 1 vung trong Google Sheet.
'   spreadsheetId : lay tu URL Sheet (giua /d/ va /edit)
'   rangeA1       : vd "Sheet1!A1:C10"
Public Function GSheetRead_RPC(ByVal spreadsheetId As String, _
    ByVal rangeA1 As String, _
    Optional ByVal account As String = "default", _
    Optional ByVal bufChars As Long = 0) As String
    Dim req As String
    req = "{""action"":""sheets.read"",""account"":""" & account & """," & _
          """spreadsheetId"":""" & spreadsheetId & """," & _
          """range"":""" & rangeA1 & """}"
    GSheetRead_RPC = GBridgeCall(req, bufChars)
End Function

' GSheetWrite_RPC: ghi du lieu vao 1 vung, GHI DE (khong chen dong).
'   valuesJSON: JSON mang 2 chieu, vd [["a","b"],[1,2]]
Public Function GSheetWrite_RPC(ByVal spreadsheetId As String, _
    ByVal rangeA1 As String, ByVal valuesJSON As String, _
    Optional ByVal account As String = "default") As String
    Dim req As String
    req = "{""action"":""sheets.write"",""account"":""" & account & """," & _
          """spreadsheetId"":""" & spreadsheetId & """," & _
          """range"":""" & rangeA1 & """," & _
          """values"":" & valuesJSON & "}"
    GSheetWrite_RPC = GBridgeCall(req)
End Function

' GSheetAppend_RPC: them dong moi vao CUOI 1 vung (khong ghi de du
' lieu cu) - hop cho log/audit trail.
Public Function GSheetAppend_RPC(ByVal spreadsheetId As String, _
    ByVal rangeA1 As String, ByVal valuesJSON As String, _
    Optional ByVal account As String = "default") As String
    Dim req As String
    req = "{""action"":""sheets.append"",""account"":""" & account & """," & _
          """spreadsheetId"":""" & spreadsheetId & """," & _
          """range"":""" & rangeA1 & """," & _
          """values"":" & valuesJSON & "}"
    GSheetAppend_RPC = GBridgeCall(req)
End Function

' ==========================================================
' PHAN 4 - GMAIL
' ==========================================================

Public Function GMailSend_RPC(ByVal toAddr As String, ByVal subject As String, _
    ByVal body As String, Optional ByVal account As String = "default") As String
    Dim req As String
    req = "{""action"":""gmail.send"",""account"":""" & account & """," & _
          """to"":""" & toAddr & """," & _
          """subject"":""" & subject & """," & _
          """body"":""" & body & """}"
    GMailSend_RPC = GBridgeCall(req)
End Function

' GMailList_RPC: liet ke email theo cu phap tim kiem Gmail
' (vd "from:abc@gmail.com is:unread").
Public Function GMailList_RPC(Optional ByVal query As String = "", _
    Optional ByVal maxResults As Long = 20, _
    Optional ByVal account As String = "default") As String
    Dim req As String
    req = "{""action"":""gmail.list"",""account"":""" & account & """," & _
          """query"":""" & query & """," & _
          """maxResults"":" & CStr(maxResults) & "}"
    GMailList_RPC = GBridgeCall(req)
End Function

' ==========================================================
' PHAN 5 - DRIVE
' ==========================================================

' GDriveUpload_RPC: upload 1 file tu DIA CUA MAY CHU (khong phai may
' khach) len Drive. QUAN TRONG: localPath la duong dan tren may chay
' BridgeSvc/BridgeHost, vi GoogleSvc.dll thuc thi tren may chu, KHONG
' phai may dang chay VBA. Neu can upload file tu may khach, phai copy
' file do len may chu truoc (vd qua thu muc mang chia se) hoac dung
' co che khac de chuyen file qua mang.
Public Function GDriveUpload_RPC(ByVal localPath As String, _
    Optional ByVal folderID As String = "", _
    Optional ByVal mimeType As String = "", _
    Optional ByVal account As String = "default") As String
    Dim req As String
    req = "{""action"":""drive.upload"",""account"":""" & account & """," & _
          """localPath"":""" & Replace(localPath, "\", "\\") & """," & _
          """folderId"":""" & folderID & """," & _
          """mimeType"":""" & mimeType & """}"
    GDriveUpload_RPC = GBridgeCall(req)
End Function

' GDriveDownload_RPC: download 1 file tu Drive ve DIA MAY CHU (cung
' luu y nhu GDriveUpload_RPC - localPath la duong dan tren may chu).
Public Function GDriveDownload_RPC(ByVal fileID As String, ByVal localPath As String, _
    Optional ByVal account As String = "default") As String
    Dim req As String
    req = "{""action"":""drive.download"",""account"":""" & account & """," & _
          """fileId"":""" & fileID & """," & _
          """localPath"":""" & Replace(localPath, "\", "\\") & """}"
    GDriveDownload_RPC = GBridgeCall(req)
End Function

Public Function GDriveList_RPC(Optional ByVal folderID As String = "", _
    Optional ByVal maxResults As Long = 50, _
    Optional ByVal account As String = "default") As String
    Dim req As String
    req = "{""action"":""drive.list"",""account"":""" & account & """," & _
          """folderId"":""" & folderID & """," & _
          """maxResults"":" & CStr(maxResults) & "}"
    GDriveList_RPC = GBridgeCall(req)
End Function

' ==========================================================
' PHAN 6 - TEST (chay tu Immediate Window, Ctrl+G)
' SUA spreadsheetId/email/file truoc khi chay cho dung du lieu thuc te.
' ==========================================================

Public Sub Test_GPing()
    Debug.Print "=== Test_GPing ==="
    Debug.Print GPing_RPC()
End Sub

Public Sub Test_GLogin()
    Debug.Print "=== Test_GLogin (chi qua BridgeHost.exe) ==="
    Debug.Print "Dang dang nhap, cho browser tren MAY CHU..."
    Debug.Print GLogin_RPC()
End Sub

Public Sub Test_GSheetRead()
    Debug.Print "=== Test_GSheetRead ==="
    Debug.Print GSheetRead_RPC("1punDQ-pRaMsoULsUaNthri5pj4ZrhNLFkOD3qkoo", "Sheet1!A1:C10")
End Sub

Public Sub Test_GSheetWrite()
    Debug.Print "=== Test_GSheetWrite ==="
    Debug.Print GSheetWrite_RPC("1punDQ-pRaMsopULsUaNuHrpj4ZrhNLFkOD3qkoo", _
        "Sheet1!A7:B8", "[[""Qua RPC""],[1]]")
End Sub

Public Sub Test_GMailSend()
    Debug.Print "=== Test_GMailSend ==="
    Debug.Print GMailSend_RPC("kieumanh366377@gmail.com", "Test qua RPC", "Gui tu modGoogleSvc.bas")
End Sub

Public Sub Test_GDriveList()
    Debug.Print "=== Test_GDriveList ==="
    Debug.Print GDriveList_RPC()
End Sub

Sub Test_Tenant_Login()
    Dim req As String
    req = "{""action"":""auth.login"",""tenant"":""test1"",""account"":""default""}"
    Debug.Print GBridgeCall(req)
End Sub

Cơ bản đã xây dựng hệ thống máy chủ RPC hàm từ xa OK rồi thì có DLL nào cứ giáp vào là chạy vèo vèo

ai tò mò tìm hiểu ABI là làm được ... đã nói cái bài trước rồi rất đơn giản thời đại AI ............... khi cộng tác với AI viết mã
 
Lần chỉnh sửa cuối:
1/ đã úp dự án mã đơn giản lên github ai quan tâm có thể test thử

2/ trước khi thử hãy đọc kỹ link sau làm theo chỉ dẫn


3/ Tách chủ đề sử dụng cho máy chủ ra thớt khác hổ trợ cho ai quan tâm

---

Mô hình sử dụng GoogleSvc Bridge​

1. Tổng quan​

Dự án cung cấp một kiến trúc bridge trung gian giữa máy khách và các dịch vụ Google (Sheets, Gmail, Drive...).

Máy khách không truy cập trực tiếp Google API mà thông qua máy chủ trung gian để đảm bảo kiểm soát, bảo mật và quản lý tập trung.


2. Kiến trúc hệ thống​

Máy chủ (Bridge Server)​

  • Quản lý toàn bộ OAuth Google
  • Lưu trữ và làm mới token Google tự động
  • Thực thi các thao tác:
    • Google Sheets (đọc/ghi/xoá)
    • Gmail (gửi/nhận)
    • Google Drive (upload/download)
  • Quản lý phiên đăng nhập của máy khách
  • Kiểm soát quyền truy cập theo từng client
  • Cho phép revoke / giới hạn / vô hiệu hoá token client

Máy khách (Client)​

  • Không cần service account hoặc OAuth Google
  • Không lưu token Google
  • Chỉ giao tiếp với máy chủ thông qua token đăng nhập nội bộ
  • Có thể chạy trên nhiều hệ điều hành (Windows / Linux / 32-bit / 64-bit)
  • Gửi request nghiệp vụ (không xử lý Google API trực tiếp)

3. Cơ chế xác thực​

  • Mỗi máy khách được cấp một Client Token
  • Token này dùng để xác thực với máy chủ trung gian
  • Token không liên quan trực tiếp đến Google OAuth
  • Máy chủ có toàn quyền:
    • cấp token
    • thu hồi token
    • giới hạn phiên làm việc

4. Mẫu cấu hình Client Token​

Mã:
{
  "type"      : "bridge_client",
  "version"   : 2,
  "client_id" : "cli_62077e54",
  "key_id"    : "kid_fd20",
  "api_key"   : "83566a2f2d62fc5b90543c9f73eaccf1667f1b6794ee8d2101350fcda83b3878",
  "server"    : "192.168.1.192",
  "port"      : 9000
}

5. Luồng hoạt động​

  1. Máy khách đăng nhập lần đầu vào máy chủ
  2. Máy chủ xác thực và cấp client token
  3. Máy khách sử dụng token để gửi request
  4. Máy chủ xử lý toàn bộ logic Google API
  5. Kết quả trả về cho máy khách

6. Đặc điểm chính​

  • Không lộ Google credentials cho client
  • Tập trung toàn bộ OAuth tại server
  • Dễ quản lý và kiểm soát người dùng
  • Hỗ trợ đa nền tảng
  • Có thể mở rộng thành hệ thống API Gateway nội bộ

7. Tách biệt hệ thống​

  • Máy khách chỉ xử lý giao diện và request logic
  • Máy chủ xử lý toàn bộ xác thực + Google integration
  • Hai lớp hoạt động độc lập, giao tiếp qua bridge protocol


xem hình máy chủ quản lý cấp token cho máy khách (cli_62077e54) đăng nhập máy chủ

1782188256527.png




quản lý chi tiết cấp và ngăn chặn khi cần thiết
 
ai quan tâm Google Sheet, Gmail và Drive Tôi tách sang chủ đề sau ... vui lòng qua link sau trao đổi và bàn luận chi tiết

 

Bài viết mới nhất

Back
Top Bottom