ElkArte Community Modern, Free, Powerful
Community building forum software

I am not sure whether I should talk about this in close thread or an open one, but I decided the later might be best. I guess phpsessionid and cookies should by default use the forum set domain, not its top level domain, but since 1.0 (even smf), it has been using top level domain. I am not sure how this forum which should have the same built manage to set it correctly to www.elkarte.net. In mine, phpsessionid always remain the tld .sch.my, while for cookies, I only manage to set it to the forum domain using subdomain cookies settings, and add into the column below it the forum domain, elkarte.sch.my for 1.1 and elkarte2.sch.my for 2.0. I think it shouldn't be like that, and the default must always use the fully qualified domain name set for the forum, as well as its path/dir, if using any. Is the file for session used in this forum different causing phpsessionid to be correctly using FQDN set for the forum?

What about sites that use like a CMS that also logs cookies, as top then the forum as sub?
ElkArte here has everything logged into the same, but some sites have 2 different, one for main site and one for the forum.
I think it should be where it's easily set to how the admin wants it, whether the main domain, or subdomain.
If using just a directory, instead of sub-domain, then make it cover the whole domain, perhaps?

I going to start by writing down what the system should be doing and lets go from there, meaning is it not doing this or it is doing this buts its wrong.

• Neither Local nor Global is checked: Standard single domain or single subdomain forums (forum.example.com or example.com).  This generally should maximize compatibility while preventing subdomain cross talk / cookie leakage.  This is how this site is setup.
  
  
• Enable Local Cookies (localCookies) checked: Multiple distinct forum/app installations sharing the exact same hostname and path (e.g., example.com/forum1 vs example.com/forum2).  Scopes cookies strictly to the subfolder, and disables login persistence in parent directories.
  
  
• Enable Global Cookies (globalCookies) checked: A single login required across different subdomains (e.g., sharing login between forum.example.com and www.example.com). Allows subdomain session sharing, but requires proper domain scope entry in the "Main domain used for subdomain" (globalCookiesDomain) to avoid conflicts.  I will note that if not filled in, ElkArte will set a default one (like .example.com) however it will fail to this correctly if the domain contains a ccTLD  such as .sch.my, .co.uk, or .com.au

So basically I should not have chosen subdomain cookies there, and there is no necessities to fix forum domain there after. That seems to work great except the fact that phpsessionid is correct when that parts are left out, but when checked and filled, it becomes tld again, which it should not right? As the right one would be phpsessionid must always is the fqdn set for the forum, right?

When "Subdomain independent cookies" (a.k.a. globalCookies) is enabled, PHPSESSID becoming scoped to the parent/root domain (e.g. .example.com) is the intended behavior. However, if you do not need cross subdomain sharing, keeping the option disabled (which keeps cookies scoped to the forum's FQDN) is the right choice.

ElkArte manages two primary cookies one for authentication and one for sessions:

• The ElkArte Login Cookie ($cookiename): Stores the persistent login token and member ID.
• The PHP Session Cookie (PHPSESSID): Identifies the PHP session ($_SESSION), which tracks state, verification tokens, and session data.

Depending on your admin settings in Server Settings > Cookies and Sessions, domain scoping works as follows:

When "Subdomain independent cookies" is UNCHECKED
   

• PHP Session (PHPSESSID): ElkArte leaves session.cookie_domain at its default empty value. Browsers treat this as a host-only cookie locked strictly to the forum's exact Fully Qualified Domain Name (FQDN), e.g. forum.example.com.
• Login Cookie: Scoped strictly to the forum host/path.
• Result: Other subdomains (e.g., wiki.example.com or blog.example.com) cannot read or access the session or login cookie.

When "Subdomain independent cookies" is CHECKED
   

• PHP Session (PHPSESSID): ElkArte executes: @ini_set('session.cookie_domain', '.' . ltrim((string) $modSettings['globalCookiesDomain'], '.')); or automatically extracts the base domain (e.g. .example.com) <- fails on ccTLD
     
• Login Cookie: The cookie domain is set to .example.com.
• PHPSESSID must be set to the parent domain: If PHPSESSID remained locked to the forum's FQDN (forum.example.com), PHP sessions would not be shared across subdomains. Any ElkArte SSI/portal running on www.example.com or example.com would receive the login cookie but not the session cookie, causing session validation or CSRF checks to fail.

   
When global cookies are enabled:
   

• If the forum is at forum.example.com, the cookie is scoped to .example.com (the apex/registrable domain).
• The optional Global Cookie Domain (globalCookiesDomain) input is only needed if your domain has multiple labels or a multi-part TLD (e.g. example.co.uk) where automatic detection needs explicit guidance.
• Do not enable "Subdomain independent cookies" if ElkArte is standalone on its own domain or subdomain (e.g. forum.example.com) and you do not need users to be seamlessly logged into other subdomains. Leaving it unchecked ensures both PHPSESSID and login cookies remain host-only on the forum's FQDN.
• Enable it only if you run other applications/portals on sibling subdomains (or the apex domain) and use ElkArte's SSI / authentication bridge across them. In that setup, both cookies must be scoped to the parent domain.

Planning to use default for security even when using multi tenancy (multi domain addon) since each domain shall be using their own phpsessionid and cookies, but I am not so sure how to hook to cookies name yet, but intend not to create cookies name for each, but automatically use their fqdn as cookies name, easy to recognized, or is it not safe that way, as I noticed elkarte have reassigning the name with different end numbers each time?