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
On Mar 16, 10:56 pm, jwinkle jameswin...@gmail.com wrote:
For Facebook...network people together to share pics and relationship
status. You could probably make facebook server code OSS...it's the
existing network in-place that keeps people there...it was first and it has
a brand.
Actually
I have a set of apps that basically just reproduces the official
Twitter user experience, exactly what Twitter says we should not do.
However, I add value by running on a platform that Twitter does not
support and is unlikely to ever support. I believe this should be
allowed and encouraged and
On my Android phone I have both the official Twitter client and
Twidroid installed. If they had more or less the same functionailty
and useability I would prefer to use the official client. However I
only use Twidroid, because Twitter's official app is inferior. I
could explain why in detail if
On Mar 13, 2:23 pm, Raffi Krikorian ra...@twitter.com wrote:
if you are building a regular timeline client, we're going to be
holding you to a higher bar.
That is reasonable. However we have to wonder if Twitter's people
will/can be fair in applying this standard to 3rd party clients whose
The #newtwitter direct message UI sucks.
- There's no indication on the main UI that you have an unread
message. If you miss the email notification you will never notice the
message.
- On the DM page, there's no indication of which conversations have
unread messages, or even the most recent
Twitter's official Android app is obviously using OAuth, since it
still works. So why does it ask for my password? Isn't it supposed to
send me to a web page where I can click Ok? What is going on behind
the scenes here?
Maybe just some leftover Basic Auth code that hasn't been deleted
yet? If
On Aug 31, 12:46 pm, Matt Harris thematthar...@twitter.com wrote:
Like many mobile applications Twitter for Android uses xAuth. In this
mode the user enters their username and password which is then sent to
Twitter for the OAuth credentials. Part of the agreement of granting
access to xAuth
On Aug 9, 7:44 am, Tom allerleiga...@gmail.com wrote:
If you use some kind of server-side proxy, you still have the same
issue, because you also have to identify your application to your own
server - which anyone can do, no matter how good the encryption is.
Yes, anyone who uses your
On Aug 7, 10:52 am, @epc epcoste...@gmail.com wrote:
What's the approved open source solution to this problem?
You don't have to make it a full-fledged web app as Ed Borasky says.
You can also use a server-side proxy that holds your API keysecret
and signs API calls. Of course this means all of
-source apps like this.
When that becomes available I'll check it out and see if it solves
this.
---
Jef
Jef Poskanzer j...@mail.acme.com http://acme.com/jef/
On Jul 5, 10:52 am, Decklin Foster deck...@red-bean.com wrote:
There is also Curlicue, which I've written:
http://github.com/decklin/curlicue
Ooo a sh script! Very nice.
On Jul 2, 6:59 am, John Kalucki j...@twitter.com wrote:
FWIW: They are tweets. A twit is something else.
So why isn't the company app called Tweeter?
You're right in theory that requests after the initial authentication
step should not really need the app's credentials, a single
authentication token secret ought to suffice and the service
(twitter) should remember which app each token came from. But shrug,
that's just not the way OAuth works.
My app page at http://twitter.com/oauth_clients/details/n says I
should use:
http://twitter.com/oauth/request_token
http://twitter.com/oauth/access_token
http://twitter.com/oauth/authorize
However the OAuth at Twitter page at
http://dev.twitter.com/pages/auth#at-twitter
says to use https
Yeah, what Ryan said.
Also,
On Jun 13, 1:40 pm, segphault ryankp...@gmail.com wrote:
Facebook and Google Buzz both offer desktop-appropriate OAuth
authentication flows which do not require a consumer secret key and do
not require the user to go through a complicated copy/paste process.
I'm
I don't understand why you are suggesting this only for open source
programs. Were you thinking that an attacker would be incapable of
decompiling an executable and extracting the secret?
obfuscate your code (compiling, or intentional obfuscation)
So OAuth's security is based on obscurity? That's pretty lame.
On Jun 12, 10:16 am, Taylor Singletary taylorsinglet...@twitter.com
wrote:
(This is the other side of the coin.. on one side of the coin you have the
advantage that OAuth applications keep working even if the user changes
their password (YAY!) and then you have on the side of the coin that
On Jun 12, 11:49 am, Bernd Stramm bernd.str...@gmail.com wrote:
secure against what?
The threat that OAuth's security-through-obscurity fails to protect
against is rogue-app B doing something bad while using legit-app A's
stolen credentials. The author of app A gets blamed for app B's bad
You know, it's right there in the OAuth RFC.
http://tools.ietf.org/html/rfc5849#section-4.6
4.6. Secrecy of the Client Credentials
In many cases, the client application will be under the control of
potentially untrusted parties. For example, if the client is a
desktop application with
For my command-line twitter applications there is no third party, just
the end-user and twitter. Basic Auth + https would be just fine for
that.
Have you considered keeping basic auth enabled, but only for https?
This would be secure against packet sniffing and would probably use
less resources than OAuth.
Twurl is just what I need, a command-line OAuth getter. Except it's
written in a language I don't have so it's useless to me.
Before turning off basic auth twitter needs to provide their own
official implementation of a CLI OAuth getter, written in plain old C.
So how long until status ids reach 4294967296, breaking the apps that
were fixed today by changing signed to unsigned? Taking twitter's
growth rate into account I think it's less than a year away.
---
Jef
On Jun 12, 2:05 pm, J. Adam Moore jadammo...@gmail.com wrote:
Got it. Use Java's BigInteger class for all the ID fields and don't
look back. :)
Actually the easiest solution is to leave the status ids as strings.
That's what I do in my three homebrew twitter clients and they are
working just
26 matches
Mail list logo