Hi,
In building out our Android and iPhone app we are in need of a
seamless way for users to auth with Twitter and make it possible for
us to Auto-Share for them if they choose. With the http auth going
away we are looking for guidance on best practices here. We would love
to see something like th
Hi All,
I still think that it is reasonable to think about this.
Is there anyone from twitter doing something about it?
Thanks.
On May 4, 9:25 am, twittme_mobi wrote:
> Hello Raffi,
>
> Could you please, get back to us on this?
> Do you have any plans on resolving that issue?
> Is there any sho
Hello Raffi,
Could you please, get back to us on this?
Do you have any plans on resolving that issue?
Is there any show stopper?
What are we doing with this?!
Thanks.
On Apr 29, 12:07 pm, Raffi Krikorian wrote:
> hi.
>
> i'll follow up on this - do you have a notion of what browsers, what phon
Hello,
I would agree with bob.hitching - let's take a general approach.
It is obvous that the OAuth twitter login page is not mobile optimized
so, rather than going and asking everyone
what phone you have and then trying to fix it for that phone - why
don't you just follow the best practice for mo
On Apr 30, 5:52 pm, "bob.hitching" wrote:
> At Xumii we’re using Twitter mobile oAuth on a wide range of phones,
> from low-end feature phones to high-end smartphones. A recent QA cycle
> revealed 7 out of 30 Most Popular devices not coping with Twitter
> mobile oAuth: Samsung C3110, Nokia 3120, S
Hi Raffi and everyone,
Firstly, Twitter is doing better than some other oAuth pages I could
mention..!
At Xumii we’re using Twitter mobile oAuth on a wide range of phones,
from low-end feature phones to high-end smartphones. A recent QA cycle
revealed 7 out of 30 Most Popular devices not coping w
Can you let us know the current supported User Agents? That way I can
direct our users to it if I am certain their phones are supported.
Thanks
T
On Feb 6, 4:39 am, Ryan Sarver wrote:
> Ill talk with the team and figure out if it's better to roll it back or just
> limit it to the known, workin
And for QA, if you're not able to procure each commercially available
handset, check out www.deviceanywhere.com. Or if you prefer to
outsource, hit me up off list, I can give you a list of reputable
mobile QA houses.
On Feb 6, 2010, at 7:40 AM, Dewald Pretorius wrote:
Ryan,
Don't know
Ryan,
Don't know if it will fit in with your architecture, but maybe this
service could be of use to you:
http://wapple.net/
On Feb 6, 12:39 am, Ryan Sarver wrote:
> Ill talk with the team and figure out if it's better to roll it back or just
> limit it to the known, working user agents
>
> On
Ill talk with the team and figure out if it's better to roll it back or just
limit it to the known, working user agents
On Fri, Feb 5, 2010 at 3:42 PM, CharlesW wrote:
> That's an amazingly great recommendation, Michael.
>
> -- Charles
>
> On Feb 5, 9:22 am, Michael Steuer wrote:
> > In fact, I
That's an amazingly great recommendation, Michael.
-- Charles
On Feb 5, 9:22 am, Michael Steuer wrote:
> In fact, I'd recommend that you only show the new version for devices you
> have actually tested against... Mobile browser support is a crap shoot and
> you really can't assume that something
In fact, I'd recommend that you only show the new version for devices you
have actually tested against... Mobile browser support is a crap shoot and
you really can't assume that something that works on one device, works on
another... You need to test each and every one of them (or at least each
fam
Ryan,
Thanks for both the attempted fix and the announcement.
Unfortunately, where the previous version was kind of a crapshoot for
mobile users because the buttons appeared black (see my screenshot in
the bug report at http://code.google.com/p/twitter-api/issues/detail?id=395),
this new version
Following up on my earlier email. I jumped the gun and the rollback never
actually happened :)
However, we are getting some reports of the buttons not functioning in a
number of browsers and are working on a fix.
Best, Ryan
On Thu, Feb 4, 2010 at 3:27 PM, Ryan Sarver wrote:
> We've had to roll
Buttons are non-clickable on Nokia 6300. This will be teh same for all
Nokia Series 40 browsers.
On Feb 5, 10:27 am, Ryan Sarver wrote:
> We've had to roll back the mobile OAuth update as it was consuming an
> abnormally large amount of resources. We'll dig in and figure out what was
> going on.
We've had to roll back the mobile OAuth update as it was consuming an
abnormally large amount of resources. We'll dig in and figure out what was
going on.
Almost there, rs
On Thu, Feb 4, 2010 at 12:24 PM, Carlos wrote:
> Buttons not clickable on Windows Mobile; tried on both a 6.1 & 6.5
> devic
Buttons not clickable on Windows Mobile; tried on both a 6.1 & 6.5
device.
On Feb 3, 6:16 pm, Ryan Sarver wrote:
> FINALLY!
>
> An update has just gone live that fixes rendering of the OAuth screens for
> most mobile devices. We also fixed a few small nagging things like the
> default action is n
Buttons *NOT* clickable on BlackBerry Bold Browser (OS4.6).
Have tried with and without Javascript enabled.
Can provide headers etc if needed.
Thanks for this update - it looks amazing. Should really ramp up
security & usability.
On Feb 3, 11:16 pm, Ryan Sarver wrote:
> FINALLY!
>
> An update
Rocks!
On Feb 3, 5:16 pm, Ryan Sarver wrote:
> FINALLY!
>
> An update has just gone live that fixes rendering of the OAuth screens for
> most mobile devices. We also fixed a few small nagging things like the
> default action is now "allow" instead of deny if you just hit "go" on an
> iPhone. I've
this broke my code - in case anyone needs it and didn't notice, the
oauth element id changed from 'oauth_pin' to 'oauth-pin'.
On Feb 3, 4:56 pm, Will Fleming wrote:
> It is working correctly on a G1 running Android, but getting the non mobile
> version on a Nexus One. User-Agent is
>
> *Mozilla/5
It is working correctly on a G1 running Android, but getting the non mobile
version on a Nexus One. User-Agent is
*Mozilla/5.0 (Linux; U; Android 2.1; en-us; Nexus One Build/ERD79)
AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Mobile Safari/530.17*
'oauth_pin' element id got changed to 'oauth-pin' for anyone else
who's stuff broke
On Feb 3, 3:53 pm, Fernando Olivares wrote:
> I've started testing it and it looks good. One comment, though. Is
> there any chance to move the PIN above the instructions?
Did the element id change? I was using this piece of code (iphone) to
get the oauth_id, and it's no longer working since around when these
new changes got pushed -
NSString*authPin = [[_webView
stringByEvaluatingJavaScriptFromString:
@"document.getEl
I've started testing it and it looks good. One comment, though. Is
there any chance to move the PIN above the instructions?
Thank you so much. This looks much better.
On Feb 3, 4:16 pm, Ryan Sarver wrote:
> FINALLY!
>
> An update has just gone live that fixes rendering of the OAuth screens for
> most mobile devices. We also fixed a few small nagging things like the
> default action is now "allow" instead of deny if y
ZOMG *faints*
one small nit: the redirect back to the app seemed to take longer than
it should. not sure what the redirect timeout is, but it might do well
to shorten it up by a second or two... otherwise ppl might start to
get click-happy while nothing is happening.
-Chad
On Wed, Feb 3, 2010 at
thank you x1000
This is great and works well too!
On Feb 3, 11:25 pm, Swap wrote:
> w0t! :D
w0t! :D
Hi Jim,
any news on that?How close are you to address this?
Thanks.
On Sep 7, 9:54 am, "jim.renkel" wrote:
> I've opened a feature request for this in the issues database:
>
> http://code.google.com/p/twitter-api/issues/detail?id=1011
>
> If you like this idea and / or think it's a good thing,
I've opened a feature request for this in the issues database:
http://code.google.com/p/twitter-api/issues/detail?id=1011
If you like this idea and / or think it's a good thing, please
indicate your support both here and in the issues forum.
If you don't like it and / or don't think it's so hot
advantage to this alternative is it reduces by
> one the number of API calls needed.
>
> I believe either of these alternatives is a viable solution for the
> circumstances where the existing OAuth implementation does not work so
> great.
>
> Comments expected and welcome.
>
o:twitter-development-t...@googlegroups.com] On Behalf Of
twittme_mobi
Sent: Friday, September 04, 2009 08:39
To: Twitter Development Talk
Subject: [twitter-dev] Re: Mobile oAuth
I am also interested in mobile oath solution.
twitter guys should think of something before deprecating basic auth
I am also interested in mobile oath solution.
twitter guys should think of something before deprecating basic auth
On Aug 20, 8:01 am, Cameron Kaiser wrote:
> > I have a mobile based twitter client in the field and have implemented
> > oAuth for this client. Some of the devices are either very l
> I have a mobile based twitter client in the field and have implemented
> oAuth for this client. Some of the devices are either very low memory
> or have primitive browsers that dont support the rendering of the
> 'allow' / 'deny' access page ( http://twitter.com/oauth/authorize ). I
> have tried
34 matches
Mail list logo
