V9.1 Prompts and logins.

[Damo]

Invoice immutability is disabled. We strongly recommend updating your workflows to eliminate the need to edit non-Draft invoices
 

No matter how many times we dismiss this message, via the X it shows every time we login. 
 

Also, the admin login is not staying set. Why are admins required to login each time? 

[WHMCS John]

Hi @Damo,

The notice dismissal and remember me are cookie-based. Check your browser settings aren't blocking the cookie from your domain.

If the cookie is blocked then you'll see admin notices and login prompts once the PHP Session has expired.

[Damo]

This is still happening.  Multiple devices, multiple admin users, multiple browsers.  Are there any tools or suggestions on how to track down the cause?

It only started with this release.

Cookies and sessions for another app on the same domain as our WHMCS continue to work without issue.

[Waqas Ahmed Waseer]

@Damo if it's every device, every browser and every admin, I'd stop looking at browser settings and check whether the cookie is actually being set and kept. This is what I'd go through:

1. Watch the login in DevTools. Open the admin login page in Chrome, press F12, go to the Network tab, tick Remember Me and log in. Click the login request and look at the Set-Cookie lines in the response headers. If Chrome rejected one, there's a small warning icon next to it, and hovering over it tells you why (Secure flag on a non-HTTPS request, SameSite, domain mismatch and so on). Then open Application, Cookies for your WHMCS host and see whether the cookie is there and what expiry it has. A cookie that shows "Session" in the Expires column instead of a future date would explain the repeated logins exactly.

2. Compare the System URL with the address your admins actually type. Under Configuration, System Settings, General Settings, the WHMCS System URL should match the scheme and host exactly (https, and www or no www). A mismatch there is one of the most common reasons login and dismiss cookies don't stick.

3. Look at anything sitting between the browser and PHP. A Cloudflare cache rule or a caching proxy that caches admin responses can drop or reuse Set-Cookie headers, and server-side hardening (an Apache Header edit rule on Set-Cookie, nginx proxy_cookie_path or proxy_cookie_flags, a WAF rule) can rewrite them. Since your other app on the same domain is fine, check whether a rule like that only matches the WHMCS path, or was added around the time you upgraded.

4. If admins also get thrown out in the middle of working, check the PHP side too: session.gc_maxlifetime for the PHP version WHMCS actually runs on, and whether anything cleans the session save path more aggressively than that. On cPanel servers each ea-php version has its own php.ini, so the value you checked may not be the one WHMCS is using.

If step 1 shows the cookie arriving with a sensible expiry and then vanishing, or not being sent at all on 9.1 when it was before, that's worth a ticket with WHMCS. Attach the response headers from the login request, with the cookie values blanked out.