Re: [delicious-discuss] Re: remote app auth
Remote access would only be granted when the remote app presents a triple (url, user, password). One important difference seems to be the easier support to long transactions in this case. Transactions could be independent of the browser or user interaction. I can't see where the user is having more work. In the simplest case, it only has to register an app and send the credentials to this new app. However he can use more advanced functions - like filtering and logging. Sérgio Nunes On 10/7/05, joshua schachter [EMAIL PROTECTED] wrote: There's no easy way to prevent a url from using a password or whatever, since they aren't actually objects that have actions. There's only IP addresses or authentication pairs (username, password, etc) I don't see this solution particularly different from what I propose aside from making the user do more stuff to authenticate an application. Joshua Hi, regarding remote authorization, the proposed method seems complex. I suggest the following - each user can have multiple passwords. 1) In del.icio.us remote auth settings I can add/delete URLs. 2) Adding an URL returns a new password for my user, that only works for the given URL. 3) Removing an URL revokes password, thus denying the remote application's access to my data. 4) del.icio.is keeps a log for each interaction from the remote app - I can check it and audit what the remote app is doing. 5) I give my del.icio.us username plus my new password to the remote app. Plus: The user could be able to set permissions for each new URL. Example: just read,, read/write, just access tags: X1, X2, X2..., don't access to tags: Y1, Y2..., etc. Seems more simple and intuitive for the user. Sérgio Nunes Date: Sun, 11 Sep 2005 23:13:50 -0400 From: joshua schachter [EMAIL PROTECTED] Subject: [delicious-discuss] remote app auth i'd like to put together a spec for letting users authorize remote application access without giving away their actual password. here's a very preliminary idea: 1) remote webapp links to, say, del.icio.us/auth?return=http:// place.to.send.auth.key/ 2) user ends up on a page that tells him 'grant access to http:// place.to.send.auth.key for write/read/decline' 3) chooses read or write or whatever and is redirected to http:// place.to.send.auth.key/?user=xyzkey=abc and this is logged to some del.icio.us database. (or maybe this should be POST) 4) api will accept either password or the auth key thoughts? -- joshua schachter [EMAIL PROTECTED] ___ discuss mailing list discuss@del.icio.us http://lists.del.icio.us/cgi-bin/mailman/listinfo/discuss -- joshua schachter [EMAIL PROTECTED] ___ discuss mailing list discuss@del.icio.us http://lists.del.icio.us/cgi-bin/mailman/listinfo/discuss
[delicious-discuss] Re: remote app auth
Hi, regarding remote authorization, the proposed method seems complex. I suggest the following - each user can have multiple passwords. 1) In del.icio.us remote auth settings I can add/delete URLs. 2) Adding an URL returns a new password for my user, that only works for the given URL. 3) Removing an URL revokes password, thus denying the remote application's access to my data. 4) del.icio.is keeps a log for each interaction from the remote app - I can check it and audit what the remote app is doing. 5) I give my del.icio.us username plus my new password to the remote app. Plus: The user could be able to set permissions for each new URL. Example: just read,, read/write, just access tags: X1, X2, X2..., don't access to tags: Y1, Y2..., etc. Seems more simple and intuitive for the user. Sérgio Nunes Date: Sun, 11 Sep 2005 23:13:50 -0400 From: joshua schachter [EMAIL PROTECTED] Subject: [delicious-discuss] remote app auth i'd like to put together a spec for letting users authorize remote application access without giving away their actual password. here's a very preliminary idea: 1) remote webapp links to, say, del.icio.us/auth?return=http:// place.to.send.auth.key/ 2) user ends up on a page that tells him 'grant access to http:// place.to.send.auth.key for write/read/decline' 3) chooses read or write or whatever and is redirected to http:// place.to.send.auth.key/?user=xyzkey=abc and this is logged to some del.icio.us database. (or maybe this should be POST) 4) api will accept either password or the auth key thoughts? -- joshua schachter [EMAIL PROTECTED] ___ discuss mailing list discuss@del.icio.us http://lists.del.icio.us/cgi-bin/mailman/listinfo/discuss
Re: [delicious-discuss] Re: remote app auth
There's no easy way to prevent a url from using a password or whatever, since they aren't actually objects that have actions. There's only IP addresses or authentication pairs (username, password, etc) I don't see this solution particularly different from what I propose aside from making the user do more stuff to authenticate an application. Joshua Hi, regarding remote authorization, the proposed method seems complex. I suggest the following - each user can have multiple passwords. 1) In del.icio.us remote auth settings I can add/delete URLs. 2) Adding an URL returns a new password for my user, that only works for the given URL. 3) Removing an URL revokes password, thus denying the remote application's access to my data. 4) del.icio.is keeps a log for each interaction from the remote app - I can check it and audit what the remote app is doing. 5) I give my del.icio.us username plus my new password to the remote app. Plus: The user could be able to set permissions for each new URL. Example: just read,, read/write, just access tags: X1, X2, X2..., don't access to tags: Y1, Y2..., etc. Seems more simple and intuitive for the user. Sérgio Nunes Date: Sun, 11 Sep 2005 23:13:50 -0400 From: joshua schachter [EMAIL PROTECTED] Subject: [delicious-discuss] remote app auth i'd like to put together a spec for letting users authorize remote application access without giving away their actual password. here's a very preliminary idea: 1) remote webapp links to, say, del.icio.us/auth?return=http:// place.to.send.auth.key/ 2) user ends up on a page that tells him 'grant access to http:// place.to.send.auth.key for write/read/decline' 3) chooses read or write or whatever and is redirected to http:// place.to.send.auth.key/?user=xyzkey=abc and this is logged to some del.icio.us database. (or maybe this should be POST) 4) api will accept either password or the auth key thoughts? -- joshua schachter [EMAIL PROTECTED] ___ discuss mailing list discuss@del.icio.us http://lists.del.icio.us/cgi-bin/mailman/listinfo/discuss -- joshua schachter [EMAIL PROTECTED] ___ discuss mailing list discuss@del.icio.us http://lists.del.icio.us/cgi-bin/mailman/listinfo/discuss
