every time I sign in as the admin user for my ubuntu 18.04 hestiacp server I experience this same bug. it occurred on version 1.0.6 and now again on 1.1.0 Im using macOS Catalina Safari browser and the 1password browser extension. it allows me to paste the 2fa code in and then it reloads the login page the first sign in attempt stating invalid or missing token and then the second attempt always loads the path /inc/2fa/active.php?user=admin with a white page and a 200 status. then deleting the path and signing in once more with the same process of using 1password it actually makes it sign me in. It happens every time I sign in and I know it isnāt an internet connectivity issue for me. the bug seems to be isolated to safari browser as it doesnāt happen when using google chrome browser.
Just tried a setup with MacOS Catalina Safari Browser and the Google Authenticator there it works fine.
I think its in combination with the 1Password extension together with HestiaCP
I use KeePass to auto-fill passwords. I realized I first need to input the username (note this) for Hestia to be able to know that I need a 3rd input field (the 2FA field). And that there must be sufficient time for Hestia to understand I need the 2FA field and to be displayed, before ENTER is pressed (by the auto-type sequence).
The above are not directly related to the original problem. Just a heads-up of how I think the system works. For the issue in Safari+1Password, I suppose the 2FA only appears to you after you (or more accurately, 1Password) have filled in the user/pass, right? What happens if you manually paste the 2FA code (not rely on 1Password to paste it) and try to log in ?
I just tried to manually type the āadminā username in and then pasted the password in manually and then pasted the 2FA code in manually. I donāt have the auto submit option enabled for 1password so it waits until I I manually press the submit button everywhere. The issue occurs every time for me without fail on any macOS computer I try it on. Interestingly I know someone else had a similar issue, however their issue seems been that the 2FA box wasnāt showing up. in my case the 2FA field shows up I fill it out it returns invalid or missing token and I fill it out again how I described and get redirected to a blank white page that I have to reset the address bar to the main host and port and then login the same way once more to get into the panel. as another side issue, It signs me out after ~60 seconds of being on another page and coming back to the panel. It doesnāt make managing or debugging sites easy when I keep having to wrestle with the sign in. After signing me out on its own signing back in works the first time every time thereafter. You are right though that the 2FA field normally shows up after 1password enters the user/pass, however even typing the username in first and trying to manually paste the password and the 2FA code it yields the same outcome. even manually typing the 2FA code in shows the same error message. Could it be caused by me using Cloudflare or the fact that Iām using a custom port for the panel that isnāt the default panel port but instead one of the supported ports allowed through the Cloudflare proxy system?
This is interesting information. So the problem occurs even if you manually fill in user/pass/2FA.
Is this happening in Safari Private Window too? I just tried on Catalina+Safari+Private Windows and logged in without issues. I opened another site on a new tab and browsed for ~5 minutes. Then I got back to Hestia and it was still logged in.
Any special Safari extensions?
I suppose Cloudflare could interfere. If possible and for debugging, try without it to see what happens.
That would be possible, I would check it without cloudflare, default port shouldnt be needed at all.
I have wipr which is an ad blocker for macOS leveraging the content blocker feature of safari. however I had this issue far before I started using that extension. Besides that and 1password those are the only two extensions in safari I have installed. private window signed me out as well. I turned off āprevent cross site trackingā and the sign in works as expected as far as I can tell where it signs me in on the first time. I am now testing with that default preference still checked and instead turning Cloudflare dns proxy off for the domain the panel uses. so far it seems to be caused by Cloudflareās proxy and safariās default option to prevent cross site tracking that was added with Catalina. I can leave Cloudflare off for this domain I suppose, likely donāt need it with all of the security updates hestiacp has now. 2 minutes away from the logs tab and it still kept me signed in. Im thinking Cloudflare and safari cross site tracking blocking seemed to be the culprit. Iāll update this forum if it starts acting weird later. so far though I think @ScIT and @Felix both had the right idea that Cloudflare was causing it.I thought I tried it a while ago but that may have been before I migrated to hestiacp from the previous panel I was using regarding the sign out issue.
so 7 minutes of inactivity causes it to sign out but 3 minutes of inactivity didnāt sign me out. what is the actual session timeout duration for the hestiacp web panel so I know what it should be?
On my main computer (Windows + Firefox) I get signed out when:
- My IP changes (not 100% sure about that)
- Clear cache, cookies or open Private Window
Basicly what @Felix wrote, as far as I know, Hestia doesnt have a hard set session timer, but Iāll ask our team to give a proper answer here 
.
Cloudflare works via different nodes so this can be a issue. And the data can be send over mulitple nodes. Mainly when no activity happens with in x min.
Thanks for pointing me to it, probaly this was left due bad copy & paste work , Iāve removed the part with the following commit: https://github.com/hestiacp/hestiacp/commit/d69e80df68f92a5831e6e222ee7a30106fff742f
@rmjtechnologies I know. Use Cloudflare al lot even with PHP Sessions and stuff like that.
How ever if you check the PHP Code:
<?php
$v_user = escapeshellarg($_POST['user']);
$v_ip = escapeshellarg($_SERVER['REMOTE_ADDR']);
if (isset($_POST['twofa'])) {
$v_twofa = escapeshellarg($_POST['twofa']);
}
?>
You will see that $_SERVER[āREMOTE_ADDRā] is used for the security. With the use of Cloudflare the Remote Addr will be changed from the user to the remote addr of the caching server.
Solution of that is to check if a proxy (Cloudflare, AWS and any other party) and overwrite the ip with the ārealā ip
Problem solved.
I am trying out the suggested changes to those three files and so far with cloud flare and even the Wipr extension re enabled, 2fa login works the first time every time both in private window and regular safari window. Iām testing the auto logout issue currently but given the details that have come to light about using remote_address I agree that detecting proxies and replacing with the ārealā ip is a real solution to the issue I was experiencing with auto sign out. I will say that with those changes to the 3 files the only xhr request is that made on sign in request now to the same hostname as the hestiacp panel. As I wrote this response 10 minutes have already passed and I remain signed into the hestiacp hosting panel which passes the previous time by a few minutes already.
everything is working super smoothly now, thank you! I look forward to the next official release with this included
just wanted to say: AWESOME GUYS!
thanks for figuring out the problem and a solution/fix and even submitting the changes via PR - that is really awesome community help and much appreciated! keep on rocking 