Skip to main content ↑ ↓
Recent Posts
2
Bug Reports / Re: PhpSessionId & Cookies
Last post by Hj Ahmad Rasyid Hj Ismail -
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?
3
Bug Reports / Re: PhpSessionId & Cookies
Last post by Spuds -
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.
4
Bug Reports / Re: Slow Page Load time
Last post by Spuds -
I generally still use APCu as well.

I think what you are seeing in the Admin panel is, when you use a cache engine that requires a connection such as Redis, Memcached, Memcache, they store that value in cache_servers in your Settings.php file.  The system does not save the server names for each cache engine (as only one can be used at a time), so it reuses the variable name.   This is not the cleanest setup, but its what we have.

When you swap engines you need to set the server name and save to validate it actually connects.  On a typical server these are likely the same e.g. localhost and ElkArte will try the standard ports for the engine you choose.
5
Bug Reports / Re: Slow Page Load time
Last post by Hj Ahmad Rasyid Hj Ismail -
Replaced the old Redis.php with the new one but seemed like having no effect. Nothing is shown on the admin side. Note that memcache menu is till on whether memcache or memcached or redis is selected, of which I think its default behaviour must be hidden when either of the other two is selected. For now I am still maintaining ACPU as the option since it is the second best after redis.
6
Bug Reports / Re: PhpSessionId & Cookies
Last post by Hj Ahmad Rasyid Hj Ismail -
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?
7
Bug Reports / Re: Slow Page Load time
Last post by Spuds -
I'm using ext-redis not predis/predis indicating that for clarity. 

The server is level 6.2.24 and my dev setup had no UID and a PASS of redis.   On a successful connection it should say something like: / Connected servers: redis in the admin panel.  If it fails to connect it will say Connected servers: No results found.

Just for fun I set a bogus UID to see what would happen and got a fatal error while trying to connect, so that is not good.  Looking into that now.

ETA: Attached is a new Redis.php file that will not fail on a bad connection.  It goes in ...\sources\ElkArte\Cache\CacheMethod
8
Bug Reports / Re: PhpSessionId & Cookies
Last post by Spuds -
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
9
Bug Reports / Re: PhpSessionId & Cookies
Last post by ScottJB -
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?
10
Bug Reports / PhpSessionId & Cookies
Last post by Hj Ahmad Rasyid Hj Ismail -
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?