0036819: Secure cookies are rejected by the browser - MantisBT

ID	Project	Category	View Status	Date Submitted	Last Update
0036819	mantisbt	authentication	public	2026-01-07 19:56	2026-04-12 09:57

Reporter	ThecaTTony	Assigned To	dregad
Priority	normal	Severity	major	Reproducibility	always
Status	resolved	Resolution	fixed
Platform	linux	OS	ubuntu	OS Version	24.04 lts
Product Version	2.28.0
Target Version	2.28.2	Fixed in Version	2.28.2

Summary	0036819: Secure cookies are rejected by the browser
Description	After updating to version 2.28.0 and having the cookie prefix set to: $g_cookie_prefix = '__Host-BPMS'; The browser rejects cookies because they are not being served correctly by (I think) mantisbt. If I revert the update, changing the mantisbt link to the previous version in the web server directory, everything works correctly.
Steps To Reproduce	Update to 2.28.0 with "__Host-SOMETHING" cookie prefix and try to login or (if already logged) try to change project.
Additional Information	https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Set-Cookie#cookie_prefixes Secure-: Cookies with names starting with Secure- must be set with the Secure attribute by a secure page (HTTPS). Host-: Cookies with names starting with Host- must be set with the Secure attribute by a secure page (HTTPS). In addition, they must not have a Domain attribute specified, and the Path attribute must be set to /. This guarantees that such cookies are only sent to the host that set them, and not to any other host on the domain. It also guarantees that they are set host-wide and cannot be overridden on any path on that host. This combination yields a cookie that is as close as can be to treating the origin as a security boundary.
Tags	No tags attached.
Attached Files	mantis-cookie.png (53,639 bytes) mantis-cookie.png (53,639 bytes)

ThecaTTony 2026-01-07 21:17 reporter ~0070707	I forgot to mention that the cookies in the attached screenshot were set using version 2.27.3, while I was testing. I was unable to login with version 2.28.0, all I got was the message: "Your browser either does not know how to handle cookies, or refuses to handle them."

dregad 2026-01-09 13:23 developer ~0070711	Hello @ThecaTTony, thanks for the report. I was not aware of this cookie prefix feature, learn something new everyday... Confirming the bug, as I was able to reproduce the problem. According to git bisect, the regression was introduced by MantisBT master 5393a566 as part of fix for 0035424.

scooterchris 2026-04-02 18:01 reporter ~0070934	We did some debugging and found that in the constructor for MantisPHPSession the variable $g_cookie_secure_flag_enabled seems to be losing it's scope between gpc_api.php and session_api.php. This was apparent when dumping the $t_options array as the 'session' cookie flag was showing as 'null' in version 2.28.0 and showing as 'true' in verison 2.27.3. Our quick fix for this was to make the following change: global $g_cookie_secure_flag_enabled; to $g_cookie_secure_flag_enabled = http_is_protocol_https(); We looked through the change set you mentioned in your previous comment, but couldn't find any apparent reason that would be causing this issue.

dregad 2026-04-06 08:35 developer ~0070942	Thanks for the feedback @scooterchris We looked through the change set you mentioned in your previous comment, but couldn't find any apparent reason that would be causing this issue. To be honest, I did not perform any analysis of what could be causing the problem - I just ran the bisect to identify the offending commit. I do not have time to investigate at the moment. Maybe @raspopov who authored that change can have a look care to comment.

raspopov 2026-04-07 11:21 reporter ~0070947	@dregad You are absolutely right; adding the call `require_api( ‘string_api.php’ );` to the `http_api.php` file causes the chain of `require_api()` calls in the `session_api.php` file to loop back to that same file. This causes the `session_api.php` file to actually execute before the `gpc_api.php` file, even though it seems like it should be the other way around based on the `require_api()` calls. This is the birth of the Ouroboros serpent! It's surprising that this didn't happen sooner, given the significant functional overload of the internal API files. We can revert the changes in `http_api.php`, since they're fairly minor. Ideally, we should add a check inside `require_api()` so that we can identify the “snake.” By the way, when I was looking at the `require_api()` function, I discovered another issue—unnecessary recursive calls to this function, with some pages on the site having a couple dozen more calls than necessary. This happens because the line `$s_api_included[$p_api_name] = 1;` is located AFTER `require_once( $g_core_path . $p_api_name );`, whereas it should be BEFORE it, effectively preventing a recursive call (and the processing of global variables).

dregad 2026-04-07 11:54 developer ~0070948	Thanks for the analysis and feedback @raspopov. IMO reverting changes to http_api.php to remove the string_api dependency is the better approach. It's not worth making require_api() more complex for such a corner case. I'll take care of it. Feel free to open an issue and submit a PR to optimize require_api per your suggestion if you can spare the time.

MantisBT: master-2.28 2ec1b106 2026-04-07 12:02 dregad Details Diff	Revert use of string_url() in http_api.php Requiring string_api.php was causing a circular inclusion pattern of the core APIs, resulting in rejection of Secure Cookies by the browser. Partial revert of commit 5393a5663d33a0060d13ee0d4517bb701ddac40d. Fixes 0036819		Affected Issues 0036819
	mod - core/http_api.php		Diff File