Đăng nhập bằng Facebook

Yêu cầu và thu hồi quyền

Mỗi loại quy trình đăng nhập đều có phương thức yêu cầu quyền riêng, tùy thuộc vào nền tảng và cách bạn chọn tích hợp phương thức Đăng nhập bằng Facebook:

Web

Ứng dụng di động

Lưu ý rằng bạn cũng có thể dùng nhiều API được liệt kê ở trên để yêu cầu thêm quyền sau này trong toàn bộ thời gian hoạt động của ứng dụng, chứ không phải chỉ khi đăng nhập lúc đầu.

Tối ưu hóa yêu cầu cấp quyền

Theo quy tắc chung, ứng dụng yêu cầu càng nhiều quyền thì mọi người càng ít khả năng sẽ sử dụng Facebook để đăng nhập vào ứng dụng. Trên thực tế, nghiên cứu của chúng tôi chỉ ra rằng các ứng dụng yêu cầu nhiều hơn 4 quyền có số lần đăng nhập hoàn tất giảm đáng kể.

Nguyên tắc

Dưới đây là vài nguyên tắc cần sử dụng khi yêu cầu quyền, cả trong và sau khi đăng nhập:

  • Chỉ yêu cầu các quyền thiết yếu với ứng dụng.

  • Yêu cầu quyền trong ngữ cảnh cần quyền. Ví dụ: nếu ứng dụng muốn hiển thị các địa điểm yêu thích gần vị trí của một người, việc yêu cầu user_location ngay trước khi hiển thị thông tin đó sẽ giúp người này hiểu rõ hơn lý do yêu cầu quyền này.

  • Tách riêng yêu cầu quyền đọc và quyền đăng. Để biết thêm thông tin, hãy xem bên dưới.

  • Tuyệt đối không yêu cầu các quyền mà bạn cho rằng mình có thể cần trong tương lai. Mọi người sẽ nghi ngờ và có thể từ chối ứng dụng của bạn.

  • Cho mọi người biết trước lý do bạn yêu cầu một quyền. Việc giải thích lý do bạn cần quyền truy cập vào nội dung nào đó sẽ làm tăng khả năng họ sẵn sàng chia sẻ nội dung đó.

Quyền đăng

Ứng dụng nên tách riêng yêu cầu quyền đọc và quyền đăng. Hãy lên kế hoạch cho ứng dụng về việc yêu cầu các quyền đọc tối thiểu lúc đăng nhập ban đầu, rồi đến các quyền đăng khi một người thực sự cần. Ví dụ: khi họ muốn tạo một tin đăng bằng Open Graph trong ứng dụng. Điều này mang lại trải nghiệm người dùng tốt nhất và tối ưu hóa lượt chuyển đổi.

Bạn có thể nhận được Cảnh báo cho nhà phát triển nếu ứng dụng của bạn yêu cầu quyền đọc và quyền đăng liên tiếp. Để ngừng nhận những cảnh báo này, hãy tách biệt các yêu cầu của bạn hoặc tuân theo nguyên tắc bên dưới cho các trường hợp ngoại lệ.

Trong trường hợp hiếm gặp, ứng dụng của bạn cần có trước quyền đăng (ví dụ: một ứng dụng chỉ đăng tâm trạng của một người lên Facebook), hãy chỉ yêu cầu quyền đọc tối thiểu lúc đăng nhập ban đầu. Sau khi người đó đăng nhập, hãy hiển thị một màn hình giải thích lý do ứng dụng của bạn cần quyền đăng và cho phép người đó chọn yêu cầu quyền đăng bằng cách nhấp vào một nút. Việc này sẽ cung cấp thêm ngữ cảnh cho người dùng và cải thiện lượt chuyển đổi của bạn.

Một trường hợp mà bạn có thể phải yêu cầu quyền đọc và quyền ghi liên tiếp là lần đầu tiên bạn liên kết tài khoản dựa trên email với tài khoản Facebook của một người. Việc này thường được thực hiện khi ai đó muốn chia sẻ một tin lên Dòng thời gian của họ trên Facebook. Khi ứng dụng tạo hộp thoại đăng nhập, người đó sẽ nhìn thấy 2 hộp thoại liên tiếp – một hộp thoại để kết nối tài khoản của họ với ứng dụng của bạn và hộp thoại còn lại yêu cầu cấp quyền đăng. Đối với trường hợp này, hãy đảm bảo rằng quyền đọc duy nhất mà bạn yêu cầu là public_profile. Như vậy, người dùng sẽ có trải nghiệm tốt nhất vì họ muốn đăng từ ứng dụng của bạn và thường không quan tâm đến việc cấp quyền đọc bổ sung. Việc này cũng sẽ cải thiện lượt chuyển đổi của bạn.

Kiểm tra quyền hiện tại

Facebook cho phép mọi người toàn quyền kiểm soát các quyền họ cấp cho một ứng dụng. Quyền kiểm soát đó vượt ngoài thời điểm mà họ nhìn thấy hộp thoại đăng nhập. Họ có thể chọn không cấp một số quyền trong quá trình đăng nhập. Họ cũng có thể thu hồi quyền trong cài đặt quyền riêng tư của mình trên Facebook bất cứ lúc nào. Các ứng dụng nên kiểm tra tính hợp lệ của quyền trước khi cố gắng thực hiện lệnh gọi API cần có quyền đó. Ví dụ: trước khi gửi tin nhắn, hãy kiểm tra để đảm bảo rằng email vẫn được cấp.

Đối với ứng dụng web, chúng tôi cung cấp một điểm cuối API Đồ thị để truy xuất danh sách các quyền được cấp:

GET /{user-id}/permissions

Lệnh gọi này phải được thực hiện với mã truy cập người dùng hoặc mã truy cập ứng dụng. Lệnh gọi này sẽ trả về chuỗi JSON chứa tên quyền đã được cấp cho ứng dụng và trạng thái của quyền:

{
  "data": [
    {
      "permission": "public_profile",
      "status": "granted"
    },
    {
      "permission": "email",
      "status": "granted"
    },
    {
      "permission": "user_friends",
      "status": "declined"
    }
  ]
}

Chúng tôi cũng cung cấp các phương thức trong SDK dành cho iOS và Android để biểu thị các quyền mà ứng dụng của bạn đã được cấp theo cách thân thiện với nền tảng.

Xử lý quyền bị thiếu

Khi một ứng dụng yêu cầu quyền, mọi người có thể từ chối hoàn toàn những quyền đó, không cấp đầy đủ những quyền đó hoặc thay đổi các quyền đó sau này. Để mang lại trải nghiệm tuyệt vời, ứng dụng cần được thiết kế sao cho có thể xử lý những tình huống này.

Đầu tiên, ứng dụng cần phải xử lý được mọi quyền đã yêu cầu nhưng không được cấp:

  • Kiểm tra các quyền được cấp trước khi cố gắng sử dụng những API cần có các quyền đó.
  • Phát hiện các lỗi quyền được trả về khi tạo một yêu cầu API mà không có đúng quyền. Đây là một ví dụ về lỗi:
{
  "error": {
    "message": "(#200) The user hasn't authorized the application
     to perform this action",
    "type": "OAuthException",
    "code": 200
  }
}

Sau khi phát hiện ra ai đó đã từ chối một số hoặc tất cả các quyền, ứng dụng có thể chuyển họ về thông qua quy trình đăng nhập một lần và yêu cầu mọi quyền bắt buộc. Tuy nhiên, việc này sẽ dẫn đến trải nghiệm kém và nên tránh nếu có thể. Nếu ai đó chủ động chọn không cấp một quyền cụ thể cho ứng dụng thì không chắc họ sẽ thay đổi ý kiến ngay cả khi tiếp tục được nhắc. Thay vào đó, hãy thực hiện như sau:

  • Nếu một người từ chối hộp thoại đăng nhập dù được giải thích trước và rõ ràng về lý do bạn yêu cầu mỗi quyền, hãy cho phép người đó nhấp hoặc nhấn để chọn quay lại hộp thoại yêu cầu quyền. Không chuyển ngay họ đến một hộp thoại yêu cầu quyền mà không giải thích.

  • Nếu ai đó đã từ chối một quyền cho ứng dụng, hộp thoại đăng nhập sẽ không cho phép ứng dụng yêu cầu lại quyền đó trừ khi bạn chuyển auth_type=rerequest cùng với yêu cầu của mình.

  • Đối với trường hợp ai đó đã cấp một số quyền nhưng không cấp các quyền khác, hãy chỉ nhắc các quyền bị thiếu tại thời điểm cần những quyền đó. Ví dụ: nếu ứng dụng gửi thư xác nhận đơn đặt hàng đến địa chỉ email của người dùng, hãy chỉ yêu cầu email khi họ đặt hàng.

  • Trừ khi các quyền bạn đang yêu cầu trong hộp thoại đăng nhập rất quan trọng đối với chức năng của ứng dụng và một tính năng sẽ không hoạt động nếu thiếu các quyền đó, hãy cho phép mọi người tiếp tục dùng ứng dụng mà không cần quyền.

Bạn có thể nhận được Cảnh báo cho nhà phát triển nếu ứng dụng nhiều lần chuyển người dùng đến các hộp thoại yêu cầu quyền sau khi họ từ chối cấp quyền. Để ngừng nhận những cảnh báo này, hãy tuân theo các nguyên tắc sau.

Thu hồi quyền

Ứng dụng có thể cho phép mọi người thu hồi các quyền đã được cấp trước đó. Ví dụ: ứng dụng có thể có một trang cài đặt cho phép người dùng vô hiệu hóa khả năng gửi email cho họ. Trang cài đặt đó cũng có thể đồng thời thu hồi quyền email.

Bạn có thể thu hồi một quyền cụ thể bằng cách thực hiện lệnh gọi đến điểm cuối API Đồ thị:

DELETE /{user-id}/permissions/{permission-name}

Yêu cầu này phải được tạo bằng mã truy cập người dùng hoặc mã truy cập ứng dụng của ứng dụng hiện tại. Nếu yêu cầu này thành công, bạn sẽ nhận được phản hồi là true.

Thu hồi quyền đăng nhập

Bạn cũng có thể cho phép mọi người hủy cấp quyền hoàn toàn đối với một ứng dụng hoặc thu hồi quyền đăng nhập bằng cách thực hiện lệnh gọi đến điểm cuối API Đồ thị sau:

DELETE /{user-id}/permissions

Yêu cầu này phải được tạo bằng mã truy cập người dùng hợp lệ hoặc mã truy cập ứng dụng của ứng dụng hiện tại. Nếu yêu cầu này thành công, ứng dụng sẽ nhận được phản hồi là true. Nếu lệnh gọi này thành công, mọi mã truy cập người dùng dành cho người đó sẽ bị vô hiệu hóa và họ sẽ phải đăng nhập lại. Vì bạn đang hủy cấp quyền đối với ứng dụng, nên người dùng cũng sẽ phải cấp quyền truy cập vào ứng dụng nếu họ đăng nhập lần đầu tiên.

Hướng dẫn theo nền tảng

AndroidiOSWeb