Hi Matt, I can see why it's done this way. The javascript code for adding credentials to the header is straight-forward and works fine. I don't do much http programming, so this was all new to me, but it would be nice if the api docs reflected what kind of authentication is required -- forced or passive.
Thanks, Jonas On Jun 22, 11:08 am, Matt Sanford <[email protected]> wrote: > Hi Jonas, > > The issue here is that /users/show allows both authenticated and > un-authenticated access. Unlike the bug you referenced [1], the RFC > does not really mention what to do in that case to my knowledge. For > resources that require authentication we respond with a 401, and the > browser prompts for a username/password and re-sends and authenticated > request. In the case of /users/show we return valid data when not > authenticated so the browser does not bother. > In most programming languages/libraries there is an option to > preemptively authenticate, or you can manually add the Authorization > header. Someone has even done this in Javascript [2], albeit in XUL > since it lacks a cross-domain security issue. > > Thanks; > – Matt Sanford / @mzsanford > Twitter Dev > > [1] -http://code.google.com/p/twitter-api/issues/detail?id=135 > [2] -http://groups.google.com/group/twitter-development-talk/browse_frm/th... > > On Jun 19, 2009, at 8:21 PM, Jonas wrote: > > > > > When I send incorrect credentials with a user/show.json command I > > expect to get a 401 code from twitter. However, when I do this from a > > browser using xmlhttprequest I get 400 instead. Actually, for the > > first 100 tries I get 200 codes, and there after I get 400 codes, > > because there is a rate limit of 100 per hour. The point is, at no > > time does authentication ever occur. > > > Could this be a bug in twitter? > > > As this post explains > > >http://groups.google.com/group/twitter-development-talk/browse_thread... > > > the RFC dictates that the browser does not send credentials until it > > first receives a 401. > >
