15214 0 true 2008-04-30T11:15:18-07:00 7654 2012-12-31T00:00:00-08:00 27724 16 patch-http-authentication 26 9779 resolved auth http patch 2009-12-12T16:30:14-08:00 17123 Ryan Tomayko Bjørn Arild Mæland Blake Mizerany http://sinatra.lighthouseapp.com/projects/9779/tickets/16 Future I needed HTTP auth for a simple web service I was creating, so I ported some code over from Rails. I guess this could be useful for others as well? :) Code: http://github.com/Chrononaut/sinatra/commits/master I needed HTTP auth for a simple web service I was creating, so I ported some code over from Rails. I guess this could be useful for others as well? :) Code: http://github.com/Chrononaut/sinatra/commits/master <div><p> I needed HTTP auth for a simple web service I was creating, so I ported some code over from Rails. I guess this could be useful for others as well? :) </p><p> Code: <a href="http://github.com/Chrononaut/sinatra/commits/master">http://github.com/Chrononaut/sin...</a> </p></div> 15214 0 I needed HTTP auth for a simple web service I was creating, so I ported some code over from Rails. I guess this could be useful for others as well? :) Code: http://github.com/Chrononaut/sinatra/commits/master <div><p> I needed HTTP auth for a simple web service I was creating, so I ported some code over from Rails. I guess this could be useful for others as well? :) </p><p> Code: <a href="http://github.com/Chrononaut/sinatra/commits/master">http://github.com/Chrononaut/sin...</a> </p></div> false 2008-04-30T11:15:18-07:00 7654 --- {} 9332 16 patch-http-authentication 0 9779 new 2008-04-30T11:15:18-07:00 7654 Bjørn Arild Mæland Bjørn Arild Mæland Blake Mizerany http://sinatra.lighthouseapp.com/projects/9779/tickets/16 0.3.0 Sammy 15214 0 oh snap. nice. thank you. I'll get this in a soon as I can. <div><p> oh snap. nice. thank you. I'll get this in a soon as I can. </p></div> false 2008-04-30T11:36:13-07:00 7654 --- {} 9332 16 patch-http-authentication 0 9779 new 2008-04-30T11:36:13-07:00 15214 Blake Mizerany Bjørn Arild Mæland Blake Mizerany http://sinatra.lighthouseapp.com/projects/9779/tickets/16 0.3.0 Sammy 15214 0 Wow. This is a lot more simple than I thought it would be. Good stuff, Chrononaut. Here's some food for thought: It might be worth investigating the use of <a href="http://rack.rubyforge.org/doc/classes/Rack/Auth/Basic/Request.html">Rack::Auth::Basic::Request</a>. It's not well documented so it might be best to dive into the Rack sources: here's <a href="http://github.com/chneukirchen/rack-mirror/tree/master/lib/rack/auth">a link to lib/rack/auth</a> on Rack's master. There's quite a bit of good, solid functionality in there. All you need to use it is to pass the Rack environment hash into a new Rack::Auth::Basic::Request object. From there, you have access to a few useful convenience methods: @@@ ruby auth = Rack::Auth::Basic::Request.new(@env) auth.provided? #=> true when authentication headers present auth.basic? #=> true when authentication type is basic auth.credentials #=> [ 'username', 'password' ] auth.username #=> 'username' @@@ Like I said, the implementation you've come up with is quite simple so using the Rack APIs isn't really buying much in this case. However, it's always a good idea to use what Rack gives us when possible, IMO. <div><p> Wow. This is a lot more simple than I thought it would be. Good stuff, Chrononaut. Here's some food for thought: </p><p> It might be worth investigating the use of <a href="http://rack.rubyforge.org/doc/classes/Rack/Auth/Basic/Request.html">Rack::Auth::Basic::Request</a>. It's not well documented so it might be best to dive into the Rack sources: here's <a href="http://github.com/chneukirchen/rack-mirror/tree/master/lib/rack/auth">a link to lib/rack/auth</a> on Rack's master. There's quite a bit of good, solid functionality in there. </p><p> All you need to use it is to pass the Rack environment hash into a new Rack::Auth::Basic::Request object. From there, you have access to a few useful convenience methods: </p> <pre><code class="ruby">auth = Rack::Auth::Basic::Request.new(@env) auth.provided? #=&gt; true when authentication headers present auth.basic? #=&gt; true when authentication type is basic auth.credentials #=&gt; [ 'username', 'password' ] auth.username #=&gt; 'username' </code></pre> <p> Like I said, the implementation you've come up with is quite simple so using the Rack APIs isn't really buying much in this case. However, it's always a good idea to use what Rack gives us when possible, IMO. </p></div> false 2008-05-02T15:13:23-07:00 7654 --- {} 9332 16 patch-http-authentication 0 9779 new 2008-05-02T15:13:23-07:00 17123 Ryan Tomayko Bjørn Arild Mæland Blake Mizerany http://sinatra.lighthouseapp.com/projects/9779/tickets/16 0.3.0 Sammy 15214 0 One thing that worries me a bit about this patch is that it adds some fairly generic method names to EventContext: #authenticate, #authorization, #username_and_password, #decode_credentials, etc. Seems like there's a good chance these are going to clash with app-specific helper methods or future authentication related code. I suppose we can deal with the latter when it comes up but the former seems worth preventing. For example, suppose someone has implemented form/session-based auth using a helper method named "authenticate": @@@ ruby helpers do def authenticate if session[:user].nil? ... end end end get '/admin' do authenticate ... end @@@ Wouldn't this cause problems? Seems like this type of thing could be avoided with some simple method renaming or pulling the code from within those methods up into the very-specifically named public methods. <div><p> One thing that worries me a bit about this patch is that it adds some fairly generic method names to EventContext: #authenticate, #authorization, #username_and_password, #decode_credentials, etc. Seems like there's a good chance these are going to clash with app-specific helper methods or future authentication related code. I suppose we can deal with the latter when it comes up but the former seems worth preventing. </p><p> For example, suppose someone has implemented form/session-based auth using a helper method named "authenticate": </p> <pre><code class="ruby">helpers do def authenticate if session[:user].nil? ... end end end get '/admin' do authenticate ... end </code></pre> <p> Wouldn't this cause problems? Seems like this type of thing could be avoided with some simple method renaming or pulling the code from within those methods up into the very-specifically named public methods. </p></div> false 2008-05-02T15:39:52-07:00 7654 --- {} 9332 16 patch-http-authentication 0 9779 new 2008-05-02T15:39:52-07:00 17123 Ryan Tomayko Bjørn Arild Mæland Blake Mizerany http://sinatra.lighthouseapp.com/projects/9779/tickets/16 0.3.0 Sammy 15214 0 Thanks for your feedback Ryan! Yes, I suspected Rack might have utility methods for this, but as you said the implementation turned out okay without them, so I didn't investigate further at that point. I agree with your view on using the Rack API as much as possible though, so I'll try to make them to use. On your second point: Rails solves this by placing the public and private methods into two separate modules, and only includes the public one into ActionController. I had something in mind here - I just forgot to do it. I'll fix this right now. <div><p> Thanks for your feedback Ryan! Yes, I suspected Rack might have utility methods for this, but as you said the implementation turned out okay without them, so I didn't investigate further at that point. I agree with your view on using the Rack API as much as possible though, so I'll try to make them to use. </p><p> On your second point: Rails solves this by placing the public and private methods into two separate modules, and only includes the public one into ActionController. I had something in mind here - I just forgot to do it. I'll fix this right now. </p></div> false 2008-05-03T02:48:43-07:00 7654 --- {} 9332 16 patch-http-authentication 0 9779 new 2008-05-03T02:48:43-07:00 7654 Bjørn Arild Mæland Bjørn Arild Mæland Blake Mizerany http://sinatra.lighthouseapp.com/projects/9779/tickets/16 0.3.0 Sammy 15214 0 Rack::Auth::Basic::Request made the implementation a whole lot cleaner. :) I suspect this could be taken even further, by utilizing Rack::Auth::Basic.new(app) during the application build. I think it will require storing the login procedure and realm name in Sinatra.options (or similar) though. I dropped it for now since I'm not sure if it's worth it. <div><p> Rack::Auth::Basic::Request made the implementation a whole lot cleaner. :) I suspect this could be taken even further, by utilizing Rack::Auth::Basic.new(app) during the application build. I think it will require storing the login procedure and realm name in Sinatra.options (or similar) though. I dropped it for now since I'm not sure if it's worth it. </p></div> false 2008-05-03T07:20:24-07:00 7654 --- {} 9332 16 patch-http-authentication 0 9779 new 2008-05-03T07:20:24-07:00 7654 Bjørn Arild Mæland Bjørn Arild Mæland Blake Mizerany http://sinatra.lighthouseapp.com/projects/9779/tickets/16 0.3.0 Sammy 15214 0 Awesome. Regarding Rack::Auth::Basic -- we'll be able to do this very easily once we get our pseudo builder support in. You'll be able to do something like the following right at the top-level of your sinatra file to get basic auth for the entire app: @@@ ruby use Rack::Auth::Basic do |username,password| password == 'secret' end @@@ <div><p> Awesome. </p><p> Regarding Rack::Auth::Basic -- we'll be able to do this very easily once we get our pseudo builder support in. You'll be able to do something like the following right at the top-level of your sinatra file to get basic auth for the entire app: </p> <pre><code class="ruby">use Rack::Auth::Basic do |username,password| password == 'secret' end </code></pre></div> false 2008-05-03T13:04:05-07:00 7654 --- {} 9332 16 patch-http-authentication 0 9779 new 2008-05-03T13:04:05-07:00 17123 Ryan Tomayko Bjørn Arild Mæland Blake Mizerany http://sinatra.lighthouseapp.com/projects/9779/tickets/16 0.3.0 Sammy 15214 0 Just wondering if there's anything else missing before this can be pulled upstream? <div><p> Just wondering if there's anything else missing before this can be pulled upstream? </p></div> false 2008-05-12T03:12:07-07:00 7654 --- {} 9332 16 patch-http-authentication 0 9779 new 2008-05-12T03:12:07-07:00 7654 Bjørn Arild Mæland Bjørn Arild Mæland Blake Mizerany http://sinatra.lighthouseapp.com/projects/9779/tickets/16 0.3.0 Sammy 15214 0 Chrononaut, My free time. ;) I'm wrapping a project at work and will pull soon. Thank you for your work! <div><p> Chrononaut, </p><p> My free time. ;) I'm wrapping a project at work and will pull soon. Thank you for your work! </p></div> false 2008-05-12T12:02:18-07:00 7654 --- {} 9332 16 patch-http-authentication 0 9779 new 2008-05-12T12:02:18-07:00 15214 Blake Mizerany Bjørn Arild Mæland Blake Mizerany http://sinatra.lighthouseapp.com/projects/9779/tickets/16 0.3.0 Sammy 15214 0 Ah, no problem. :) Btw I tried to clean up the history by rebasing all the small commits into a large one, but I got into some trouble (my git-fu is not that strong). Maybe you can clean it up on your part when you pull. It's not a big deal of course. <div><p> Ah, no problem. :) Btw I tried to clean up the history by rebasing all the small commits into a large one, but I got into some trouble (my git-fu is not that strong). Maybe you can clean it up on your part when you pull. It's not a big deal of course. </p></div> false 2008-05-16T02:22:32-07:00 7654 --- {} 9332 16 patch-http-authentication 0 9779 new 2008-05-16T02:22:32-07:00 7654 Bjørn Arild Mæland Bjørn Arild Mæland Blake Mizerany http://sinatra.lighthouseapp.com/projects/9779/tickets/16 0.3.0 Sammy 17123 0 false 2008-09-07T18:29:13-07:00 7654 --- :tag: :assigned_user: 15214 9332 16 patch-http-authentication 0 9779 new auth http patch 2008-09-07T18:29:18-07:00 17123 Ryan Tomayko Bjørn Arild Mæland Ryan Tomayko http://sinatra.lighthouseapp.com/projects/9779/tickets/16 0.3.0 Sammy 17123 0 Pushing to 0.4. I'd like to keep new features in 0.3.x to a minimum so that we're not burdening 0.4 with even more work for backward compatibility. <div><p>Pushing to 0.4. I'd like to keep new features in 0.3.x to a minimum so that we're not burdening 0.4 with even more work for backward compatibility.</p></div> false 2008-09-14T03:16:57-07:00 7654 --- :milestone: 9332 :state: new 16 patch-http-authentication 0 9779 open auth http patch 2008-09-14T03:17:56-07:00 17123 Ryan Tomayko Bjørn Arild Mæland Ryan Tomayko http://sinatra.lighthouseapp.com/projects/9779/tickets/16 17123 0 Sorry, moving to hoboken and putting on hold for now. <div><p>Sorry, moving to hoboken and putting on hold for now.</p></div> true 2008-12-30T02:45:16-08:00 7654 --- :milestone: 18496 :state: open 27290 16 patch-http-authentication 0 9779 hold auth http patch 2008-12-30T02:45:17-08:00 17123 Ryan Tomayko Bjørn Arild Mæland Ryan Tomayko http://sinatra.lighthouseapp.com/projects/9779/tickets/16 0.9.0 Hoboken 17123 0 false 2008-12-30T03:00:27-08:00 7654 --- :state: hold 27290 16 patch-http-authentication 0 9779 new auth http patch 2008-12-30T03:00:30-08:00 17123 Ryan Tomayko Bjørn Arild Mæland Ryan Tomayko http://sinatra.lighthouseapp.com/projects/9779/tickets/16 0.9.0 Hoboken 17123 0 false 2009-01-07T11:10:43-08:00 7654 --- :milestone: 27290 27725 16 patch-http-authentication 0 9779 new auth http patch 2009-01-07T11:10:47-08:00 17123 Ryan Tomayko Bjørn Arild Mæland Ryan Tomayko http://sinatra.lighthouseapp.com/projects/9779/tickets/16 0.9.1 17123 0 false 2009-01-17T16:48:02-08:00 7654 --- :milestone: 27725 27724 16 patch-http-authentication 0 9779 new auth http patch 2009-01-17T16:48:04-08:00 17123 Ryan Tomayko Bjørn Arild Mæland Ryan Tomayko http://sinatra.lighthouseapp.com/projects/9779/tickets/16 Future 0 false 2009-01-18T14:42:45-08:00 7654 --- :assigned_user: 17123 27724 16 patch-http-authentication 0 9779 new auth http patch 2009-01-18T14:42:50-08:00 17123 Ryan Tomayko Bjørn Arild Mæland http://sinatra.lighthouseapp.com/projects/9779/tickets/16 Future 0 Here's an implementation by foca that looks pretty good as well: http://github.com/foca/sinatra-diddies/blob/master/lib/diddies/authorization.rb Also, I like "authorize!" as the helper method name. Not sure where I saw it but I've been meaning to note that. <div><p>Here's an implementation by foca that looks pretty good as well:</p> <p><a href="http://github.com/foca/sinatra-diddies/blob/master/lib/diddies/authorization.rb"> http://github.com/foca/sinatra-d...</a></p> <p>Also, I like "authorize!" as the helper method name. Not sure where I saw it but I've been meaning to note that.</p></div> false 2009-01-25T00:15:50-08:00 7654 --- {} 27724 16 patch-http-authentication 0 9779 new auth http patch 2009-01-25T00:15:53-08:00 17123 Ryan Tomayko Bjørn Arild Mæland http://sinatra.lighthouseapp.com/projects/9779/tickets/16 Future 0 I'm not sure if this belongs in core. I'd like to keep it separate as a plugin. Keep the core lean and mean :) <div><p>I'm not sure if this belongs in core. I'd like to keep it separate as a plugin. Keep the core lean and mean :)</p></div> false 2009-01-25T13:01:56-08:00 7654 --- {} 27724 16 patch-http-authentication 0 9779 new auth http patch 2009-01-25T13:02:01-08:00 278 ronin-278 (at lighthouseapp) Bjørn Arild Mæland http://sinatra.lighthouseapp.com/projects/9779/tickets/16 Future 0 I'm definitely leaning toward keeping it out of core. It's not actually planned for a release but it seems to come up quite a bit in #sinatra. If we had a solid plugin/extension that we could point people to, I'd be willing to WONTFIX this. <div><p>I'm definitely leaning toward keeping it out of core. It's not actually planned for a release but it seems to come up quite a bit in #sinatra. If we had a solid plugin/extension that we could point people to, I'd be willing to WONTFIX this.</p></div> false 2009-01-25T16:15:29-08:00 7654 --- {} 27724 16 patch-http-authentication 0 9779 new auth http patch 2009-01-25T16:15:29-08:00 17123 Ryan Tomayko Bjørn Arild Mæland http://sinatra.lighthouseapp.com/projects/9779/tickets/16 Future 0 +1 for keeping it out of core, mainly because Rack gives us the functionality out of the box, as middleware: @@@ ruby use Rack::Auth::Basic do |username, password| username == 'foo' and password == 'bar' end @@@ Which covers all the cases where all of the app has to be password protected. I suspect you can check for the requested path or something to limit that. <div><p>+1 for keeping it out of core, mainly because Rack gives us the functionality out of the box, as middleware:</p> <pre><code class="ruby"> use Rack::Auth::Basic do |username, password| username == 'foo' and password == 'bar' end </code></pre> <p>Which covers all the cases where all of the app has to be password protected. I suspect you can check for the requested path or something to limit that.</p></div> false 2009-01-26T08:49:57-08:00 7654 --- {} 27724 16 patch-http-authentication 0 9779 new auth http patch 2009-01-26T08:49:59-08:00 11278 Harry Vangberg Bjørn Arild Mæland http://sinatra.lighthouseapp.com/projects/9779/tickets/16 Future 0 Harry: if it were that simple, I'd be in total agreement with you. The issue is that there's often a need to mark certain requests as requiring Auth and others not. Using the Rack::Auth::Basic middleware protects the entire app (or mapping area). <div><p>Harry: if it were that simple, I'd be in total agreement with you. The issue is that there's often a need to mark certain requests as requiring Auth and others not. Using the Rack::Auth::Basic middleware protects the entire app (or mapping area).</p></div> false 2009-01-26T11:04:33-08:00 7654 --- {} 27724 16 patch-http-authentication 0 9779 new auth http patch 2009-01-26T11:04:36-08:00 17123 Ryan Tomayko Bjørn Arild Mæland http://sinatra.lighthouseapp.com/projects/9779/tickets/16 Future 0 I've implemented an alternative way of specifying protected routes, which I think is a tad nicer than doing it in the block: @@@ ruby get '/sekret', :protect => 'admin:password' do # protected stuff goes here end @@@ It's in my fork here: http://github.com/nakajima/sinatra/tree/master. With that being said, I'm perfectly fine with this type of stuff not being built into core as well. <div><p>I've implemented an alternative way of specifying protected routes, which I think is a tad nicer than doing it in the block:</p> <pre><code class="ruby"> get '/sekret', :protect =&gt; 'admin:password' do # protected stuff goes here end </code></pre> <p>It's in my fork here: <a href="http://github.com/nakajima/sinatra/tree/master.%3C/p">http://github.com/nakajima/sinat...</a>&gt;</p> <p>With that being said, I'm perfectly fine with this type of stuff not being built into core as well.</p></div> false 2009-02-08T01:40:58-08:00 7654 --- {} 27724 16 patch-http-authentication 0 9779 new auth http patch 2009-02-08T01:40:59-08:00 5641 Pat Nakajima Bjørn Arild Mæland http://sinatra.lighthouseapp.com/projects/9779/tickets/16 Future 0 Yeah. This is perfect for an extension. We should have docs on that shortly and I'm hoping a lot of these Auth experiments will make there way into extensions available as gems. <div><p>Yeah. This is perfect for an extension. We should have docs on that shortly and I'm hoping a lot of these Auth experiments will make there way into extensions available as gems.</p></div> false 2009-02-17T08:51:50-08:00 7654 --- {} 27724 16 patch-http-authentication 0 9779 new auth http patch 2009-02-17T08:55:17-08:00 17123 Ryan Tomayko Bjørn Arild Mæland http://sinatra.lighthouseapp.com/projects/9779/tickets/16 Future 0 false 2009-03-02T20:06:49-08:00 7654 --- :milestone: 27724 31983 16 patch-http-authentication 0 9779 new auth http patch 2009-03-02T20:06:50-08:00 17123 Ryan Tomayko Bjørn Arild Mæland http://sinatra.lighthouseapp.com/projects/9779/tickets/16 0.9.2 0 sounds more like a plugin/extension to me since basic auth requires a clear-text copy of the password, so sinatra'd be promoting what is in essence a bad practice that said... if you do want to protect part of your application using Rack::Auth, you can always URLMap the secure and non-secure parts (and I know that doesn't take care of all cases) <div><p>sounds more like a plugin/extension to me since basic auth requires a clear-text copy of the password, so sinatra'd be promoting what is in essence a bad practice</p> <p>that said... if you do want to protect part of your application using Rack::Auth, you can always URLMap the secure and non-secure parts (and I know that doesn't take care of all cases)</p></div> false 2009-03-03T09:47:19-08:00 7654 --- {} 31983 16 patch-http-authentication 0 9779 new auth http patch 2009-03-03T09:47:20-08:00 17559 S. Brent Faulkner Bjørn Arild Mæland http://sinatra.lighthouseapp.com/projects/9779/tickets/16 0.9.2 0 Yeah. I agree this should be an extension but I'd still like to keep it as a task for us to consider as part of the 0.9.2 release. IMO, it would be good to have a few extensions that we maintain so that we're putting the extensions API through its paces. <div><p>Yeah. I agree this should be an extension but I'd still like to keep it as a task for us to consider as part of the 0.9.2 release. IMO, it would be good to have a few extensions that we maintain so that we're putting the extensions API through its paces.</p></div> false 2009-03-04T04:47:57-08:00 7654 --- {} 31983 16 patch-http-authentication 0 9779 new auth http patch 2009-03-04T04:47:58-08:00 17123 Ryan Tomayko Bjørn Arild Mæland http://sinatra.lighthouseapp.com/projects/9779/tickets/16 0.9.2 0 One more solution to this: <http://github.com/integrity/sinatra-authorization/tree/master> (avalaible on rubyforge BTW) Don't miss nakajima's nice sugar (not included in the gem ATM): <http://github.com/integrity/sinatra-authorization/blob/c503ccd2a8e5bddc816cc3dc237e58534ac1217a/test/authorization_test.rb#L29> <div><p>One more solution to this: <a href="http://github.com/integrity/sinatra-authorization/tree/master">http://github.com/integrity/sinatra-authorization/tree/master</a> (avalaible on rubyforge BTW)</p> <p>Don't miss nakajima's nice sugar (not included in the gem ATM): <a href="http://github.com/integrity/sinatra-authorization/blob/c503ccd2a8e5bddc816cc3dc237e58534ac1217a/test/authorization_test.rb#L29"> http://github.com/integrity/sinatra-authorization/blob/c503ccd2a8e5bddc816cc3dc237e58534ac1217a/test/authorization_test.rb#L29</a></p></div> false 2009-03-31T10:11:38-07:00 7654 --- {} 31983 16 patch-http-authentication 0 9779 new auth http patch 2009-03-31T10:59:39-07:00 11306 Simon Rozet Bjørn Arild Mæland http://sinatra.lighthouseapp.com/projects/9779/tickets/16 0.9.2 0 Warden looks interesting as well: http://github.com/hassox/warden/tree/master <div><p>Warden looks interesting as well:</p> <p><a href="http://github.com/hassox/warden/tree/master">http://github.com/hassox/warden/...</a></p></div> false 2009-04-25T09:27:25-07:00 7654 --- :milestone: 31983 27724 16 patch-http-authentication 0 9779 new auth http patch 2009-04-25T09:27:28-07:00 17123 Ryan Tomayko Bjørn Arild Mæland http://sinatra.lighthouseapp.com/projects/9779/tickets/16 Future 0 Eh, the fact that it's a bad idea to send password via clear text really has no bearing on whether it should be an extension or not. There are plenty of uses for basic auth that don't involve sending passwords as clear text. API keys and tokens, for example, are sometimes sent via basic auth. Also, there's a few specs out and about that insist on basic auth as a minimum. See, for example: http://bitworking.org/projects/atom/rfc5023.html#rfc.section.14 Basic auth should really be something we officially support. <div><p>Eh, the fact that it's a bad idea to send password via clear text really has no bearing on whether it should be an extension or not. There are plenty of uses for basic auth that don't involve sending passwords as clear text. API keys and tokens, for example, are sometimes sent via basic auth. Also, there's a few specs out and about that insist on basic auth as a minimum. See, for example: <a href="http://bitworking.org/projects/atom/rfc5023.html#rfc">http://bitworking.org/projects/a...</a>.section.14</p> <p>Basic auth should really be something we officially support.</p></div> false 2009-05-01T08:01:14-07:00 7654 --- {} 27724 16 patch-http-authentication 0 9779 new auth http patch 2009-05-01T08:01:19-07:00 9337 Bob Aman Bjørn Arild Mæland http://sinatra.lighthouseapp.com/projects/9779/tickets/16 Future 0 @Bob: I don't know. It's not something *every* app needs, and I like keeping he core lean and mean :) We should, however, pick an extension that handles this and mark it as the "preferred way". Even host it under github.com/sinatra to mark it as "official", and test against it with new releases to ensure it works. Only you need to require another library to get this extra piece of functionality. Now, which one we should choose, I don't know :) <div><p>@Bob: I don't know. It's not something <em>every</em> app needs, and I like keeping he core lean and mean :)</p> <p>We should, however, pick an extension that handles this and mark it as the "preferred way". Even host it under github.com/sinatra to mark it as "official", and test against it with new releases to ensure it works. Only you need to require another library to get this extra piece of functionality.</p> <p>Now, which one we should choose, I don't know :)</p></div> false 2009-05-22T21:15:27-07:00 7654 --- {} 27724 16 patch-http-authentication 0 9779 new auth http patch 2009-05-22T21:15:31-07:00 278 ronin-278 (at lighthouseapp) Bjørn Arild Mæland http://sinatra.lighthouseapp.com/projects/9779/tickets/16 Future 0 Rereading what I wrote, yeah... I wasn't clear. When I said "officially support" I didn't mean as part of the core. Just that we should officially maintain something, somewhere that does HTTP auth. <div><p>Rereading what I wrote, yeah... I wasn't clear. When I said "officially support" I didn't mean as part of the core. Just that we should officially maintain something, somewhere that does HTTP auth.</p></div> false 2009-05-22T21:53:26-07:00 7654 --- {} 27724 16 patch-http-authentication 0 9779 new auth http patch 2009-05-22T21:53:27-07:00 9337 Bob Aman Bjørn Arild Mæland http://sinatra.lighthouseapp.com/projects/9779/tickets/16 Future 0 false 2009-05-25T05:04:33-07:00 7654 --- :title: "[PATCH] HTTP Authentication" 27724 16 patch-http-authentication 0 9779 new auth http patch 2009-05-25T05:04:34-07:00 17123 Ryan Tomayko Bjørn Arild Mæland http://sinatra.lighthouseapp.com/projects/9779/tickets/16 Future 15214 0 Last I heard, Blake was working on something for this long standing ticket. Are there other HTTP auth extensions out there that are gaining good traction? <div><p>Last I heard, Blake was working on something for this long standing ticket. Are there other HTTP auth extensions out there that are gaining good traction?</p></div> false 2009-12-12T15:34:43-08:00 7654 --- :assigned_user: 27724 16 patch-http-authentication 0 9779 new auth http patch 2009-12-12T15:34:47-08:00 17123 Ryan Tomayko Bjørn Arild Mæland Blake Mizerany http://sinatra.lighthouseapp.com/projects/9779/tickets/16 Future 15214 0 I use http://github.com/integrity/sinatra-authorization/blob/master/lib/sinatra/authorization.rb which is actually based on some early code by you and cschneid but it is not actively maintained; I just noticed it is still using Sinatra::Default. I believe it could be good if someone gave it some love, though. It'd be a good use of the undocumented route-level filter feature. (`get "/foo", :protect => true`) The "playground" branch has some cool stuff as well, like this commit by nakajima: http://github.com/integrity/sinatra-authorization/commit/f4afb20e2850c4200ebc6edef6b947b5f80558c4 <div><p>I use <a href= "http://github.com/integrity/sinatra-authorization/blob/master/lib/sinatra/authorization.rb"> http://github.com/integrity/sinatra-authorization/blob/master/lib/s...</a> which is actually based on some early code by you and cschneid but it is not actively maintained; I just noticed it is still using Sinatra::Default. I believe it could be good if someone gave it some love, though. It'd be a good use of the undocumented route-level filter feature. (<code>get "/foo", :protect =&gt; true</code>) The "playground" branch has some cool stuff as well, like this commit by nakajima: <a href= "http://github.com/integrity/sinatra-authorization/commit/f4afb20e2850c4200ebc6edef6b947b5f80558c4"> http://github.com/integrity/sinatra-authorization/commit/f4afb20e28...</a></p></div> false 2009-12-12T15:57:11-08:00 7654 --- {} 27724 16 patch-http-authentication 0 9779 new auth http patch 2009-12-12T15:57:12-08:00 11306 Simon Rozet Bjørn Arild Mæland Blake Mizerany http://sinatra.lighthouseapp.com/projects/9779/tickets/16 Future 15214 0 That looks great sr. Let's close this. <div><p>That looks great sr. Let's close this.</p></div> true 2009-12-12T16:30:13-08:00 7654 --- :state: new 27724 16 patch-http-authentication 0 9779 resolved auth http patch 2009-12-12T16:30:14-08:00 17123 Ryan Tomayko Bjørn Arild Mæland Blake Mizerany http://sinatra.lighthouseapp.com/projects/9779/tickets/16 Future