Basic auth credentials garbled after DELETE request
Mika Tuupola
I am not sure whether this is Sinatra or Rack::Auth::Basic issue. However I noticed that basic auth credentials get garbled after doing a DELETE request. I can reproduce this with Thin, Shotgun (Mongrel) and Passenger. I have tested with Sinatra 1.1.0, Rack 1.2 and ruby 1.8.7 (one provided with OSX and REE 2010.02 on CentOS 5).
Example code which reproduces the problem:
https://gist.github.com/874847
Run the app. Open the page. Login with test and test. Reload a few times. Page loads fine. Then make DELETE request by clicking the button. Now when you reload it asks for username and password again. If you check the logs you can see credentials are now broken.
--
Mika Tuupola
http://www.appelsiini.net/
Mika Tuupola
On Mar 17, 2011, at 9:04 PM, Mika Tuupola wrote:
> I am not sure whether this is Sinatra or Rack::Auth::Basic issue. However I noticed that basic auth credentials get garbled after doing a DELETE request. I can reproduce this with Thin, Shotgun (Mongrel) and Passenger. I have tested with Sinatra 1.1.0, Rack 1.2 and ruby 1.8.7 (one provided with OSX and REE 2010.02 on CentOS 5).
This is Safari issue and not related to the HTTP verb nor Sinatra. I sniffed the headers with tcpdump and found out Authorization header breaks after browser gets 302 redirect and you do a reload. For those who interested test case and header dumps at:
https://gist.github.com/874847
Matt Todd
--
You received this message because you are subscribed to the Google Groups "sinatrarb" group.
To post to this group, send email to sina...@googlegroups.com.
To unsubscribe from this group, send email to sinatrarb+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sinatrarb?hl=en.
--
Matt Todd
Highgroove Studios
www.highgroove.com
cell: 404-314-2612
blog: maraby.org
Scout - Web Monitoring and Reporting Software
www.scoutapp.com
Mika Tuupola
On Mar 19, 2011, at 11:55 PM, Matt Todd wrote:
> I saw this the other day somewhere totally unrelated. Thanks for sharing your findings!
As a sidenote. Apache seems to recover from the broken header and does not ask for the password again. Rack based applications will ask for password again. Have not tested with other webservers. Also filed a bug about this:
https://bugs.webkit.org/show_bug.cgi?id=56716