[twitter-dev] Re: Source parameter only available through oauth - misses a use case
I totally agree... Ivo, I got the same answers for a pretty similar question some months ago... I do not see the link between the source parameter and how the authentication is made... Cheers! Ivo wrote: Hi, short answer: oauth is for delegated authentication; I'm using direct authentication of my own account. Both are valid use cases, so in my opinion the source parameter should continue to work for the second use case (I can't find a good reason to only support it for delegated authentication) Besides; all the examples you mention are for delegated authentication; it would be weird to have a headless system that is working as a service implement an oauth scheme. greetings, Ivo On Sep 14, 12:09 pm, Andrew Badera and...@badera.us wrote: With all the freely available examples, and all the freely available documentation and support available through oauth.net, what's stopping you from cranking out an OAuth client implementation in 2 hours? OAuth helps prevent, or at least make obvious for the time being, spammers. HTTP Basic Auth has no value here. ∞ Andy Badera ∞ +1 518-641-1280 ∞ This email is: [ ] bloggable [x] ask first [ ] private ∞ Google me:http://www.google.com/search?q=andrew%20badera On Mon, Sep 14, 2009 at 1:48 AM, Ivo i...@epointment.com wrote: Hi, the developer wiki mentions that the source parameter is no longer recommended, because using oauth, twitter can already know the source of messages. However, there are a few use case scenario's that are limited if source is only available through oauth. Oauth is all about delegated authentication. It's about the user granting access to his resources to a service. There are services out there that do not use the user's credentials at all, but use their own account. E.g. I built flackr.net, and it logs in with its own @flackr account to follow its own timeline and aggregate news on a website. I don't need user's credentials at all for that. The Flackr backend is autonomous and runs on a server that has no web frontend, it just fetches data and processes it. It does send out tweets when it has aggregated something interesting. If I were to use oauth in this scenario I would have to build in full oauth support in my backend script, only to login once with my own account to grant myself access. Since this is not about delegated access, I don't need oauth and can authenticate against twitter directly. This is a perfectly good use case scenario, and the source parameter would have to stay in order to support this use case scenario while still providing a different source.
[twitter-dev] Re: Source parameter only available through oauth - misses a use case
It's an incentive to move to OAuth. Twitter has made their intentions clear about Basic Auth: They want it to go away. By restricting the source parameter to OAuth requests, they give developers an incentive to move forward. On Sep 15, 4:20 am, Emrah e...@ekanet.net wrote: I totally agree... Ivo, I got the same answers for a pretty similar question some months ago... I do not see the link between the source parameter and how the authentication is made... Cheers! Ivo wrote: Hi, short answer: oauth is for delegated authentication; I'm using direct authentication of my own account. Both are valid use cases, so in my opinion the source parameter should continue to work for the second use case (I can't find a good reason to only support it for delegated authentication) Besides; all the examples you mention are for delegated authentication; it would be weird to have a headless system that is working as a service implement an oauth scheme. greetings, Ivo On Sep 14, 12:09 pm, Andrew Badera and...@badera.us wrote: With all the freely available examples, and all the freely available documentation and support available through oauth.net, what's stopping you from cranking out an OAuth client implementation in 2 hours? OAuth helps prevent, or at least make obvious for the time being, spammers. HTTP Basic Auth has no value here. ∞ Andy Badera ∞ +1 518-641-1280 ∞ This email is: [ ] bloggable [x] ask first [ ] private ∞ Google me:http://www.google.com/search?q=andrew%20badera On Mon, Sep 14, 2009 at 1:48 AM, Ivo i...@epointment.com wrote: Hi, the developer wiki mentions that the source parameter is no longer recommended, because using oauth, twitter can already know the source of messages. However, there are a few use case scenario's that are limited if source is only available through oauth. Oauth is all about delegated authentication. It's about the user granting access to his resources to a service. There are services out there that do not use the user's credentials at all, but use their own account. E.g. I built flackr.net, and it logs in with its own @flackr account to follow its own timeline and aggregate news on a website. I don't need user's credentials at all for that. The Flackr backend is autonomous and runs on a server that has no web frontend, it just fetches data and processes it. It does send out tweets when it has aggregated something interesting. If I were to use oauth in this scenario I would have to build in full oauth support in my backend script, only to login once with my own account to grant myself access. Since this is not about delegated access, I don't need oauth and can authenticate against twitter directly. This is a perfectly good use case scenario, and the source parameter would have to stay in order to support this use case scenario while still providing a different source.
[twitter-dev] Re: Source parameter only available through oauth - misses a use case
Ok, but againplease make OAuth pages at twitter mobile friendly so that the mobile web sites can use it! On Sep 15, 11:28 am, Duane Roelands duane.roela...@gmail.com wrote: It's an incentive to move to OAuth. Twitter has made their intentions clear about Basic Auth: They want it to go away. By restricting the source parameter to OAuth requests, they give developers an incentive to move forward. On Sep 15, 4:20 am, Emrah e...@ekanet.net wrote: I totally agree... Ivo, I got the same answers for a pretty similar question some months ago... I do not see the link between the source parameter and how the authentication is made... Cheers! Ivo wrote: Hi, short answer: oauth is for delegated authentication; I'm using direct authentication of my own account. Both are valid use cases, so in my opinion the source parameter should continue to work for the second use case (I can't find a good reason to only support it for delegated authentication) Besides; all the examples you mention are for delegated authentication; it would be weird to have a headless system that is working as a service implement an oauth scheme. greetings, Ivo On Sep 14, 12:09 pm, Andrew Badera and...@badera.us wrote: With all the freely available examples, and all the freely available documentation and support available through oauth.net, what's stopping you from cranking out an OAuth client implementation in 2 hours? OAuth helps prevent, or at least make obvious for the time being, spammers. HTTP Basic Auth has no value here. ∞ Andy Badera ∞ +1 518-641-1280 ∞ This email is: [ ] bloggable [x] ask first [ ] private ∞ Google me:http://www.google.com/search?q=andrew%20badera On Mon, Sep 14, 2009 at 1:48 AM, Ivo i...@epointment.com wrote: Hi, the developer wiki mentions that the source parameter is no longer recommended, because using oauth, twitter can already know the source of messages. However, there are a few use case scenario's that are limited if source is only available through oauth. Oauth is all about delegated authentication. It's about the user granting access to his resources to a service. There are services out there that do not use the user's credentials at all, but use their own account. E.g. I built flackr.net, and it logs in with its own @flackr account to follow its own timeline and aggregate news on a website. I don't need user's credentials at all for that. The Flackr backend is autonomous and runs on a server that has no web frontend, it just fetches data and processes it. It does send out tweets when it has aggregated something interesting. If I were to use oauth in this scenario I would have to build in full oauth support in my backend script, only to login once with my own account to grant myself access. Since this is not about delegated access, I don't need oauth and can authenticate against twitter directly. This is a perfectly good use case scenario, and the source parameter would have to stay in order to support this use case scenario while still providing a different source.
[twitter-dev] Re: Source parameter only available through oauth - misses a use case
With all the freely available examples, and all the freely available documentation and support available through oauth.net, what's stopping you from cranking out an OAuth client implementation in 2 hours? OAuth helps prevent, or at least make obvious for the time being, spammers. HTTP Basic Auth has no value here. ∞ Andy Badera ∞ +1 518-641-1280 ∞ This email is: [ ] bloggable [x] ask first [ ] private ∞ Google me: http://www.google.com/search?q=andrew%20badera On Mon, Sep 14, 2009 at 1:48 AM, Ivo i...@epointment.com wrote: Hi, the developer wiki mentions that the source parameter is no longer recommended, because using oauth, twitter can already know the source of messages. However, there are a few use case scenario's that are limited if source is only available through oauth. Oauth is all about delegated authentication. It's about the user granting access to his resources to a service. There are services out there that do not use the user's credentials at all, but use their own account. E.g. I built flackr.net, and it logs in with its own @flackr account to follow its own timeline and aggregate news on a website. I don't need user's credentials at all for that. The Flackr backend is autonomous and runs on a server that has no web frontend, it just fetches data and processes it. It does send out tweets when it has aggregated something interesting. If I were to use oauth in this scenario I would have to build in full oauth support in my backend script, only to login once with my own account to grant myself access. Since this is not about delegated access, I don't need oauth and can authenticate against twitter directly. This is a perfectly good use case scenario, and the source parameter would have to stay in order to support this use case scenario while still providing a different source.
[twitter-dev] Re: Source parameter only available through oauth - misses a use case
Hi, short answer: oauth is for delegated authentication; I'm using direct authentication of my own account. Both are valid use cases, so in my opinion the source parameter should continue to work for the second use case (I can't find a good reason to only support it for delegated authentication) Besides; all the examples you mention are for delegated authentication; it would be weird to have a headless system that is working as a service implement an oauth scheme. greetings, Ivo On Sep 14, 12:09 pm, Andrew Badera and...@badera.us wrote: With all the freely available examples, and all the freely available documentation and support available through oauth.net, what's stopping you from cranking out an OAuth client implementation in 2 hours? OAuth helps prevent, or at least make obvious for the time being, spammers. HTTP Basic Auth has no value here. ∞ Andy Badera ∞ +1 518-641-1280 ∞ This email is: [ ] bloggable [x] ask first [ ] private ∞ Google me:http://www.google.com/search?q=andrew%20badera On Mon, Sep 14, 2009 at 1:48 AM, Ivo i...@epointment.com wrote: Hi, the developer wiki mentions that the source parameter is no longer recommended, because using oauth, twitter can already know the source of messages. However, there are a few use case scenario's that are limited if source is only available through oauth. Oauth is all about delegated authentication. It's about the user granting access to his resources to a service. There are services out there that do not use the user's credentials at all, but use their own account. E.g. I built flackr.net, and it logs in with its own @flackr account to follow its own timeline and aggregate news on a website. I don't need user's credentials at all for that. The Flackr backend is autonomous and runs on a server that has no web frontend, it just fetches data and processes it. It does send out tweets when it has aggregated something interesting. If I were to use oauth in this scenario I would have to build in full oauth support in my backend script, only to login once with my own account to grant myself access. Since this is not about delegated access, I don't need oauth and can authenticate against twitter directly. This is a perfectly good use case scenario, and the source parameter would have to stay in order to support this use case scenario while still providing a different source.
