Re: [twitter-dev] OAuth Additions
On Tue, Feb 9, 2010 at 20:54, Harshad RJ harshad...@gmail.com wrote: On Wed, Feb 10, 2010 at 8:17 AM, Abraham Williams 4bra...@gmail.comwrote: On Tue, Feb 9, 2010 at 05:28, Dewald Pretorius dpr...@gmail.com wrote: Two additions to OAuth that will be very helpful: 1) When a user removes the application from their connections, Twitter should make a callback to my system so that I can delete the account from my DB. Your application should already have good handling logic built in for users deleting their accounts or changing their usernames. This seems like adding just another point of failure to the system. The handling logic will invariably involve a poll. The OP's solution sounds more efficient. Why would it need a poll? You wait until you have to make a call and if it is refused you know authorization has be revoked. Abraham -- Abraham Williams | Community Advocate | http://abrah.am Project | Out Loud | http://outloud.labs.poseurtech.com This email is: [ ] shareable [x] ask first [ ] private. Sent from Seattle, WA, United States
Re: [twitter-dev] OAuth Additions
On Sat, Feb 13, 2010 at 8:16 AM, Abraham Williams 4bra...@gmail.com wrote: On Tue, Feb 9, 2010 at 20:54, Harshad RJ harshad...@gmail.com wrote: On Wed, Feb 10, 2010 at 8:17 AM, Abraham Williams 4bra...@gmail.comwrote: Your application should already have good handling logic built in for users deleting their accounts or changing their usernames. This seems like adding just another point of failure to the system. The handling logic will invariably involve a poll. The OP's solution sounds more efficient. Why would it need a poll? You wait until you have to make a call and if it is refused you know authorization has be revoked. You are right. I didn't articulate properly and I hadn't understood your statement the first time I read it. Restating, the OP's solution of a callback is efficient for applications that need to know a-priori whether they are authorized by the user. -- Harshad RJ http://hrj.wikidot.com
Re: [twitter-dev] OAuth Additions
Dewald, 1) good idea 2) also a good idea 3) tons :) On Tue, Feb 9, 2010 at 5:28 AM, Dewald Pretorius dpr...@gmail.com wrote: Two additions to OAuth that will be very helpful: 1) When a user removes the application from their connections, Twitter should make a callback to my system so that I can delete the account from my DB. 2) There should be a call my system can make to remove the app from the user's connections, typically in the case where the user deletes his account from my system. As an aside, how many times have you misspelled oauth as ouath in your code?
Re: [twitter-dev] OAuth Additions
On Tue, Feb 9, 2010 at 05:28, Dewald Pretorius dpr...@gmail.com wrote: Two additions to OAuth that will be very helpful: 1) When a user removes the application from their connections, Twitter should make a callback to my system so that I can delete the account from my DB. Your application should already have good handling logic built in for users deleting their accounts or changing their usernames. This seems like adding just another point of failure to the system. 2) There should be a call my system can make to remove the app from the user's connections, typically in the case where the user deletes his account from my system. I am strongly against this. I don't like the idea that an application can act on my behalf then disappear. Any authorized applications should stay listed unless I explicitly remove them. If a user deletes his account from you system forget his access_token and move on. A possible compromise is to add a deactivated stage that applications could set themselves in for each user. As an aside, how many times have you misspelled oauth as ouath in your code? Many mnay times. ;) -- Abraham Williams | Community Advocate | http://abrah.am Project | Out Loud | http://outloud.labs.poseurtech.com This email is: [ ] shareable [x] ask first [ ] private. Sent from Seattle, WA, United States
Re: [twitter-dev] OAuth Additions
2) There should be a call my system can make to remove the app from the user's connections, typically in the case where the user deletes his account from my system. I am strongly against this. I don't like the idea that an application can act on my behalf then disappear. Any authorized applications should stay listed unless I explicitly remove them. If a user deletes his account from you system forget his access_token and move on. A possible compromise is to add a deactivated stage that applications could set themselves in for each user. i tend to agree with abraham on this one -- i understand your use case, dewald, but how does twitter, verifiably know that the user has deleted their account from your system? i think its too easy for us to do a weird thing here, from the perspective of the user. -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] OAuth Additions
On Wed, Feb 10, 2010 at 8:17 AM, Abraham Williams 4bra...@gmail.com wrote: On Tue, Feb 9, 2010 at 05:28, Dewald Pretorius dpr...@gmail.com wrote: Two additions to OAuth that will be very helpful: 1) When a user removes the application from their connections, Twitter should make a callback to my system so that I can delete the account from my DB. Your application should already have good handling logic built in for users deleting their accounts or changing their usernames. This seems like adding just another point of failure to the system. The handling logic will invariably involve a poll. The OP's solution sounds more efficient. 2) There should be a call my system can make to remove the app from the user's connections, typically in the case where the user deletes his account from my system. I am strongly against this. I don't like the idea that an application can act on my behalf then disappear. Any authorized applications should stay listed unless I explicitly remove them. If a user deletes his account from you system forget his access_token and move on. A possible compromise is to add a deactivated stage that applications could set themselves in for each user. I agree with Abraham on this. -- Harshad RJ http://hrj.wikidot.com
