tài khoản đăng ký tại Couchapp/CouchDB qua jquery.couch.js hoặc Nếu không

Question

nền

Ngay bây giờ, tôi đang cố gắng để xây dựng một ứng dụng với CouchDB/couchapp rằng sẽ lưu trữ thông tin liên tục và quan trọng từ người sử dụng, và bị kẹt trên các bước cần thiết cho đăng ký người dùng với couchapp.

Về cơ bản, những gì tôi muốn làm là có một mẫu đăng ký đơn giản mà người dùng có thể sử dụng để đăng ký tài khoản để sử dụng ứng dụng của tôi. Điều này sẽ đòi hỏi phải tạo ra một người dùng mới trong cơ sở dữ liệu couchdb _users, và tạo ra một cơ sở dữ liệu mới, với người dùng mới được gán vai trò của quản trị cơ sở dữ liệu.

Tất cả yêu cầu thông tin đăng nhập quản trị viên máy chủ.

Lý tưởng nhất, tôi rất muốn có thể thực hiện cuộc gọi bằng một trong các chức năng jquery.couch.js, nhưng dường như không có cách nào an toàn để thực hiện điều đó. (Hoặc là có ??)

Câu hỏi

cách chưa an toàn hiệu quả nhất để giảm tải công việc này cho một phần mềm trung lớp hoặc là gì?

Bằng hiệu quả, ý tôi là cần số lượng bước tối thiểu cho người dùng, không nhất thiết là số tiền ít phiền toái nhất đối với tôi.

Hiện tại, tôi đã thiết lập máy chủ node.js riêng biệt nhận được yêu cầu đăng ký. Thông tin quản trị máy chủ couchDB của tôi được lưu trữ dưới dạng biến riêng tư trên tệp server.js của nút. Sau đó tôi POST bất kỳ yêu cầu tạo db nào trở lại couchDB bằng cách sử dụng couch-client.

Tôi có vượt qua quá nhiều vòng lặp (không an toàn tiềm năng) ở đây không? Có cách nào tốt hơn để đảm bảo quá trình đăng ký an toàn không?

Cảm ơn.

Answer 1

Tôi đã sử dụng node.js theo cách bạn mô tả. Nó không khác gì việc sử dụng phần mềm trung gian như PHP để giao tiếp với MySQL. Mạnh mẽ như API dành cho CouchDB, bạn vẫn nên sử dụng một cái gì đó khác ở giữa để có thể phục vụ nội dung mà không cần AJAX. (đặc biệt nếu bạn cần bất cứ điều gì phức tạp hơn một thực thể hoặc danh sách các thực thể)

Nếu bạn quyết định tiếp tục với CouchApp trực tiếp, bạn cần phải sử dụng máy chủ proxy để định tuyến các yêu cầu HTTPS tới chính máy chủ CouchDB . (Nginx và Apache là các ví dụ phổ biến của trường hợp sử dụng này) Nếu bạn không thể sử dụng, có một article trong wiki về việc thêm một lớp mã hóa cho phía máy khách. Tôi đã tìm thấy trên số wiki hỗ trợ SSL gốc sẽ được thêm với v1.1 (và được hỗ trợ trong thân của nguồn)

(Btw, tất cả các bài viết này tôi đã xem qua "How-to Guides" trên CouchDB Wiki)

Answer 2

Người dùng quản trị được yêu cầu tạo cơ sở dữ liệu và chỉ định quản trị viên cơ sở dữ liệu.

Câu trả lời của Dominic rất tuyệt. Tuy nhiên, cách khác là giữ cấu trúc ghế sofa trực tiếp và chạy mã quản trị của bạn bên ngoài, bên ngoài chuỗi người dùng-đi-văng.

Ví dụ: trong NodeJS, hãy kết nối với CouchDB với tư cách quản trị viên. Truy vấn /_users/_changes?feed=continuous&include_docs=true.Bạn sẽ nhận được sự kiện dữ liệu trong thời gian thực khi người dùng được tạo. Khi bạn nhìn thấy một người dùng mới, hãy tạo cơ sở dữ liệu và gán chúng làm quản trị viên.

Mã máy khách có thể thăm dò ý kiến ​​cho cơ sở dữ liệu mới của họ. Hoặc, khách hàng cũng có thể truy vấn /_users qua nguồn cấp dữ liệu COMET _changes. Dù bằng cách nào, khi trình duyệt biết rằng tài khoản được thiết lập, bạn có thể hiển thị nó cho người dùng trong giao diện người dùng.

Proxy (kiến trúc 3 lớp) thật tuyệt vời. Không có gì họ không thể làm. Tuy nhiên, tôi thường thích kiến ​​trúc của "CouchDB với tác nhân bên ngoài" vì hai lý do:

1. Thật đơn giản. Có một máy chủ web. Người dùng kết nối với CouchDB. Bạn kết nối với CouchDB. Mọi thứ đều có trong cơ sở dữ liệu. Có ít vấn đề về cấu hình và bảo trì hơn.
2. Thật linh hoạt. Bạn có thể viết ứng dụng khách bên ngoài bằng bất kỳ ngôn ngữ nào, chạy từ bất kỳ máy chủ nào. Bạn viết một ứng dụng lớn để làm mọi thứ hoặc nhiều ứng dụng nhỏ để tập trung vào một nhiệm vụ (ví dụ: tạo cơ sở dữ liệu mới, gửi email người dùng cho mật khẩu bị mất, thông báo cho bạn nếu cơ sở dữ liệu quá lớn, v.v.).