Can someone explain to me why half of the documentation says, conercning oauth/login, "To obtain approval from the user, you need to do a browser redirect to the Netflix site and send an HTTP GET request to the Netflix user authorization URL", and why the other half says "A REST resource for authenticating users and requesting permission to access Netflix services on their behalf." and has the "name", "password" and "accept_tos=TRUE" as part of the parameters?
The problem is that we really want to avoid the Password Anti-pattern. Ideally, users should never enter their credentials into an application because there's no telling what that application will do with them. Pointing a user to the log-in page (Something that can be done outside of your app, say, by an email message) gives us the ability to strengthen the login page without effecting your code. By and large, the methodology is RESTful, we're using standard extensions to OAUTH to perform this login.
Unfortunately, the documentation does also discuss "browserless" authentication, which is only available for select, trusted partners.
We really encourage you to use the login redirect method so that there's a consistent experience for the user and you don't raise suspicion regarding your app.
Can someone explain to me why half of the documentation says, conercning oauth/login, "To obtain approval from the user, you need to do a browser redirect to the Netflix site and send an HTTP GET request to the Netflix user authorization URL", and why the other half says "A REST resource for authenticating users and requesting permission to access Netflix services on their behalf." and has the "name", "password" and "accept_tos=TRUE" as part of the parameters?
Can this be REST'ed?
Can it not?
Why do the docs give conflicting information?
Thanks,
David
Message edited by David Engfer 3 years ago
Tags
JR Conlin – 3 years ago
The problem is that we really want to avoid the Password Anti-pattern. Ideally, users should never enter their credentials into an application because there's no telling what that application will do with them. Pointing a user to the log-in page (Something that can be done outside of your app, say, by an email message) gives us the ability to strengthen the login page without effecting your code. By and large, the methodology is RESTful, we're using standard extensions to OAUTH to perform this login.
Unfortunately, the documentation does also discuss "browserless" authentication, which is only available for select, trusted partners.
We really encourage you to use the login redirect method so that there's a consistent experience for the user and you don't raise suspicion regarding your app.
David Engfer – 3 years ago
Thanks for your response. I'm developing a facebook app and was trying to keep the interface fluid within FB, but the login thing worked well