2 ms·

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

by gry 15y ago

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 15y ago
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 15y ago
  > However, there is more more to this then verifying it renders. How do you mean?
  - swatermasysk 15y ago
    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 15y ago
      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 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.

by gry 15y ago

swatermasysk 15y ago

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 15y ago
> However, there is more more to this then verifying it renders. How do you mean?
- swatermasysk 15y ago
  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 15y ago
    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 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.