Tôi có nên sử dụng tên người dùng hoặc ID của người dùng để tham chiếu đến người dùng được xác thực trong ASP.NET

Question

Vì vậy, trong trang web học tập đơn giản của tôi, tôi sử dụng hệ thống xác thực ASP.NET được tích hợp sẵn.

Tôi thêm bây giờ là một bảng dùng để lưu những thứ như zip của mình, DOB, vv Câu hỏi của tôi là:

1. Trong bảng mới, nên chìa khóa là tên người dùng (chuỗi) hoặc người dùng ID đó là GUID tìm số họ sử dụng trong asp_ tables.
2. Nếu thực hành tốt nhất là sử dụng hướng dẫn xấu xí đó, có ai biết cách nhận nó không? dường như không thể truy cập dễ dàng như tên (System.Web.HttpContext.Current.User.Identity.Name)
3. Nếu bạn đề nghị tôi không sử dụng (không phải trường hướng dẫn và trường userName do ASP.NET xác thực) thì làm cách nào để thực hiện với xác thực ASP.NET? Một tùy chọn tôi thích là sử dụng địa chỉ email của người dùng làm đăng nhập, nhưng làm thế nào để tôi làm cho hệ thống xác thực ASP.NET sử dụng địa chỉ email thay vì tên người dùng? (Hoặc không có gì để làm ở đó, nó chỉ là tôi quyết định tôi "biết" userName thực sự là một địa chỉ email

Xin lưu ý:

• Tôi không yêu cầu về cách có được một GUID trong NET, tôi chỉ đề cập đến các cột userID trong asp_ tables như guid.
• tên người dùng độc đáo ở chỗ xác thực ASP.NET.

Answer 1

tôi sẽ đề nghị sử dụng tên người dùng làm khóa chính trong bảng nếu tên người dùng sẽ là độc đáo, có một vài lý do chính đáng để làm điều này:

1. Các khóa chính sẽ một chỉ số nhóm và do đó tìm kiếm chi tiết người dùng thông qua tên người dùng của họ sẽ rất nhanh.
2. Nó sẽ ngăn chặn tên người dùng trùng lặp xuất hiện
3. Bạn không cần phải lo lắng về việc sử dụng hai peices thông tin khác nhau (username hoặc guid)
4. Nó sẽ làm cho viết code dễ dàng hơn nhiều vì không phải tra cứu hai bit của thông tin.

Answer 2

bạn nên sử dụng một số ID duy nhất, hoặc GUID bạn đề cập đến hoặc một số tướng tự động khác ated key. Tuy nhiên, con số này sẽ không bao giờ được hiển thị cho người dùng.

Lợi ích to lớn của việc này là tất cả mã của bạn đều có thể hoạt động trên ID người dùng nhưng tên của người dùng không thực sự gắn với nó. Sau đó, người dùng có thể thay đổi tên của họ (mà tôi đã thấy hữu ích trên các trang web). Điều này đặc biệt hữu ích nếu bạn sử dụng địa chỉ email làm thông tin đăng nhập của người dùng ... rất thuận tiện cho người dùng (sau đó họ không phải nhớ 20 ID trong trường hợp ID người dùng chung của họ là ID phổ biến).

Answer 3

Tôi đồng ý với Mike Stone. Tôi cũng sẽ đề nghị chỉ sử dụng một GUID trong trường hợp bạn sẽ theo dõi một lượng lớn dữ liệu. Nếu không, cột số nguyên tự động tăng dần (Id) sẽ đủ.

Nếu bạn cần GUID, NET là đủ đáng yêu mà bạn có thể có được một bằng cách đơn giản ...

Dim guidProduct As Guid = Guid.NewGuid() 

hoặc

Guid guidProduct = Guid.NewGuid(); 

Answer 4

Bạn nên sử dụng UserID. Đó là thuộc tính ProviderUserKey của MembershipUser.

Guid UserID = new Guid(Membership.GetUser(User.Identity.Name).ProviderUserKey.ToString()); 

Answer 5

Tôi sẽ sử dụng userid. Nếu bạn muốn sử dụng tên người dùng, bạn sẽ làm cho tính năng "thay đổi tên người dùng" rất tốn kém.

Answer 6

Nếu bạn định sử dụng LinqToSql để phát triển, tôi khuyên bạn nên sử dụng Int làm khóa chính. Tôi đã có nhiều vấn đề khi tôi có các mối quan hệ được xây dựng từ các trường phi Int, ngay cả khi trường nvarchar (x) có các ràng buộc để làm cho nó trở thành một trường duy nhất.

Tôi không chắc liệu đây có phải là lỗi đã biết trong LinqToSql hay không, nhưng tôi đã gặp vấn đề với dự án hiện tại và tôi phải hoán đổi PK và FK trên một vài bảng.

Answer 7

Tôi đồng ý với Mike Stone. Gần đây, công ty của tôi đã triển khai bảng người dùng mới cho các khách hàng bên ngoài (ngược lại với người dùng nội bộ xác thực thông qua LDAP). Đối với người dùng bên ngoài, chúng tôi đã chọn lưu trữ GUID làm khóa chính và lưu trữ tên người dùng dưới dạng varchar với các ràng buộc duy nhất trên trường tên người dùng.

Ngoài ra, nếu bạn định lưu trữ trường mật khẩu, tôi khuyên bạn nên lưu trữ mật khẩu dưới dạng mã nhị phân đã được băm, muối trong cơ sở dữ liệu. Bằng cách này, nếu ai đó tấn công cơ sở dữ liệu của bạn, họ sẽ không có quyền truy cập vào mật khẩu của khách hàng của bạn.

Answer 8

Tôi sẽ sử dụng số tăng tự động thường là int.

Bạn muốn giữ kích thước của khóa càng nhỏ càng tốt. Điều này giúp chỉ số của bạn nhỏ và mang lại lợi ích cho bất kỳ khóa ngoại nào. Additonally bạn không chặt chẽ khớp nối thiết kế dữ liệu với dữ liệu người dùng bên ngoài (điều này cũng đúng cho GUID aspnet).

Thông thường GUID không tạo ra khóa chính tốt vì chúng lớn và chèn có thể xảy ra ở bất kỳ trang dữ liệu nào trong bảng thay vì ở trang dữ liệu cuối cùng. Ngoại lệ chính cho điều này là nếu bạn đang chạy cơ sở dữ liệu nhân rộng mutilple. GUID là rất hữu ích cho các phím trong kịch bản này, nhưng tôi đoán bạn chỉ có một cơ sở dữ liệu vì vậy đây không phải là một vấn đề.

Answer 9

Tôi đồng ý với Palmsey, Mặc dù có vẻ là một lỗi nhỏ trong mã của mình:

Guid UserID = new Guid(Membership.GetUser(User.Identity.Name)).ProviderUserKey.ToString()); 

nên

Guid UserID = new Guid(Membership.GetUser(User.Identity.Name).ProviderUserKey.ToString()); 

Answer 10

Tôi có thể nói sử dụng UserID để Tên người dùng vẫn có thể được thay đổi mà không ảnh hưởng đến khóa chính. Tôi cũng sẽ đặt cột tên người dùng là duy nhất để dừng tên người dùng trùng lặp.

Nếu bạn chủ yếu sẽ tìm kiếm trên tên người dùng thay vì UserID thì hãy đặt tên người dùng thành chỉ mục nhóm và đặt khóa chính sẽ không được nhóm. Điều này sẽ cung cấp cho bạn truy cập nhanh nhất khi tìm kiếm tên người dùng, tuy nhiên, nếu bạn chủ yếu tìm kiếm UserIds thì hãy để điều này làm chỉ mục nhóm.

Chỉnh sửa: Điều này cũng sẽ phù hợp hơn với bảng thành viên ASP.Net hiện tại vì họ cũng sử dụng UserID làm khóa chính.

Answer 11

Tôi sẽ sử dụng guid trong mã của mình và như đã đề cập một địa chỉ email làm tên người dùng.Đó là, sau khi tất cả, đã độc đáo và đáng nhớ cho người dùng. Có lẽ thậm chí mương guid (v. Debateable).

Ai đó đã đề cập bằng cách sử dụng chỉ mục nhóm trên GUID nếu điều này đang được sử dụng trong mã của bạn. Tôi sẽ tránh điều này, đặc biệt nếu INSERT cao; chỉ mục sẽ được xây dựng lại mỗi khi bạn INSERT một bản ghi. Các chỉ mục được nhóm hoạt động tốt trên các ID tăng tự động mặc dù các bản ghi mới chỉ được nối vào.

Answer 12

Đây là cũ nhưng tôi chỉ muốn những người tìm thấy điều này cần lưu ý một vài điều:

1. Các aspnet cơ sở dữ liệu thành viên được tối ưu hóa khi nói đến việc tiếp cận hồ sơ người dùng. Chỉ số nhóm tìm kiếm (tối ưu) trong máy chủ sql được sử dụng khi một bản ghi được tìm kiếm bằng cách sử dụng tên miền hạ xuống và ứng dụng. Điều này rất có ý nghĩa vì chúng tôi chỉ có tên người dùng được cung cấp để tiếp tục khi người dùng gửi thông tin đăng nhập của họ lần đầu tiên.

2. Hướng dẫn sử dụng guid sẽ cung cấp kích thước chỉ mục lớn hơn int nhưng điều này không thực sự quan trọng vì chúng tôi thường chỉ lấy 1 bản ghi (người dùng) tại một thời điểm và về phân đoạn, số lần đọc thường lớn hơn số lượng ghi và chỉnh sửa cho bảng người dùng - mọi người chỉ không cập nhật thông tin đó thường xuyên.

3. Tập lệnh regsql tạo bảng thành viên aspnet có thể được chỉnh sửa để thay vì sử dụng NEWID làm mặc định cho userid, nó có thể sử dụng NEWSEQUENTIALID() mang lại hiệu suất tốt hơn (tôi đã lược tả điều này).

4. Tiểu sử. Ai đó tạo ra một "trang web học tập mới" không nên cố gắng tái tạo lại bánh xe. Một trong những trang web tôi đã làm việc để sử dụng một phiên bản hộp của bảng thành viên aspnet (không bao gồm hệ thống hồ sơ khủng khiếp) và bảng người dùng chứa gần 2 triệu hồ sơ người dùng. Ngay cả với số lượng bản ghi cao như vậy, các lựa chọn vẫn nhanh bởi vì, như tôi đã nói để bắt đầu, các chỉ mục cơ sở dữ liệu tập trung vào lowerusername + applicationid thành chỉ mục nhóm nhỏ tìm kiếm các bản ghi này và nói chung, nếu sql đang thực hiện một chỉ mục nhóm để tìm 1 bản ghi, bạn không có bất kỳ vấn đề nào, ngay cả với số lượng lớn các bản ghi được cung cấp mà bạn không thêm cột vào các bảng và bắt đầu kéo lại quá nhiều dữ liệu.

5. Lo lắng về một hướng dẫn trong hệ thống này, với tôi, dựa trên hiệu suất thực tế và trải nghiệm của hệ thống, là tối ưu hóa sớm. Nếu bạn có một int cho userid của bạn nhưng hệ thống thực hiện các truy vấn phụ tối ưu vì thiết kế chỉ mục tùy chỉnh của bạn, vv hệ thống sẽ không mở rộng tốt. Những kẻ Microsoft đã làm một công việc chung tốt với db thành viên aspnet và có nhiều điều hiệu quả hơn để tập trung vào hơn thay đổi userId thành int.