OAuth 2.x UI ideas [#318782]

Hi
we did a lot of work for UI of oauth module .. here in version 2 we can again discuss what kind of UI should this module have

Let me explain a bit(earlier in version 1) :

UI features for normal authenticated users :

1. oauth token + oauth shared secret key on account page
2. End point url details of server on account page.
3. A cool auth authentication system(exactly like flickr) where developers can register for an API key (we call cool-auth key) and access oauth services on website

3. A form where users can register and edit their cool-auth applications
4. A tab where users can keep track of issued oauth access tokens corresponding to registered cool-auth service(eg. http://pimg.com ..)
5. Permissions with users to delete access tokens corresponding to a service
6. Test browser where users can test their oauth installs (I think it as an imp. feature)

UI features for administrators :

1. Test browser from administrator interface
2. Interface to choose if you like to use OAuth with services API or not .. otherwise it works as simple protocol with no calls to services
3. Interface to choose if you like to use pluggable registering service cool-auth with oauth OR not
4. Interface to view all registered applications on website(cool-auth)
5. Interface for admin to add/register new applications corresponding to a user-id

The above interface is already a part of ver 1 of oauth module .. what we are trying to import to ver 2 we can discuss here

There is a screencast to show this module(ver 1) works in best case is here http://blip.tv/file/1184077

Comments

Comment #1

brmassa CreditAttribution: brmassa commented 8 October 2008 at 23:41

Title:

UI for new version of oauth module

» OAuth 2.x UI ideas

Sumit!

HI THERE! i asked Boris to let me do some work on OAuth. He asked me to not mix with your code, so i created a 2.x branch.

I would love to expand it. The topics bellow follow your list numbers:

Users:

OAuth keys are already there. Only available if the user has the "integrate external application" permission. This permission is on Web Services module. We might consider to create our own version. I just dont want duplicate things much.
I prefer to let admins decide how to present the site's specific URLs and methods. All sites that want to provide an external API might need a dedicated page explaining step-by-step. I personally dont see much reason to duplicate this data into each user profile page.
I would prefer consider Cool Auth as an external module. Not only the name by the technique is not the OAuth standard and it looks weird to offer a custom OAuth module. In fact, i dont understand Cool Auth concept very much.
Currently, the consumer keys are associated to users, not applications. If an user want to write 2 sites that will be a consumer, they will share the same consumer key. The name or URL of the application is not even asked (since its not a OAuth standard). So there is no good way to list what sites a user authorized to consume the services without giving the consumer's name. It would be a nice feature however.
We might implement this feature, but it depends on the item above: the list of existing tokens.
I didnt get it. Service provider developers might need to test if their services work, but users?

Admins:

I dont know if i gotit right. Test what? If OAuth is working?
Currently, its not integrated with Services module, but only Web Services module, which allow a authentication plugin (If WebServices module will use OAuth or another method, its defined on that module). The specific code that integrates it is very small, so i think its not subject of another module.
As i said before, i prefer to consider Cool Auth as a external module.
Despite the item above, it would be nice to export all token and consumer key data to Views, so users might build admin lists.
As i said on users's item 4, the consumer keys are linked directly to Drupal users and not to their registered applications.

The summary is:

Integrate all data with Views
Consider link consumer keys to applications, instead directly to users (but generally, they will be basically one-to-one)
Build Cool Auth as an extra module (maybe a submodule)

I think i addressed all issues. But because its a very young module with basically no documentation (i suggest to all of us to improve deeply the docs on http://drupal.org/node/296205), we dont have much "in the field" data: users telling that the current UI is or is not good and how to improve.

best regards,

massa