Demo page never allows you to login from CNAME URL

[jbrooksuk]

Something is wrong with the demo site (I've just pushed the latest changes). After setup, if you logout and then back in again, it'll simply redirect you back to the login page without an error message.

https://status.cachethq.io/auth/login

[jbrooksuk]

Nevermind. Fully redeployed and it worked.

[jbrooksuk]

Nevermind. Fully redeployed and it worked.

[jbrooksuk]

Nope. I lied.

The problem occurs when you attempt to login via https://status.cachethq.io but if you login using the https://cachet.herokuapp.com it works fine.

[joecohens]

Does this has to be with the proxied domains ? Maybe we should add or change the default domain to status.cachethq.io on the configs.

[jbrooksuk]

Perhaps... Let me reset the migrations.

[jbrooksuk]

Nope, still doesn't work.

[jbrooksuk]

I wonder if it's CloudFlare?

[joecohens]

I think CloudFlare it's disabled Traffic will bypass CloudFlare's network I'll enable it because we have the rule to force SSL.

[jbrooksuk]

I happened to just disable it.

[joecohens]

Lol we would need to disable the force SSL on the subdomain if that's the problem.

[GrahamCampbell]

Cloudflare cannot be causing this. Don't disable forcing ssl.

[noahbass]

^ this

[GrahamCampbell]

Also, even if it was cloudflare, we'd need to still get it working. Other people way want to use cachet behind cloudflare.

[noahbass]

Yeah. I'm doing a test on heroku + cloudflare right now to try to find some fixes to this

[GrahamCampbell]

thx :)

[jbrooksuk]

My thoughts on this:

• apcu, some weird config?
• Laravel config is not done properly?
• Sessions?

[GrahamCampbell]

Ahh yes. What have you configured the app url as @jbrooksuk?

[GrahamCampbell]

It needs to be set to "https://status.cachethq.io".

[jbrooksuk]

It's just set as localhost in config.url. The setup page will ask for the URL, so we should overwrite the setting.

[GrahamCampbell]

I think we might need to set it at an earlier point. That might be what's causing the issue.

[jbrooksuk]

Like we do with the timezone and locale?

[jbrooksuk]

@GrahamCampbell we are actually setting the app.url value https://github.com/cachethq/Cachet/blob/master/src/Http/Before/LoadConfigFilter.php#L26

[GrahamCampbell]

Oh wow, that stuff does not belong in a filter. It belongs in the register method of a service provider.

[jbrooksuk]

Yeah, I was playing with the idea earlier, but ran out of time :(

[joecohens]

Sorry my bad :(. @GrahamCampbell so we set a LoadConfigServiceProvider and move the filter code?

[GrahamCampbell]

Yeh, sounds like a plan.

[joecohens]

Perfect!

[noahbass]

Update on possible fixes: (Note: all of these were tested on heroku + cloudflare ssl)

1 the Request::setTrustedProxies fix

It simply did not work.

2 fideloper/TrustedProxy

It simply did not work.

3 the $_SERVER fix (adapted from seedprod/laravel-cloudflare)

3.1 Throwing it into a filter

public function filter()
{
    if (isset($_SERVER['HTTP_CF_VISITOR']) && preg_match('/https/i', $_SERVER['HTTP_CF_VISITOR'])) {
        $_SERVER['HTTPS'] = 'On';
        $_SERVER['HTTP_X_FORWARDED_PORT'] = 443;
        $_SERVER['SERVER_PORT'] = 443;
    }
}

and adding it to the RoutingServiceProvider.php in the registerFilters function. Does not work.

3.2 Throwing it into a service provider

Same function as above renamed to boot in a new service provider. Then added to app/config/app.php providers. Does not work

3.3 Throwing it into a bootstrap/ file

Throwing this into autoload.php or start.php will work!!:

if (isset($_SERVER['HTTP_CF_VISITOR']) && preg_match('/https/i', $_SERVER['HTTP_CF_VISITOR'])) {
    $_SERVER['HTTPS'] = 'On';
    $_SERVER['HTTP_X_FORWARDED_PORT'] = 443;
    $_SERVER['SERVER_PORT'] = 443;
}

My conclusion

The fix works in a bootstrap/ file, but not in a filter or service provider. So I'm thinking that putting this fix in a service provider or filter is too late for laravel to see and generate https urls.

[jbrooksuk]

@GrahamCampbell any idea on this? Is there a way to hook into bootstrap.php without actually placing the code there?

[GrahamCampbell]

There is a better way of doing this. See my cms again. :)

[GrahamCampbell]

https://github.com/fideloper/TrustedProxy
https://github.com/BootstrapCMS/CMS/blob/0.8/app/config/packages/fideloper/proxy/config.php

I've used the cloudflare server ips as the default in my cms config there. :)

[jbrooksuk]

@noahbass do you want to try it with the TrustedProxy package?

[pedrommone]

TrustedProxy is a good one, I use in my projects.

[noahbass]

@GrahamCampbell, @jbrooksuk

Just did a test again with https://github.com/fideloper/TrustedProxy. It didn't work.

[pedrommone]

Are you using behid a nginx or cloudflare?

[noahbass]

It's a heroku + cloudflare setup

[pedrommone]

Did you set cloudflare ips on white list? @GrahamCampbell posted one above.

[noahbass]

@pedrommone yes I did

[noahbass]

Okay. Now this is getting weird. Applying https://github.com/fideloper/TrustedProxy will fix the ssl issues on a *.herokuapp.com host for some reason, but not the cloudflare host.

[jbrooksuk]

@noahbass let's get one problem fixed at a time. Now we know TrustedProxy is fixing half of it, let's do that.

[jbrooksuk]

I've just pushed with the changes.

[jbrooksuk]

Even with the TrustedProxy fix, I'm still unable to login at https://status.cachethq.io/dashboard :(

[noahbass]

Unless we're doing something wrong on our end, then I guess this is an issue with fideloper/TrustedProxy.

[jbrooksuk]

Side note; we still need to fix the bloody unsecure forms.

[jbrooksuk]

Any other ideas on this? I don't see why we have an issue with logins just because we're running on a different domain?

[jbrooksuk]

Since we have no solution on this I replaced the Form facades with raw HTML in 5ac5f12. It's now fixed.