

Running Pow Over SSL - swatermasysk
http://www.scottw.com/using-ssl-pow

======
gry
I used to think this was a good way to test SSL, but it's a lot more work to
bootstrap a developer and doesn't maintain good separation of concerns. SSL
should belong in all your non-desktop/laptop boxes -- production, staging,
test.

In test setup blocks:

    
    
      @request.env['HTTPS'] = 'on'
      @request.env['SERVER_PORT'] = 443
    

You can stub out TLS/SSL. Then, ensure your require SSL definition in your
controller returns a HTTP 426 status if it's not over SSL.

Your tests expect a 200 response, not a 426 or 302. 302 is bad -- you've
already submitted via plaintext once (I'm looking at you, ssl_requirement).
Fail fast and fix your code.

SSL will be disabled for only localhost requests.

    
    
      def ssl_enabled?
        !(request.local?)
      end
    

This has been tested on dozens of computers.

~~~
swatermasysk
If this was only about code, I would agree with you.

However, there is more more to this then verifying it renders. For that, I
still need to be able to see it in a browser right in front of me.

For me, the two minute setup time for this is well worth.

Thanks for the suggestion/comment.

~~~
gry
> However, there is more more to this then verifying it renders.

How do you mean?

~~~
swatermasysk
Verifying scripts work properly under SSL, verifying the experience between
other 3rd party services (such as payments), etc.

Again, this could all be done on a dedicated test/staging server, but the cost
of doing it locally is virtually free, so why not?

~~~
gry
I follow.

I should preface it by saying I'm working with a team of about 10 developers.
For every developer to have to the software working on their local machine,
it's a burden.

Our unit/functional tests run clean when SSL is stubbed out from client
requests. We use webmock (<https://github.com/bblimke/webmock>) to mock 3rd
party integrations. Upon deploy to staging, integration tests (Selenium) sweep
through.

Our monitoring software ensures the app and its 3rd party services are
responding to those integration points.

So yeah, developing by yourself, it's ok-ish. Though I still prefer having
infrastructure be predictable. Mocking the SSL _configuration_ through a
reverse proxy feels brittle to me...it usually isn't how production is
configured.

I guess another way of putting it -- I'd rather not inspect to make sure the
app and its components behave over SSL. I'd rather it not work. Fail fast as
they say.

I should draft up our approach and clarify the points. Maybe this weekend.

