Skip to content

when ENVIRONMENT=development is set, the server does not work on https #16

Description

@ylebre

There is an issue with the following bit of code:

/*/ Make sure HTTPS is always used in production /*/
$scheme = 'http';
if (getenv('ENVIRONMENT') !== 'development') {
    $router->map('GET', '/{page:(?:.|/)*}', HttpToHttpsController::class)->setScheme($scheme);
    $scheme = 'https';
}

I would expect https to work as well with the development environment, but because all the routes are tied to $scheme, they are only available on http.

Activity

  1. Potherca commented on Oct 7, 2020

    @Potherca
    Member

    That code was originally created to enable development before a (Docker) HTTPS server was available as the internal PHP HTTP server does (explicitly) not support HTTPS.

    It might be more sensible to change the getenv('ENVIRONMENT') check to something in the direction of "unsafe" rather than forcing all development environments to be unsafe...

  2. modified the milestones: v0.3.0, v0.4.0 on Oct 7, 2020
  3. ylebre commented on Oct 8, 2020

    @ylebre
    MemberAuthor

    Maybe we can just check for env http or https to make it explicit? and even add routes for both schemes.

  4. Potherca commented on Oct 15, 2020

    @Potherca
    Member

    Strictly speaking, there shouldn't be any HTTP at all. It should just always redirect to HTTPS.

    At this point, I'm inclined to just remove the HTTP code entirely...

  5. ylebre commented on Oct 17, 2020

    @ylebre
    MemberAuthor

    I agree, having a secure default is the better option here, so we could just remove the http scheme completely. If someone really needs http:// it should be easy enough to modify that in the code.

  6. Potherca commented on Oct 23, 2020

    @Potherca
    Member

    We had a discussion offline, the current conclusion is as follows:

    1. Instead of using ->setScheme($scheme) for evey route or route-group, we remove them everywhere. This makes the routes scheme-agnostic.
    2. We add a check that forces the use of HTTPS (via a redirect on non-https). This check can be enabled (or disabled) through a config/env var.

    This means that unsafe (i.e. HTTP) URLs are supported, in case HTTPS is provided through a server-side proxy.

    The question that remains is whether it makes more sense to have the HTTPS check on or off.

    Thoughts? @ylebre / @poef / @michielbdejong

  7. self-assigned this
    on Oct 23, 2020
  8. modified the milestones: v0.4.0, v0.5.0 on Oct 23, 2020
  9. modified the milestones: v0.5.0, v0.6.0 on Dec 8, 2021
  10. added 2 commits that reference this issue on Dec 8, 2021
    e0585d3
    5162380
  11. added a commit that references this issue on Dec 10, 2021
    2c3b27e
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions