Flatpress 1.3 Login not working with http protocol

[prbt2016]

Hello,

I was in the process of manual installation of Flatpress 1.3 with Centos 7 with Apache 2.2/ 2.4, and also PHP 7.1/7.2/7.3/7.4/8.0/8.1/8.2/8.3 on http protocol on multiple testing servers.

However , I found that login doesn't work with http protocol, after entering the credentials , script redirects back to login .

However on https the login works fine .

Is this an issue ? . Could you please replicate that on your server ?

[Fraenkiman]

Hello @prbt2016

I have invested a lot of time in testing, but I am not aware of such a problem. Mostly such problems occur in connection with Docker or reverse proxies. There may be a misconfiguration.

FlatPress has no influence on the configurations of Docker, reverse proxies and DNS resolvers. You can rename existing .htaccess files as a test - just in case a failed rewrite rule is hidden here.

Check the settings.conf.php file in the /fp-content/config directory to see whether it is actually an http URL on port 80 or not. If you want to switch from an HTTPS connection to an HTTP connection, you must first adapt this part in this file

$fp_config = array (
  'general' => 
  array (
    'www' => 'https://your-flatpress-instance.ltd/',

Best regards
Frank

[prbt2016]

Hello @Fraenkiman ,

FlatPress has no influence on the configurations of Docker, reverse proxies and DNS resolvers. You can rename existing .htaccess files as a test - just in case a failed rewrite rule is hidden here.

We'll I am not using Docker, reverse proxies and DNS resolvers, plus i have no .htaccess configured.

Using 'LAMP' stack for testing .

My settings.conf.php holds this content as below for the www URL i.e:

<?php

$fp_config = array (
  'general' => 
  array (
    'www' => 'http://{{DOMAIN.COM}}/flat13/',

I have the browser console output of the same for your kind reference . Please check .

Kindly let me know regarding the same.

Regards.

[Fraenkiman]

Hello @prbt2016.
This is a browser issue - to protect users 😉. Experts say: it's a feature, not a bug. I assume you are using Chrome or a browser based on Chromium. There was an issue with/after the Chrome 80 update a while ago. You have to force/convince your browser to accept this cookie anyway.
You could use Firefox 78.6.0esr as a fallback and add an exception for the domain. However, I would advise against this, as the browser is already a few days old.

You can weaken the cookie at your own risk by removing the "samesite" attribute and the corresponding value.
To do this, you must edit the defauls.php file and comment out line 134.
https://github.com/flatpressblog/flatpress/blob/c2cca7357c3b095ce7e6ca3cf39948ef9a7ef530/defaults.php#L134C1-L134C43

In line 132 you would have to change the value from 1 to 0.

But let's ask the other way round: Would you want to log in somewhere even though you are connected via an HTTP connection/unencrypted?

A non-encrypted connection does not provide a secure login.
However, the secure login is necessary so that FlatPress is not exposed to cross-site scripting (XSS) attacks.

With best regards
Frank

[Fraenkiman]

I have created #375 and am therefore closing this issue.
With best regards
Frank

[azett]

@prbt2016
Prashant, thank you very much for reporting.
Can you confirm everything works fine again after applying the changes @Fraenkiman suggested with #375 ?

Update 2024-04-15:
I created a branch with @Fraenkiman 's changes.
@prbt2016 , can you please download and test this package? (Unfortunately, I am not able to reproduce the problem myself.)
Thanks a lot!

[Fraenkiman]

Hello everyone,
In principle, solution #375 works for this problem and is correct from a browser perspective.
Only the HTTPS cookie receives the secure flag/prefix and the HTTPONLY.
What gives me a headache, however, is e2a6bf1. For some reason you have also set the "secure" flag for HTTP cookies, which doesn't fit from today's modern browser point of view. Unfortunately, I can't find the security problem reported at the time on huntr.dev.

We don't know the server setup of the FlatPress admin.
What do you two think of a supplementary solution in the event that both HTTP and HTTPS requests are possible at the same time, depending on the server configuration? As soon as the PrettyURLs plugin is called via HTTPS in the admin area ->, a redirection from HTTP to HTTPS can be set via .htaccess.

	RewriteCond %{SERVER_PORT} !^443$
	RewriteRule (.*) https://%{HTTP_HOST}/$1 [R=301,L]

flatpress/fp-plugins/prettyurls/plugin.prettyurls.php

Line 641 in 3c5adce

<IfModule mod_rewrite.c>

Alternatively, I could place a warning in the support plugin that it is not recommended to offer HTTP during live operation.

With best regards from Berlin
Frank

[prbt2016]

Hello @azett , @Fraenkiman ,

Thanks for looking into the issue.

I checked with the package i.e https://github.com/flatpressblog/flatpress/archive/refs/heads/issue371_httphttps.zip

But still having the same issue with http.

I have tested with latest browser versions i.e : Chrome Version 123.0.6312.122 (Official Build) (64-bit) and Firefox 124.0.2 (64-bit).

Following is the console output for your kind reference :

Is there anything else that I can debug ?. Kindly let me know?.

Regards.

[Fraenkiman]

Hello everyone,

That's strange! With a non-HTTPS call, the red part I marked should not work at all. ... but only the part marked green by me.

This means that the "SameSite" and "secure" attributes should not be set at all.

Apparently the evaluation of the query in line 133 does not work correctly and $_SERVER ['HTTPS'] is not defined.

flatpress/defaults.php

Line 133 in ddfef97

if (isset($_SERVER ['HTTPS']) && ($_SERVER ['HTTPS'] == '1' || strtolower($_SERVER ['HTTPS']) == 'on')) {

If this is the case, the following change in line 133 should remedy the situation

if(!empty($_SERVER ['HTTPS']) && $_SERVER ['HTTPS'] != 'off' or $_SERVER ['SERVER_PORT'] == 443) {

Debugging: For me, with a non-HTTPS connection:

@ini_set('display_errors', 'on'); // on or off
@error_reporting(E_ALL); // E_ALL or 0
var_dump($_SERVER ['HTTPS']);
var_dump($serverport);

// Determine HTTP / HTTPS
if(!empty($_SERVER ['HTTPS']) && $_SERVER['HTTPS'] != 'off' or $_SERVER ['SERVER_PORT'] == 443) $protocol = 'https';
else $protocol = 'http';
var_dump($protocol);

results in

string(2) "off"
string(8) "http://"
string(5) "http"

@prbt2016, would you like to make the change yourself and test it?
Update from 19.04.2024: I have changed the query from $_SERVER ['HTTPS'] to this branch.
The branch was successfully tested by me under the following conditions:

• Debian 11, Apache 2, PHP 8.1 SSL/ HTTPS only, Public domain
• Windows 11, XAMPP, Apache 2, PHP 8.2, SSL/ HTTPS only, Local network
• Windows 11, XAMPP, Apache 2, PHP 8.2, HTTP only, Local network
• Windows 11, XAMPP, Apache 2, PHP 8.2, SSL/ HTTPS and HTTP, Local network

I have no possibility to test with reverse proxy, load balancer or under IIS.

@DeltaLima, please check this as well if possible.

With best regards
Frank

[azett]

I was finally able to reproduce this one on a HTTP-only server with "HTTPS only" deactivated in Firefox.
And I created a fix with ba890f3 - @prbt2016 , can you please try again with the latest version of our HTTP/HTTPS development branch?

For the record: Same problem as in #378

[Fraenkiman]

@azett, your ba890f3 fix works with my test options.

Update 23.04.2024:
Possible solution included in comment #251 (comment)

[prbt2016]

Hello @Fraenkiman , @azett

Apologies for the delay in reply. I have checked with the latest dev branch i.e https://github.com/flatpressblog/flatpress/archive/refs/heads/issue371_httphttps.zip and script works fine both on http and https.

Regards.

[Fraenkiman]

Hello @prbt2016,

I'm glad to read that the admin login now works with HTTP and HTTPS. Thank you for the time and effort you have invested.

We have another problem which is similar.
The environment consists of a load balancer which is accessible via HTTPS, but the HTTP server behind it only delivers HTTP.
The load balancer takes over the SSL encryption/decryption, but does not contain $_SERVER ["HTTPS"].

I have implemented @rrossouw01's solution in another branch.
May I ask you again to test this branch as well?

With best regards
Frank

• Solution by @rrossouw01 from theme issues with https site #251 (comment)

[prbt2016]

Hello @Fraenkiman ,

Unfortunately I don't have any load balancer setup available .

So won't be able to check the exact test case.

But I tested with this https://github.com/Fraenkiman/flatpress/archive/refs/heads/issue251-hhtps-LB-Proxy.zip on both http and https environments

Didn't face any issues as such with themes.

Regards.

[Fraenkiman]

Hello @prbt2016,

it's not so tragic that you don't have an environment with a load balancer. @rrossouw01 has already tested this solution with LB environment. I just want to make sure that with the issue251-hhtps-LB-Proxy.zip branch you don't have the login problem with Http connection again.

We may then be able to solve two different problems with this branch.

Thanks again for your support.
With best regards
frank

[azett]

Thank you all for testing and fixing! I put it all together in the issue371_httphttps branch.
Can you please perform a final test with the latest version of that branch? If all works fine, this will be released as FlatPress 1.3.1.
Thanks a lot!

[rrossouw01]

guys -- it did not work for me. I am using a fresh download issue371_httphttps.zip. couple things:

1. setup fails so I made setup work by this:

$ diff fp-defaults/settings-defaults.php /tmp/settings-defaults.php 
4c4
< 		'www' => 'https://flat.xxxxxxxxx.com',
---
> 		'www' => 'http://localhost',

2. back to the normal font issue I did this quick fix and that worked.

$ diff defaults.php /tmp/defaults.php 
147d146
< $serverport = 'https://';

if the diff is unclear all I did was add one line in defaults.php:

....
        ini_set('session.cookie_secure', 0);
}
$serverport = 'https://';

// compatibility with ISS
...

[Fraenkiman]

@azett,
are you sure with $isSecure = true; ?

flatpress/defaults.php

Line 192 in 16298a3

$isSecure = true;

maybe return true; ?

@rrossouw01, can you please change the line 192 I highlighted to return true; and test it again?
ab1a9df

Many thanks in advance.
With best regards
Frank

[azett]

My bad :(
With ab1a9df, @Fraenkiman fixed it. It's now part of the issue371_httphttps branch.
Sorry for the confusion.

[rrossouw01]

@azett that works. I did not have time to revisit the setup issue I mentioned but simply replacing with your fix works for lb(traefik with cert) + container(flatpress served on http).

diff defaults.php /tmp/defaults.php
191c191
< 		return true;
---
> 		$isSecure = true;

[azett]

Awesome, thank you very much for testing patiently.
Since @prbt2016 's problem is fixed as well, I'll release 1.3.1 as soon as possible :)

[Fraenkiman]

Hello everyone,

many, many thanks for your support.
I have manually imported the changes from the issue371_httphttps branch into the master branch.

Have a nice Sunday evening
With best regards
Frank

[RoopeshKharvi]

I was finally able to reproduce this one on a HTTP-only server with "HTTPS only" deactivated in Firefox. And I created a fix with ba890f3 - @prbt2016 , can you please try again with the latest version of our HTTP/HTTPS development branch?

For the record: Same problem as in #378

It's not work for me. I have modified these 2 files (ba890f3)

[Fraenkiman]

Hi @RoopeshKharvi, thanks for testing.

t's not work for me. I have modified these 2 files (ba890f3)

ba890f3 still had an error. Curious questions: What did your modification look like? With reverse proxy or load balancer?
Please test the current issue371_httphttps branch with ab1a9df and/or the master branch. I do not expect such problems there.

With best regards
Frank

[RoopeshKharvi]

both works in docker (ab1a9df and https://github.com/flatpressblog/flatpress/archive/refs/heads/master.zip)
but not work in c panel.

[prbt2016]

Hello @azett , @Fraenkiman

I have tested with the master branch and it worked fine for me on both http and https without any hassles.

Kind regards.

[azett]

both works in docker (ab1a9df and https://github.com/flatpressblog/flatpress/archive/refs/heads/master.zip) but not work in c panel.

@RoopeshKharvi Thanks for testing! Can you provide relevant portions of your web server's or PHP's error log? Or any other output or log file that may contain more details?

I have tested with the master branch and it worked fine for me on both http and https without any hassles.

@prbt2016 Awesome, thanks a lot! :)

[Fraenkiman]

Hello everyone,
Wouldn't we rather create a new issue #386 "cPanel server management software" so that we can close this one? I'll be cheeky 😁.

@prbt2016, thank you very much for your great help 👍.

Happy holiday to everyone in Germany tomorrow
With best regards
Frank