Matt,
A question about the error being returned. You wrote that when you
throw a 403 it will be in the format:
{"errors":[{"code":93,"message":"This application is not allowed to
access
or delete your direct messages"}]}
Rather than the traditional twitter format, as documented in the
Twitter A
Arnaud replied recently indicating that the header is now in:
"We just started to return the "X-Access-Level" header for
authenticated API requests, that tells you what access level the user
token has"
http://groups.google.com/group/twitter-development-talk/browse_thread/thread/5bf53b81f2d868c/87
Matt is this header in yet I haven't seen any announcements elsewhere
On May 19, 4:17 pm, themattharris wrote:
>
> > How do we know what the access level of a user token is?
>
> This is a great idea and one the team has discussed. What we are going
> to do is add a newheaderto authentication requ
According to Matt's response above "When the website is busy, it can
take a
little bit longer for changes to your application to be reflected." If
you still haven't see then change try setting it again.
On May 19, 4:45 pm, janole wrote:
> HiMark,
>
> I am still having the same problem like TheGur
Hi Frank,
do you now understand my "slightly provoking" question about
TweetDeck? ;-)
Ole
On May 19, 11:46 pm, Frank Ash wrote:
> Yes janol, everything but twitters official apps will fail. This is
> specifically aimed at client apps. It is a way to specifically Target client
> apps because i
Hello.
Because the OAuth flow of twitter.com cannot be used from the Web based
client for
the Japanese mobile phone that we are providing, XAuth is used.
(I get permission in your support.)
The following problems occur if it accesses the OAuth flow from the cellular
phone
of a major career of Ja
I noticed this as well. When I did that, I thought maybe that meant
everyone would be grandfathered in, but from reading this thread I do
not think that is the case.
This also makes it difficult for us to troubleshoot this with our
users since we won't know if they have the old token or the new
t
@rsarver made it very clear in some recent tweets that Twitter's apps
will not be subject to the new OAuth requirements as they are part of
the 'service' not 3rd party offerings.
On May 19, 6:59 pm, Frank Ash wrote:
> That would be much better cartmatrix but either way, its a negative and
> unn
On May 19, 5:11 pm, TheGuru wrote:
> I'm not sure I was aware of the fact there were 2 OAuth login flows,
> "web flow" versus "sign in with Twitter".
Same here. Looks like I was using /authorize already though.
> What are the implications / reasons for using one method over the
> other? They s
opment-talk@googlegroups.com
Subject: Re: [twitter-dev] Re: A new permission level
Matt Harris said:
>> Why are permissions attached to the user token?
>> Permissions are attached to the user token to ensure an application
only has the access a user has authorised.
Only because t
Matt Harris said:
*>> Why are permissions attached to the user token?
>> Permissions are attached to the user token to ensure an application only
has the access a user has authorised.
*
Only because that is the way the system is currently built, but it doesn't
have to be that way (see: Facebook).
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 /aut
Hi Frank,
> Think about the normal person that uses tweetdeck. They will load the all,
> see nothing, and think its broken.
will the new policy be applied to all clients - even TweetDeck Mobile?
Ole
--
Twitter developer documentation and resources: https://dev.twitter.com/doc
API updates via
Hi Mark,
I am still having the same problem like TheGuru. I've created a new
app with RWPM and modified an old app. Both still show as "... not be
able to: Access your private messages."
How did you manage to get it to work?
Ole
On May 19, 8:13 pm, Mark Pavlidis wrote:
> TheGuru,
> I set my ap
Hi Matt,
thanks for the follow-up. I've still got some questions ... ;-)
> > Can Read/Write applications send direct messages?
>
> Yes. Read/Write tokens can send direct messages using direct_messages/
> new.
Does this mean xAuth applications can still send direct messages but
not read them?
>
I could not agree more! I was about to write the same when I saw this
message.
I do not mind changing the Read/Write on my apps page. I do not even
mind
having to change my app to allow 'Re-connect' to re-authenticate. Even
though it is
a pain (but it is done at least).
I DO mind now having to li
Hey everyone,
There has been some really great discussion and questions since the
last set of answers. I've responded to the ones we seen since last
night below.
> Can Read/Write applications send direct messages?
Yes. Read/Write tokens can send direct messages using direct_messages/
new.
The en
Ole-
You make some very good points, but you can't use the tired "users create poor
passwords" argument as a reason to stick with outdated security protocols. By
that logic, no security upgrade is worth the time because some dumb users are
going to foil you every time.
If a user wants to chos
I've also been trying to figure this out. Could someone from Twitter maybe
respond?
My assumption is that it will stay in this state until they activate it. Is
this right, or do we have to pass an extra permission parameter?
Sent from my iPod
On 19 May 2011, at 19:04, TheGuru wrote:
> That i
Hi Damon,
> None, taken. I am a network sysadmin, developer and ultimately businessman so
> I do know a little bit about how they are all related.
Cool, so we have exactly the same background :-)
> I understand you are in a slightly different position having to deal with
> xAuth. However, xAut
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 o
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 p
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.
D
It will be interesting to see where the PR nightmare falls more squarely on
when it happens... Twitter or the app developers themselves. We will get the
tech support nightmare but if recent history is any indication (ie. Ubertwitter
ban) many users are going to ultimately blame Twitter.
--
d
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 ap
Users do not need protection from their personal mobile Twitter
clients any more than they do from their browsers. It's their app
running on their device accessing their account at their direction.
Requiring separate authentication for DMs for a mobile client app is
like requiring separate cars ke
If you're a developer who got bit in the ass by this move by Twitter,
and need to migrate your application from using xAuth to using OAuth,
I have a sample project which shows you how to obtain authorization
for a user. It's Objective-C, but the concepts should be applicable to
whatever language yo
Janole
None, taken. I am a network sysadmin, developer and ultimately businessman so I
do know a little bit about how they are all related.
I understand you are in a slightly different position having to deal with
xAuth. However, xAuth is not a secure system in itself. Any system that passes
a
Damon,
with all due respect and in all politeness, have you even read what
this thread is about?
Do you really think an xAuth application - that knows the users full
credentials - is getting more secure without the right to access
direct messages? I mean ... really ;-)
We both do not know why Tw
Thanks for the info Matt. It is much appreciated.
However, you guys really need to stop doing this type of stuff. The
war on client apps is getting a bit out of control. They grow the
twitter userbase, and dev's helped make twitter what it is and sustain
its growth by offering many different ways
On May 18, 1:01 pm, Matt Harris wrote:
> 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
I have created a new app as a test, with the new permission level. In the
OAuth dialog it still explicitly states that the app will not be able to
read or send DM's. My guess is that I either have to specify the permission
level with a variable, or that it is not enabled yet.
Any ideas which it is
+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 M
For some developers it's not just a pain in the you know what, it's a
case of it simply not working. @janole explained how it just doesn't
work with symbian. For me, and adobe air app, it's a pain, but we can
get over the inconvenience - although it's always nice to have a bit
more time. I think 8
In any security or permissions context the default should be the most secure
and least amount of permissions to get the job done. That is Computer and
Network Security 101.
A user must explicitly configure more loose permissions on their own after
understanding the implications. This is the wa
Hey everyone,
The sad reality is that the way it's being taken in the news is that
"twitter is doing this because developers have been abusing their
privacy." We know this is not the case, we know we just need access
them to provide them the feeds that they WANT to see, by virtue of the
fact that
Hi Matt,
just another tought:
Wouldn't it be possible to keep the DM access rights with xAuth and
only revoke it upon users complaints or your monitoring of API usage?
If I remember correctly, Twitter said they are revoking hundreds of
API clients per day, so it seems like this approach is worki
Hi Matt,
thanks for your feedback. I think the following paragraph can't be
generalized, though:
> > Why will you not grandfather existing applications into DM access?
>
> Grandfathering all existing read/write tokens assumes they all wanted
> access to DMs. The feedback we’ve had from users and
Thanks Matt,
Two important implementation questions that aren't 100% clear from
that announcement or any supporting docs at this point;
1) "we are also restricting this permission to the OAuth /authorize
web flow only"
To be clear, does this include using the OAuth "/authenticate" method
as well
> Please continue to send
> us your feedback about the permission model and what you would like to
> see it offer.
Why?
--
Twitter developer documentation and resources: https://dev.twitter.com/doc
API updates via Twitter: https://twitter.com/twitterapi
Issues/Enhancements Tracker: https://code.
Thanks Matt!
I still urge you to reconsider the mass breakage of older existing apps, and
crippling of the mobile/desktop app user experiences going forward.
My own judgement is that yes, maybe the user didn't realize that they didn't
want to give that level of access and maybe the web flow c
Thanks Matt!
I still urge you to reconsider the mass breakage of older and existing apps
and the crippling mobile/desktop user experiences apps going forward.
My own judgement is that yes, maybe user didn't realize that didn't want to
give that level of access and matbe the web flow can help
Hey everyone,
Thank you for all the feedback on the list, email and through Tweets.
We've been responding throughout the day to many of the Tweets but
wanted to group the questions together and respond here as well.
> Two weeks is not enough time to implement a web OAuth flow and have the app
>
Please exclude xAuth mobile clients from this, logically and from the
usability point of view, it doesn't make any sense, the user authorize my
app to use his account, why i ask for his authorization again to view his
Direct messages, why you insist on making our life very hard :(
--
Twitter
Matt,
This maybe a harder architectural shift, but a better solution would be to
move permissions from being per application, but instead a per
authentication token method, wherein that each token stores the permissions
that the app requested and was granted at the time they authorized.
So i
nevermind, i must have been out of the loop.. i was using the old form
so use http://dev.twitter.com/apps
and DO NOT USE http://twitter.com/apps (which, should be deleted or
auto-forwarded or something)
caramba,
-chad
On Wed, May 18, 2011 at 3:47 PM, Chad Etzel wrote:
> Aside from all the
Aside from all the emotional/philosophical stuff in this thread, I am
concerned about a major possible bug:
I have updated my apps to use Read/Write/DM permissions, and then it
saves it as Read-Only... I tried to change it back to just Read/Write,
and again it is saved as Read-Only.
Is anyone els
Quick question and a comment.
1) I see the new Default Access type as "Read, Write & Private
Message" not "Read, Write & Direct Messages." Is there a typo
somewhere?.
2) I just have to agree with everyone here that having all of our
users re-auth our app to give them access to a feature they've
On Wed, May 18, 2011 at 11:37 AM, Jon Colverson wrote:
>
> Also on the subject of granularity, it would be great if the app could
> request DM access but make it optional, such that users can turn it
> off on the authorization page. If the user declines it then the app
> would be able to ask them
The more I think about this, the less it makes any sense whatsoever to
force everyone through a re-authentication if DM access is required.
Here's why:
1) For existing user tokens, the users have already granted access
with the knowledge that it is to their DMs as well. In other words,
they have
On Wed, May 18, 2011 at 12:50:30PM -0700, Derek Gathright wrote:
>I agree with Scott. A token should simply be a bond between the user
>and the app, it should not contain any knowledge of
>permissions/restrictions. A token simply represents "Hi, I'm making a
>call on behalf of Joe
I agree with Scott. A token should simply be a bond between the user and
the app, it should not contain any knowledge of permissions/restrictions. A
token simply represents "Hi, I'm making a call on behalf of Joe User.
Attached is the request I want to make. Make sure I'm allowed to do this
befo
Hello,
There have been a lot of opinions voiced about how this is being implemented.
This not only proves troublesome for xAuth clients, but it lends me to worry
about how the future of permissions will evolve. Effectively now, every single
Twitter user needs to get their application re-authed
I had most of the same thoughts already mentioned in this thread so
wont reiterate everyone, except to add that this seems like a rather
sudden and disruptive change coming just after #devnestsf where
Twitter made a point that it was trying to provide better guidance so
companies that rely on the p
Hello.
For my app, it's inconvenient that the DM permission is only available
lumped in with the write permission, because now I have to request
both even though my app has no facility for posting (it's a
notification-only app), and I expect users will (rightly) be
suspicious about that.
Also on
I very much agree. To get xAuth, we all had to apply and undergo some
sort of verification process.
Also, if I take my app Gravity as an example, I am using xAuth (and
previously Basic Auth) since the very beginning and there have been
zero complaints from users that Gravity has been misusing the
Hi Matt,
I understand the change need to happen. In regards to xAuth though and
finding an upgrade path, the assumption is that those that got access to
that were developing desktop/mobile clients (not centralized services) so
there is no centralized storage of tokens or user data (only in stan
Matt,
Ultimately I understand the issues with xAuth and granularity. Frankly, if
you just ditched xAuth entirely, I can see decent arguments for it.
However, we've made a significant investment in the xAuth UX. If we have to
change it, 13 days is simply not sufficient for most devs. It will be
Matt,
If I understand correctly, activate the new permission, all Read and
Read/Write user_tokens issued to third-party applications will lose
their ability to read direct messages.
That is a HUGE and MAJOR headache for existing apps and their
thousands of users who are currently using any of the
Hi Matt,
can you please give us more time to adapt to this. It is impossible to
make the appropriate changes and submit to appstore within this
timeframe.
Thanks,
Ole, Gravity Twitter Client for Symbian
On May 18, 7:01 pm, Matt Harris wrote:
> Hey everyone,
>
> We recently updated our OAuth scr
"We know this will take some time so we are allowing a transition period
until the end of this month."
This is such a short timeframe for people to rebuild, QA and resubmit their
apps that it will certainly mean some peoples apps will stop working while
they are waiting for them to be 'approved
The new permissions level is welcomed by me and a good idea. Removing
the ability for xAuth to access DMs is insanity, pure and simple.
I presume your iOS and Mac clients will be switching off xAuth access
as well then?
On May 18, 6:19 pm, Jim Cortez wrote:
> Matt,
> You say:> This means ap
62 matches
Mail list logo