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 API Wiki
Matt is this header in yet I haven't seen any announcements elsewhere
On May 19, 4:17 pm, themattharris thematthar...@twitter.com 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
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
Hi Frank,
do you now understand my slightly provoking question about
TweetDeck? ;-)
Ole
On May 19, 11:46 pm, Frank Ash nut...@gmail.com 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
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 s...@mobileways.de wrote:
HiMark,
I am still having the same
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
On May 19, 5:11 pm, TheGuru jsort...@gmail.com 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
@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 nut...@gmail.com wrote:
That would be much better cartmatrix but either way, its a
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
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
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
+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
On May 18, 1:01 pm, Matt Harris thematthar...@twitter.com 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
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
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
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
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
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
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.
--
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.
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 jsort...@gmail.com wrote:
That is to be expected regarding the 401.
However, while I see the changes on
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 mark.pavli...@gmail.com wrote:
TheGuru,
I set my app to RWPM permission at dev.twitter.com/apps and now it
displays as such on the
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, xAuth
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
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 chose
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
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
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?
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
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
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).
*
-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 that is the way the system is currently built, but it
doesn't have
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'
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 thematthar...@twitter.com wrote:
Hey everyone,
We
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
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
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
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
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 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
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 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
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
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 11:37 AM, Jon Colverson jjc1...@gmail.com 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
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
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
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 jazzyc...@gmail.com wrote:
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
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
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
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
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 as
53 matches
Mail list logo
