falcon: Falcon is tryng to make me authenticate using X.509 User certificate

Probably because my browser advertises itself as having local X.509 certificate that can be used as a way to authenticate, I get the browser dialog requesting to select a certificate to authenticate with.

There is probably a flag on the backend that needs to be toggled to not do that.

When I selected one of the existing certificates, this was the output from the terminal:

E, [2018-10-22T18:13:39.339422 #92506] ERROR -- #<Async::IO::SSLServer:0x0000000123a8ca40>: SSL_accept returned=1 errno=0 state=error: sslv3 alert bad certificate (OpenSSL::SSL::SSLError)
/Users/brodock/.rvm/gems/ruby-2.4.4/gems/async-io-1.16.1/lib/async/io/generic.rb:128:in `accept_nonblock'
/Users/brodock/.rvm/gems/ruby-2.4.4/gems/async-io-1.16.1/lib/async/io/generic.rb:128:in `async_send'
/Users/brodock/.rvm/gems/ruby-2.4.4/gems/async-io-1.16.1/lib/async/io/generic.rb:47:in `block in wrap_blocking_method'
/Users/brodock/.rvm/gems/ruby-2.4.4/gems/async-io-1.16.1/lib/async/io/ssl_socket.rb:122:in `block in accept'
/Users/brodock/.rvm/gems/ruby-2.4.4/gems/async-1.10.3/lib/async/task.rb:74:in `block in initialize'

About this issue

Original URL
State: closed
Created 6 years ago
Reactions: 5
Comments: 41 (19 by maintainers)

Commits related to this issue

Don't try to verify the client. https://github.com/socketry/falcon/issues/24 — committed to socketry/localhost by ioquatix 5 years ago

Most upvoted comments

There is still something not working as expected.

I retried today with 0.24.0 and this is what I get when trying to access localhost:3000 started with facon serve --port 3000:

 1m52s: <Async::Task:0x86d60854 failed>
      |  OpenSSL::SSL::SSLError: SSL_accept returned=1 errno=0 state=error: http request
      |  → /Users/brodock/.rvm/gems/ruby-2.5.3/gems/async-io-1.18.2/lib/async/io/generic.rb:141 in `accept_nonblock'
      |    /Users/brodock/.rvm/gems/ruby-2.5.3/gems/async-io-1.18.2/lib/async/io/generic.rb:141 in `async_send'
      |    /Users/brodock/.rvm/gems/ruby-2.5.3/gems/async-io-1.18.2/lib/async/io/generic.rb:47 in `block in wrap_blocking_method'
      |    /Users/brodock/.rvm/gems/ruby-2.5.3/gems/async-io-1.18.2/lib/async/io/ssl_socket.rb:129 in `block in accept'
      |    /Users/brodock/.rvm/gems/ruby-2.5.3/gems/async-1.15.1/lib/async/task.rb:199 in `block in make_fiber'

brodock on Feb 19, 2019

@brodock Do you mind trying this again and opening a new issue if the problem persists? I would REALLY appreciate that. Thanks so much.

ioquatix on Jan 26, 2019

Sorry for the response lag, @ioquatix; work got a little crazy there for a while. In any case, I just pulled in falcon 0.19.6 and things look great. Thanks for that!

FWIW, here’s the Gemfile.lock portion that might be of interest:

    falcon (0.19.6)
      async-container (~> 0.8.0)
      async-http (~> 0.37.2)
      async-io (~> 1.9)
      http-protocol (~> 0.10.0)
      localhost (~> 1.1)
      rack (>= 1.0)
      samovar (~> 1.3)

turboladen on Dec 12, 2018

Ah, you know what… I still get the Async errors, but if I do RACK_HANDLER=falcon rails s -p 3456, things start behaving normally. It seems falcon is disregarding the changes to Rails::Command::ServerCommand that we have in config/boot.rb:

ENV['BUNDLE_GEMFILE'] ||= File.expand_path('../Gemfile', __dir__)

require 'bundler/setup' # Set up gems listed in the Gemfile.
require 'bootsnap/setup'
require 'rails/command'
require 'rails/commands/server/server_command'

class Rails::Command::ServerCommand
  class_option :port, aliases: '-p', type: :numeric,
                      desc: 'Runs Rails on the specified port.', banner: :port, default: 3456
end

We set the port in all of our apps like this so developers don’t always have to manually add the flag.

turboladen on Nov 29, 2018

Got it. Thank you very much for you help!

xtagon on Oct 25, 2018

Yes

Then you can instruct Rails to pick up Falcon as your Rack handler:

export RACK_HANDLER=falcon

and then run as normally you do with your dev server:

rails s

Or altogetther: RACK_HANDLER=falcon rails s

concernedrat on Oct 22, 2018