OK, so @larin555 contacted me again with the issue which was still unresolved.
I had a look at his setup and found the following to be the cause -

His users were accessing the admin-panel sometimes using the SSL secured URL (i.e. with 'https://') and also sometimes using the unsecured version of the same URL (i.e. with plain 'http://').

Now this leads to the following situation -
Suppose the user first visits the admin-panel using the secured URL; everything goes as expected, cookies get set etc.
Now suppose after some time the same user visits the admin-panel using the unsecured URL.
This time the browser will refuse to set any cookies and will complain (as seen in the developer console) that
"This attempt to set a cookie via a Set-Cookie header was blocked because it was not sent over a secure connection and would have overwritten a cookie"


And that is what was causing the issue being discussed in this thread.
TLDR; accessing the site using both secured and unsecured URLs will lead to this problem when an unsecured URL is used.

The solution is to enforce the use of only one kind of URL (which, obviously, has to be the secured one if the site is SSL enabled).
One easy way of doing this is to explicitly specify the canonical URL to be used for the site in couch/config.php e.g. as follows -
Code: Select all
// 1.
    // If necessary, define the full URL of your site including the subdomain, if any.
    // V.IMP: Don't forget the trailing slash!
    define( 'K_SITE_URL', 'https://www.yoursite.com/' );

Note the 'https:// ' in the URL.
This way even if someone now tries to use an unsecured URL, Couch will silently redirect the user to the secured URL specified above thus preventing this cookie issue to crop up,

Hope this helps someone coming across a similar issue.