[twitter-dev] Re: A new permission level

[TheGuru]

This is where my confusion stemmed from.

I'm not sure I was aware of the fact there were 2 OAuth login flows,
"web flow" versus "sign in with Twitter".

As soon as I flipped the boolean in my PHP include for OAuth to set
sign_in_with_twitter = FALSE, so that it would use /authorize instead
of /authenticate (sign in with twitter), I then saw the correct
permissions on the login page.

I'm not sure this is obvious to many devs (it wasn't to me), that
there was a difference.  I just happened to use / assume "sign in with
twitter" was the only web based login available after the
implementation of OAuth.

What are the implications / reasons for using one method over the
other?  They seem to essentially do the same exact thing / accomplish
the same exact goal.

On May 19, 3:17 pm, themattharris  wrote:

> The permission level for your application can be edited 
> onhttp://dev.twitter.com/apps. When the website is busy, it can take a
> little bit longer for changes to your application to be reflected.
>
> > Is using a web view against the Terms of Service (TOS)?
>
> Using an in-app web view to show the OAuth pages is not against our
> TOS. However, we encourage developers to use the built-in browser
> where appropriate.
>
> > You said you were restricting this permission to the OAuth /authorize web 
> > flow only. Will /oauth/authenticate (Sign in with Twitter) support the new 
> > permission?
>
> The R/W/DM permission can only be granted through the /oauth/authorize
> route. Sign in with Twitter cannot be used to grant R/W/DM.
>
> We understand applications may use other methods of authentication
> like Sign in with Twitter as well. For this reason, if a user has
> authorised your application for R/W/DM and you direct them through
> Sign in with Twitter, we will respect the existing access token
> permission. This means you can use Sign in with Twitter after a user
> has authorized your application for R/W/DM.
>

-- 
Twitter developer documentation and resources: https://dev.twitter.com/doc
API updates via Twitter: https://twitter.com/twitterapi
Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
https://groups.google.com/forum/#!forum/twitter-development-talk

[twitter-dev] Re: A new permission level

[TheGuru]

Hmm, thanks.

Wonder why some are seeing this take affect and others, as reported in
this thread (including myself), are not...

On May 19, 1:13 pm, Mark Pavlidis  wrote:
> TheGuru,
> I set my app to RWPM permission at dev.twitter.com/apps and now it
> displays as such on the OAuth login page and on twitter.com/settings/
> applications.
>
> On May 19, 2:04 pm, TheGuru  wrote:
>
>
>
>
>
>
>
> > That is to be expected regarding the 401.
>
> > However, while I see the changes on the application page of a
> > particular account, the OAuth login screen at Twitter for my
> > application still states:
>
> > This application will not be able to:
>
> >     Access your private messages.
> >     See your Twitter password.
>
> > Did you make any other changes other than upading the privilege level
> > for your application at dev.twitter.com?
>
> > On May 19, 12:49 pm, Mark Pavlidis  wrote:
>
> > > Yes i've seen the changes on my applications page and on the OAuth
> > > login page. Further, my other device that was logged in using the old
> > > Read,Write token was getting Unauthorized (401) responses as that
> > > token was revoked an replaced with the Read, Write, Private message
> > > token.  Should be handled appropriately if you are a dev with an app
> > > on multiple platforms.
>
> > > Mark
>
> > > On May 19, 9:42 am, TheGuru  wrote:
>
> > > > +1.  I'm seeing the same thing and not sure if it is a waiting game or
> > > > something that needs adjusted in the flow from the client side as
> > > > well.
>
> > > > Any insight is appreciated.
>
> > > > Has anyone who adjusted their app permissions on dev.twitter.com seen
> > > > this reflected on the OAuth login page at Twitter?
>
> > > > On May 19, 2:02 am, Adriaan Pelzer  wrote:
>
> > > > > Hi Matt,
>
> > > > > I have started implementing these changes. The app's permissions 
> > > > > setting is
> > > > > set to "Read, Write & DM" (the new one).
>
> > > > > However, when the user gets redirected to the auth page, it still 
> > > > > indicates
> > > > > that the app will not be able to read or send DM's. Is this something 
> > > > > that
> > > > > will automatically happen when you activate it, or is there a 
> > > > > permissions
> > > > > parameter I should send to the auth page?
>
> > > > > Adriaan Pelzer
>
> > > > >  //))//\\//\\||//
> > > > > //\\//7//7///\\
>
> > > > > putting you in touch with your crowdshttp://www.wewillraakyou.com
> > > > > <http://www.wewillraakyou.com>twitter:http://www.twitter.com/adriaan_pelzer
> > > > > linkedIn:http://uk.linkedin.com/pub/adriaan-pelzer/4/874/860/
> > > > > skype: adriaan_pelzer
> > > > > <http://uk.linkedin.com/pub/adriaan-pelzer/4/874/860/>
> > > > > +4478 7978 1743
>
> > > > > On Wed, May 18, 2011 at 6:01 PM, Matt Harris 
> > > > > wrote:
>
> > > > > > Hey everyone,
>
> > > > > > We recently updated our OAuth screens to give users greater 
> > > > > > transparency
> > > > > > about the level of access applications have to their accounts. The 
> > > > > > valuable
> > > > > > feedback Twitter users and developers have given us played a large 
> > > > > > part in
> > > > > > that redesign and helped us identify where we can do more.
>
> > > > > > In particular, users and developers have requested greater 
> > > > > > granularity for
> > > > > > permission levels.
>
> > > > > > In response to this feedback, we have created a new permission 
> > > > > > level for
> > > > > > applications called “Read, Write & Direct Messages”. This 
> > > > > > permission will
> > > > > > allow an application to read or delete a user's direct messages. 
> > > > > > When we
> > > > > > enforce this permission, applications without a “Read, Write & 
> > > > > > Direct
> > > > > > Messages” token will be unable to read or delete direct messages. 
> > > > > > To ensure
> > > > > > users know that an application is receiving access to their direct 
>

[twitter-dev] Re: A new permission level

[TheGuru]

That is to be expected regarding the 401.

However, while I see the changes on the application page of a
particular account, the OAuth login screen at Twitter for my
application still states:

This application will not be able to:

Access your private messages.
See your Twitter password.

Did you make any other changes other than upading the privilege level
for your application at dev.twitter.com?

On May 19, 12:49 pm, Mark Pavlidis  wrote:
> Yes i've seen the changes on my applications page and on the OAuth
> login page. Further, my other device that was logged in using the old
> Read,Write token was getting Unauthorized (401) responses as that
> token was revoked an replaced with the Read, Write, Private message
> token.  Should be handled appropriately if you are a dev with an app
> on multiple platforms.
>
> Mark
>
> On May 19, 9:42 am, TheGuru  wrote:
>
>
>
>
>
>
>
> > +1.  I'm seeing the same thing and not sure if it is a waiting game or
> > something that needs adjusted in the flow from the client side as
> > well.
>
> > Any insight is appreciated.
>
> > Has anyone who adjusted their app permissions on dev.twitter.com seen
> > this reflected on the OAuth login page at Twitter?
>
> > On May 19, 2:02 am, Adriaan Pelzer  wrote:
>
> > > Hi Matt,
>
> > > I have started implementing these changes. The app's permissions setting 
> > > is
> > > set to "Read, Write & DM" (the new one).
>
> > > However, when the user gets redirected to the auth page, it still 
> > > indicates
> > > that the app will not be able to read or send DM's. Is this something that
> > > will automatically happen when you activate it, or is there a permissions
> > > parameter I should send to the auth page?
>
> > > Adriaan Pelzer
>
> > >  //))//\\//\\||//
> > > //\\//7//7///\\
>
> > > putting you in touch with your crowdshttp://www.wewillraakyou.com
> > > <http://www.wewillraakyou.com>twitter:http://www.twitter.com/adriaan_pelzer
> > > linkedIn:http://uk.linkedin.com/pub/adriaan-pelzer/4/874/860/
> > > skype: adriaan_pelzer
> > > <http://uk.linkedin.com/pub/adriaan-pelzer/4/874/860/>
> > > +4478 7978 1743
>
> > > On Wed, May 18, 2011 at 6:01 PM, Matt Harris 
> > > wrote:
>
> > > > Hey everyone,
>
> > > > We recently updated our OAuth screens to give users greater transparency
> > > > about the level of access applications have to their accounts. The 
> > > > valuable
> > > > feedback Twitter users and developers have given us played a large part 
> > > > in
> > > > that redesign and helped us identify where we can do more.
>
> > > > In particular, users and developers have requested greater granularity 
> > > > for
> > > > permission levels.
>
> > > > In response to this feedback, we have created a new permission level for
> > > > applications called “Read, Write & Direct Messages”. This permission 
> > > > will
> > > > allow an application to read or delete a user's direct messages. When we
> > > > enforce this permission, applications without a “Read, Write & Direct
> > > > Messages” token will be unable to read or delete direct messages. To 
> > > > ensure
> > > > users know that an application is receiving access to their direct 
> > > > messages,
> > > > we are also restricting this permission to the OAuth /authorize web flow
> > > > only. This means applications which use xAuth and want to access direct
> > > > messages must send a user through the full OAuth flow.
>
> > > > What does this mean for your application?
> > > > If you do not need access to direct messages: you won’t need to make any
> > > > changes to your application. When we enforce the new permission level 
> > > > your
> > > > read or read/write token will automatically lose access to direct 
> > > > messages.
>
> > > > If you do need access to direct messages: you will need to edit your
> > > > application record onhttps://dev.twitter.com/appsandchangethe
> > > > permission level of your application to “Read, Write and Direct 
> > > > Messages”.
> > > > The new permission will not affect existing tokens which means existing
> > > > users or your app or service will need to reauthorize.
>
> > > > We know this will take some time so we are allowing a transition 

[twitter-dev] Re: A new permission level

[TheGuru]

+1.  I'm seeing the same thing and not sure if it is a waiting game or
something that needs adjusted in the flow from the client side as
well.

Any insight is appreciated.

Has anyone who adjusted their app permissions on dev.twitter.com seen
this reflected on the OAuth login page at Twitter?

On May 19, 2:02 am, Adriaan Pelzer  wrote:
> Hi Matt,
>
> I have started implementing these changes. The app's permissions setting is
> set to "Read, Write & DM" (the new one).
>
> However, when the user gets redirected to the auth page, it still indicates
> that the app will not be able to read or send DM's. Is this something that
> will automatically happen when you activate it, or is there a permissions
> parameter I should send to the auth page?
>
> Adriaan Pelzer
>
>  //))//\\//\\||//
> //\\//7//7///\\
>
> putting you in touch with your crowdshttp://www.wewillraakyou.com
> twitter:http://www.twitter.com/adriaan_pelzer
> linkedIn:http://uk.linkedin.com/pub/adriaan-pelzer/4/874/860/
> skype: adriaan_pelzer
> 
> +4478 7978 1743
>
> On Wed, May 18, 2011 at 6:01 PM, Matt Harris wrote:
>
>
>
>
>
>
>
> > Hey everyone,
>
> > We recently updated our OAuth screens to give users greater transparency
> > about the level of access applications have to their accounts. The valuable
> > feedback Twitter users and developers have given us played a large part in
> > that redesign and helped us identify where we can do more.
>
> > In particular, users and developers have requested greater granularity for
> > permission levels.
>
> > In response to this feedback, we have created a new permission level for
> > applications called “Read, Write & Direct Messages”. This permission will
> > allow an application to read or delete a user's direct messages. When we
> > enforce this permission, applications without a “Read, Write & Direct
> > Messages” token will be unable to read or delete direct messages. To ensure
> > users know that an application is receiving access to their direct messages,
> > we are also restricting this permission to the OAuth /authorize web flow
> > only. This means applications which use xAuth and want to access direct
> > messages must send a user through the full OAuth flow.
>
> > What does this mean for your application?
> > If you do not need access to direct messages: you won’t need to make any
> > changes to your application. When we enforce the new permission level your
> > read or read/write token will automatically lose access to direct messages.
>
> > If you do need access to direct messages: you will need to edit your
> > application record onhttps://dev.twitter.com/appsand change the
> > permission level of your application to “Read, Write and Direct Messages”.
> > The new permission will not affect existing tokens which means existing
> > users or your app or service will need to reauthorize.
>
> > We know this will take some time so we are allowing a transition period
> > until the end of this month. During this time there will be no change to the
> > access Read/Write tokens have to a users account. However, at the end of the
> > month any tokens which have not been upgrade to “Read, Write and Direct
> > Messages” will be unable to access and delete direct messages.
>
> > Affected APIs and requests
> > On the REST API, Read and Read/Write applications will no longer be able to
> > use these API methods:
> > /1/direct_messages.{format}
> > /1/direct_messages/sent.{format}
> > /1/direct_messages/show.{format}
> > /1/direct_messages/destroy.{format}
>
> > For the Streaming API, both User Streams and Site Streams will only receive
> > direct messages if the user has authorised an application to access direct
> > messages.
>
> > Applications that use “Sign-in with Twitter” or xAuth will only be able to
> > receive Read or Read/Write tokens.
>
> > What this means is only applications which direct a user through the OAuth
> > web flow will be able to receive access tokens that allow access to direct
> > messages. Any other method of authorization, including xAuth, will only be
> > able to receive Read/Write tokens.
>
> > What will happen when the permission is activated
> > When we activate the new permission, all Read and Read/Write user_tokens
> > issued to third-party applications will lose their ability to read direct
> > messages. Any attempt to read direct messages will result in an HTTP 403
> > error being returned.
>
> > For example, a GET request to
> >https://api.twitter.com/1/direct_messages/sent.jsonwill return an HTTP
> > 403 Forbidden with the response body:
>
> > {"errors":[{"code":93,"message":"This application is not allowed to access
> > or delete your direct messages"}]}
>
> > Key Points
> > * If you wish to access a user’s direct messages you will need to update
> > your application and reauthorize existing tokens.
> > * The only way to get direct message access is to request access through
> > the OAut

[twitter-dev] "Local trends near you" user setting via API?

[TheGuru]

Is there a way yet, via the api, to determine if a user has set their
trends to display for specific locale, versus worldwide?

In my searching, I came across the following post back in January,
stating that the setting would be included in the  object,  but
I'm not seeing anything yet:

http://groups.google.com/group/twitter-development-talk/browse_thread/thread/589c14b4649f421c/571d477f1ee73b62

Thanks.

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk?hl=en

[twitter-dev] Re: garbage in json api response?

[TheGuru]

+1, unable to parse timeline due to garbage in the XML feed.  Many of
our users are reporting the same problem.

On Sep 3, 7:35 am, koujitaro  wrote:
> Same phenomenon occured in xml.
>
> URL is 
> belowhttp://api.twitter.com/1/statuses/user_timeline.xml?user_id=93771355

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk?hl=en

[twitter-dev] Re: OAuth and impact on Twitter userbase / volume and freedom of speech

[TheGuru]

You're failing to see the point.

In the past, with basic auth, there was no need to "create any sort of
account" from the third party app side.  No need for a database, local
accounts, nothing.  A user could login as this wish, without issue,
regardless as to whether or not they need to access the Twitter.com
domain, ever.  Removing this login method changes the entire flow,
adds requirements for third party apps to now maintain their own,
potentially, local database user accounts, etc, and still requires the
user to access, even once, twitter.com.  It just doesn't flow to say,
hey, when you're home, do this, then come back later.  Sure it may
work, it's just "not eloquent", and has a negative impact on any
existing userbase.

BTW, for your reference, yes, we have already been "web sensed" in
many cases anyway for many users at their location.  Of course, just
so my "claim" rings true with you, please reference the following
link, and I'll let you figure out which application applies:

http://www.google.com/ig/directory?q=twitter (Note: that's installed
userbase for iGoogle only, doesn't count gmail, standalone, wave, etc,
that'd take it closer to 1,000,000).


On Aug 14, 9:37 am, Ken  wrote:
> Why is this an issue?
>
> A few months ago, someone from Twitter I believe suggested a pattern
> such as this:
>
> User starts to create an account on your site
> To enable the Twitter integration, you send them to Twitter.com *once*
> where they allow your app.
> You store their token and log the user in to your site with a
> temporary password you generate, that they can change. You might
> collect their email address this way.
> From then on, they never have to go to Twitter.com. They can interact
> with Twitter via your app, using your website, email, sms, etc.
>
> Of course, with the massive use of your site that you claim, it won't
> be long before your site is listed by Websense and the various evil
> governments mentioned above.
>
> On Aug 14, 1:04 am, TheGuru  wrote:
>
> > Is there no one from Twitter proper who has a position regarding this?
>
> > On Aug 13, 2:12 pm, TheGuru  wrote:
>
> > > Add that to the list of even more reasons why this is an issue.
>
> > > However, even stating oh well, tell them to use their cell phones,
> > > obviously isn't a solution of any degree.  Smart Phone penetration in
> > > the US, for example, is still less than 20%...
>
> > > On Aug 13, 9:43 am, earth2marsh  wrote:
>
> > > > At least "people at work" have the potential to use phones to access
> > > > Twitter…
>
> > > > I'm worried about users like those in China behind The Great Firewall.
> > > > Currently, they can interact with Twitter by using proxies and http
> > > > basic auth. But OAuth requires access to twitter.com (or some sort of
> > > > mediation). xAuth could be a solution, but there is already a shortage
> > > > of clients that support alternate endpoints, and some of those use
> > > > OAuth instead of xAuth (or neither).
>
> > > > When basic auth is shut off, who knows how many Chinese voices will
> > > > fall silent… or in North Korea. Or in Iran. Or in …?
>
> > > > I'm interested in hearing what others think about this.
>
> > > > Marsh
>
> > > > On Aug 12, 10:31 pm, TheGuru  wrote:
>
> > > > > I'm curious to post this question to see if Twitter has fully thought
> > > > > out the impact of forcing OAuth onto their API applications.  While it
> > > > > may appear to be a more secure method preferred in principle by users,
> > > > > the fact of the matter is that one of the main benefits of the API, is
> > > > > the ability for third party twitter alternatives to be created, thus
> > > > > allowing people to tweet during "business hours", when they normally
> > > > > could not due to firewall / web sense restrictions, etc, that prevent
> > > > > them from accessing the twitter.com domain.
>
> > > > > Via basic authentication, users would never have to visit twitter.com
> > > > > to login and gain access to twitter functionality via api clients.  By
> > > > > shutting this down, you are now forcing ALL potential users to login
> > > > > via twitter.com, many of which do not have access to this domain in
> > > > > their workplace environment, thus excluding them from easily using
> > > > > your service wholesale.
>
> > > > > This can / will, I suspect, have significant impact on twitter usage /
> > > > > volume, unless I am missing something and there is an alternative the
> > > > > does not require them to directly access the twitter.com domain to
> > > > > grant access.

[twitter-dev] Re: OAuth and impact on Twitter userbase / volume and freedom of speech

[TheGuru]

Is there no one from Twitter proper who has a position regarding this?

On Aug 13, 2:12 pm, TheGuru  wrote:
> Add that to the list of even more reasons why this is an issue.
>
> However, even stating oh well, tell them to use their cell phones,
> obviously isn't a solution of any degree.  Smart Phone penetration in
> the US, for example, is still less than 20%...
>
> On Aug 13, 9:43 am, earth2marsh  wrote:
>
> > At least "people at work" have the potential to use phones to access
> > Twitter…
>
> > I'm worried about users like those in China behind The Great Firewall.
> > Currently, they can interact with Twitter by using proxies and http
> > basic auth. But OAuth requires access to twitter.com (or some sort of
> > mediation). xAuth could be a solution, but there is already a shortage
> > of clients that support alternate endpoints, and some of those use
> > OAuth instead of xAuth (or neither).
>
> > When basic auth is shut off, who knows how many Chinese voices will
> > fall silent… or in North Korea. Or in Iran. Or in …?
>
> > I'm interested in hearing what others think about this.
>
> > Marsh
>
> > On Aug 12, 10:31 pm, TheGuru  wrote:
>
> > > I'm curious to post this question to see if Twitter has fully thought
> > > out the impact of forcing OAuth onto their API applications.  While it
> > > may appear to be a more secure method preferred in principle by users,
> > > the fact of the matter is that one of the main benefits of the API, is
> > > the ability for third party twitter alternatives to be created, thus
> > > allowing people to tweet during "business hours", when they normally
> > > could not due to firewall / web sense restrictions, etc, that prevent
> > > them from accessing the twitter.com domain.
>
> > > Via basic authentication, users would never have to visit twitter.com
> > > to login and gain access to twitter functionality via api clients.  By
> > > shutting this down, you are now forcing ALL potential users to login
> > > via twitter.com, many of which do not have access to this domain in
> > > their workplace environment, thus excluding them from easily using
> > > your service wholesale.
>
> > > This can / will, I suspect, have significant impact on twitter usage /
> > > volume, unless I am missing something and there is an alternative the
> > > does not require them to directly access the twitter.com domain to
> > > grant access.

[twitter-dev] Re: OAuth and impact on Twitter userbase / volume and freedom of speech

[TheGuru]

Add that to the list of even more reasons why this is an issue.

However, even stating oh well, tell them to use their cell phones,
obviously isn't a solution of any degree.  Smart Phone penetration in
the US, for example, is still less than 20%...

On Aug 13, 9:43 am, earth2marsh  wrote:
> At least "people at work" have the potential to use phones to access
> Twitter…
>
> I'm worried about users like those in China behind The Great Firewall.
> Currently, they can interact with Twitter by using proxies and http
> basic auth. But OAuth requires access to twitter.com (or some sort of
> mediation). xAuth could be a solution, but there is already a shortage
> of clients that support alternate endpoints, and some of those use
> OAuth instead of xAuth (or neither).
>
> When basic auth is shut off, who knows how many Chinese voices will
> fall silent… or in North Korea. Or in Iran. Or in …?
>
> I'm interested in hearing what others think about this.
>
> Marsh
>
> On Aug 12, 10:31 pm, TheGuru  wrote:
>
> > I'm curious to post this question to see if Twitter has fully thought
> > out the impact of forcing OAuth onto their API applications.  While it
> > may appear to be a more secure method preferred in principle by users,
> > the fact of the matter is that one of the main benefits of the API, is
> > the ability for third party twitter alternatives to be created, thus
> > allowing people to tweet during "business hours", when they normally
> > could not due to firewall / web sense restrictions, etc, that prevent
> > them from accessing the twitter.com domain.
>
> > Via basic authentication, users would never have to visit twitter.com
> > to login and gain access to twitter functionality via api clients.  By
> > shutting this down, you are now forcing ALL potential users to login
> > via twitter.com, many of which do not have access to this domain in
> > their workplace environment, thus excluding them from easily using
> > your service wholesale.
>
> > This can / will, I suspect, have significant impact on twitter usage /
> > volume, unless I am missing something and there is an alternative the
> > does not require them to directly access the twitter.com domain to
> > grant access.

[twitter-dev] Re: OAuth and impact on Twitter userbase / volume

[TheGuru]

Yes, I understand that, and this wasn't the point for the development
of the app, but it was a bonus (unintended) side affect, that, quite
frankly, Twitter benefits from, in terms of usage statistics, volume,
etc.

And, as mentioned, I'm willing to bet this wasn't thought about during
the conversion to OAuth by twitter.  By cutting this collective group
of users off (unintentionally), I just think it is going to have more
of an impact (at least short term), than realized.

On Aug 13, 9:28 am, Tom van der Woerdt  wrote:
> And you have a valid point, but you can't expect Twitter to build their
> stuff so that people can tweet while their boss does not want them to. ;-)
>
> Tom
>
> On 8/13/10 4:26 PM, TheGuru wrote:
>
> > Ha, well, I'm not the one circumventing this issue at work, I'm the
> > one who has an application with hundreds of thousands of users, many
> > of which are now affected...
>
> > On Aug 13, 9:21 am, Tom van der Woerdt  wrote:
> >> In that case, just get back to work and stop tweeting :-)
>
> >> Tom
>
> >> On 8/13/10 4:15 PM, TheGuru wrote:
>
> >>> And, just to clarify, I am referring to web based api applications,
> >>> where are many, all if which are affected, as xAuth is NOT,
> >>> apparently, and option in this type of setup.
>
> >>> On Aug 13, 8:54 am, Tom van der Woerdt  wrote:
> >>>> On 8/13/10 4:31 AM, TheGuru wrote:
>
> >>>>> I'm curious to post this question to see if Twitter has fully thought
> >>>>> out the impact of forcing OAuth onto their API applications.  While it
> >>>>> may appear to be a more secure method preferred in principle by users,
> >>>>> the fact of the matter is that one of the main benefits of the API, is
> >>>>> the ability for third party twitter alternatives to be created, thus
> >>>>> allowing people to tweet during "business hours", when they normally
> >>>>> could not due to firewall / web sense restrictions, etc, that prevent
> >>>>> them from accessing the twitter.com domain.
>
> >>>>> Via basic authentication, users would never have to visit twitter.com
> >>>>> to login and gain access to twitter functionality via api clients.  By
> >>>>> shutting this down, you are now forcing ALL potential users to login
> >>>>> via twitter.com, many of which do not have access to this domain in
> >>>>> their workplace environment, thus excluding them from easily using
> >>>>> your service wholesale.
>
> >>>>> This can / will, I suspect, have significant impact on twitter usage /
> >>>>> volume, unless I am missing something and there is an alternative the
> >>>>> does not require them to directly access the twitter.com domain to
> >>>>> grant access.
>
> >>>> My opinion: if your boss does not allow twitter, then don't do it.
>
> >>>> Although I have to admit that your point is valid, except for one major
> >>>> flaw: if twitter.com was really blocked, then the API would be blocked
> >>>> as well ;-)
>
> >>>> Also, some (most) desktop clients do not require you to login via OAuth,
> >>>> but instead they use xAuth. I'm sorry that you will no longer be able to
> >>>> play the silly quizzes etc, but you'll just have to live with that :-)
>
> >>>> Tom

[twitter-dev] Re: OAuth and impact on Twitter userbase / volume

[TheGuru]

Ha, well, I'm not the one circumventing this issue at work, I'm the
one who has an application with hundreds of thousands of users, many
of which are now affected...

On Aug 13, 9:21 am, Tom van der Woerdt  wrote:
> In that case, just get back to work and stop tweeting :-)
>
> Tom
>
> On 8/13/10 4:15 PM, TheGuru wrote:
>
> > And, just to clarify, I am referring to web based api applications,
> > where are many, all if which are affected, as xAuth is NOT,
> > apparently, and option in this type of setup.
>
> > On Aug 13, 8:54 am, Tom van der Woerdt  wrote:
> >> On 8/13/10 4:31 AM, TheGuru wrote:
>
> >>> I'm curious to post this question to see if Twitter has fully thought
> >>> out the impact of forcing OAuth onto their API applications.  While it
> >>> may appear to be a more secure method preferred in principle by users,
> >>> the fact of the matter is that one of the main benefits of the API, is
> >>> the ability for third party twitter alternatives to be created, thus
> >>> allowing people to tweet during "business hours", when they normally
> >>> could not due to firewall / web sense restrictions, etc, that prevent
> >>> them from accessing the twitter.com domain.
>
> >>> Via basic authentication, users would never have to visit twitter.com
> >>> to login and gain access to twitter functionality via api clients.  By
> >>> shutting this down, you are now forcing ALL potential users to login
> >>> via twitter.com, many of which do not have access to this domain in
> >>> their workplace environment, thus excluding them from easily using
> >>> your service wholesale.
>
> >>> This can / will, I suspect, have significant impact on twitter usage /
> >>> volume, unless I am missing something and there is an alternative the
> >>> does not require them to directly access the twitter.com domain to
> >>> grant access.
>
> >> My opinion: if your boss does not allow twitter, then don't do it.
>
> >> Although I have to admit that your point is valid, except for one major
> >> flaw: if twitter.com was really blocked, then the API would be blocked
> >> as well ;-)
>
> >> Also, some (most) desktop clients do not require you to login via OAuth,
> >> but instead they use xAuth. I'm sorry that you will no longer be able to
> >> play the silly quizzes etc, but you'll just have to live with that :-)
>
> >> Tom

[twitter-dev] Re: OAuth and impact on Twitter userbase / volume

[TheGuru]

API is not blocked if the twitter client (web app), is making api
calls on your behalf (curl call behind the scenes).  That is the crux
of the problem.

On Aug 13, 8:54 am, Tom van der Woerdt  wrote:
> On 8/13/10 4:31 AM, TheGuru wrote:
>
>
>
> > I'm curious to post this question to see if Twitter has fully thought
> > out the impact of forcing OAuth onto their API applications.  While it
> > may appear to be a more secure method preferred in principle by users,
> > the fact of the matter is that one of the main benefits of the API, is
> > the ability for third party twitter alternatives to be created, thus
> > allowing people to tweet during "business hours", when they normally
> > could not due to firewall / web sense restrictions, etc, that prevent
> > them from accessing the twitter.com domain.
>
> > Via basic authentication, users would never have to visit twitter.com
> > to login and gain access to twitter functionality via api clients.  By
> > shutting this down, you are now forcing ALL potential users to login
> > via twitter.com, many of which do not have access to this domain in
> > their workplace environment, thus excluding them from easily using
> > your service wholesale.
>
> > This can / will, I suspect, have significant impact on twitter usage /
> > volume, unless I am missing something and there is an alternative the
> > does not require them to directly access the twitter.com domain to
> > grant access.
>
> My opinion: if your boss does not allow twitter, then don't do it.
>
> Although I have to admit that your point is valid, except for one major
> flaw: if twitter.com was really blocked, then the API would be blocked
> as well ;-)
>
> Also, some (most) desktop clients do not require you to login via OAuth,
> but instead they use xAuth. I'm sorry that you will no longer be able to
> play the silly quizzes etc, but you'll just have to live with that :-)
>
> Tom

[twitter-dev] Re: OAuth and impact on Twitter userbase / volume

[TheGuru]

And, just to clarify, I am referring to web based api applications,
where are many, all if which are affected, as xAuth is NOT,
apparently, and option in this type of setup.

On Aug 13, 8:54 am, Tom van der Woerdt  wrote:
> On 8/13/10 4:31 AM, TheGuru wrote:
>
>
>
> > I'm curious to post this question to see if Twitter has fully thought
> > out the impact of forcing OAuth onto their API applications.  While it
> > may appear to be a more secure method preferred in principle by users,
> > the fact of the matter is that one of the main benefits of the API, is
> > the ability for third party twitter alternatives to be created, thus
> > allowing people to tweet during "business hours", when they normally
> > could not due to firewall / web sense restrictions, etc, that prevent
> > them from accessing the twitter.com domain.
>
> > Via basic authentication, users would never have to visit twitter.com
> > to login and gain access to twitter functionality via api clients.  By
> > shutting this down, you are now forcing ALL potential users to login
> > via twitter.com, many of which do not have access to this domain in
> > their workplace environment, thus excluding them from easily using
> > your service wholesale.
>
> > This can / will, I suspect, have significant impact on twitter usage /
> > volume, unless I am missing something and there is an alternative the
> > does not require them to directly access the twitter.com domain to
> > grant access.
>
> My opinion: if your boss does not allow twitter, then don't do it.
>
> Although I have to admit that your point is valid, except for one major
> flaw: if twitter.com was really blocked, then the API would be blocked
> as well ;-)
>
> Also, some (most) desktop clients do not require you to login via OAuth,
> but instead they use xAuth. I'm sorry that you will no longer be able to
> play the silly quizzes etc, but you'll just have to live with that :-)
>
> Tom

[twitter-dev] OAuth and impact on Twitter userbase / volume

[TheGuru]

I'm curious to post this question to see if Twitter has fully thought
out the impact of forcing OAuth onto their API applications.  While it
may appear to be a more secure method preferred in principle by users,
the fact of the matter is that one of the main benefits of the API, is
the ability for third party twitter alternatives to be created, thus
allowing people to tweet during "business hours", when they normally
could not due to firewall / web sense restrictions, etc, that prevent
them from accessing the twitter.com domain.

Via basic authentication, users would never have to visit twitter.com
to login and gain access to twitter functionality via api clients.  By
shutting this down, you are now forcing ALL potential users to login
via twitter.com, many of which do not have access to this domain in
their workplace environment, thus excluding them from easily using
your service wholesale.

This can / will, I suspect, have significant impact on twitter usage /
volume, unless I am missing something and there is an alternative the
does not require them to directly access the twitter.com domain to
grant access.

[twitter-dev] Re: Lists API for Subscriptions

[TheGuru]

+1

Looking to integrate lists into my application as well, and have been
beating my head into the wall trying to figure out how to get all
lists subscribed in a single call, both user created (public or
private) and subscribed to.  Right now, it seems the only way is
through multiple calls.

On Nov 7, 7:06 pm, "dean.j.robinson" 
wrote:
> +1
>
> I've just started adding Lists to Hahlo.com and found this same thing.
>
> Based on the description in the docs I was expecting:
>
> /user/lists.format to be just the lists the user created
> /user/lists/subscriptions.format to be the lists the user created +
> those they are following (as it is on twitter.com), not just the ones
> they are following
>
> any chance of getting a combined my lists + lists I follow (or
> changing the /subscriptions response) to eliminate the need for
> multiple API calls?
>
> On Nov 2, 4:27 am, Eric Woodward  wrote:
>
> > Thanks for that. It would be great to combine them and reflect
> > ownership in the response data set. This requires two API calls for
> > what will be requested each time to show both sets together, which you
> > on twitter.com. I assume others will tend to show both sets at the
> > same time as well.
>
> > --ejw
>
> > Eric Woodward
> > Email: e...@nambu.com
>
> > On Oct 31, 3:01 pm, twittelator  wrote:
>
> > > Whoops - what I meant to say was:
>
> > > :user//lists/subscriptions.:format
>
> > > will get the lists a user has subscribed to
>
> > > Andrew Stone
> > > Twitter / @twittelatorhttp://www.stone.com
> > > got iPhone?
> > >        http://tinyurl.com/twitpro
> > >        http://tinyurl.com/intentionizer
> > >        http://tinyurl.com/gesture-buy
> > >        http://tinyurl.com/igraffiti
> > >        http://tinyurl.com/talkingpics
> > >        http://tinyurl.com/mobilemix
> > >        http://tinyurl.com/soundbite
> > >        http://tinyurl.com/icreated
> > >        http://tinyurl.com/pulsar-app
>
> > > On Oct 30, 5:52 pm, Eric Woodward  wrote:
>
> > > > Anyone seeing an issue with a method to get a list of a user's list
> > > >subscriptions? The following:
>
> > > > curl -u ejwc:[password] "http://twitter.com/ejwc/lists.xml";
>
> > > > only returns the three test lists that I have created, while the same
> > > > URL on Twitter's website:
>
> > > >https://twitter.com/ejwc/lists
>
> > > > returns my three test lists, and the 5+ lists I am following.
>
> > > > Any suggestions? I have only just started getting a response for the
> > > > API methods in the last day or so and only getting familiar with them.
> > > > Any help would be appreciated.
>
> > > > --ejw
>
> > > > Eric Woodward
> > > > Email: e...@nambu.com