Hi there,
Using latest piwigon version, but I've had this issue for a long time.
I installed piwigo on subfolder
/mysub
I access it at
https://mysub.mydomain.com
The thing is if I try to login from its regular adresss
https://mysub.mydomain.com/identification.php
I get the followin error:
Cookies are blocked or not supported by your browser. You must enable cookies to log in.
If I connect at
https://mysub.mydomain.com/mysub/identification.php (so twice mysub, as subdomain & subfolder)
I can connect.
I've been trying looking in the database, config files, to find if there is any option. I deleted the cookies, set up htaccess redirection, but nothing really works.
Any hints?
Thanks!
Offline
I don't know that answer to this question but I'm wondering if its something in the PHP session setup, like maybe the session.cookie_path or something like that?
Offline
moberley wrote:
I don't know that answer to this question but I'm wondering if its something in the PHP session setup, like maybe the session.cookie_path or something like that?
Thanks for your response! But if it were the php install, I wouldn't be able to use subdomains at all, while I have many.
It's a Piwigo installed a while ago (15 years?) I'm wondering whether something in the database could mess up things?
Offline
I'm just a user so this isn't an official answer from a developer or anything like that.
I'm not familiar with what older versions of the code might have stored in the database but looking at the current version and what happens before login I don't think the problem is coming from there, especially because it would be the same data when you access through the subdirectory path which does work as you said.
That particular error message "Cookies are blocked or not supported by your browser." gets sent from identification.php based on the result of trying to load the Piwigo session cookie from $_COOKIE: "if (!isset($_COOKIE[session_name()]))".
Tracing the code back I believe that cookie should have been setup when session_start() is called in include/common.inc.php which is included at the top of identification.php. The session_name() should have been set by include/functions_session.inc.php which gets included (through include/functions.inc.php) before session_start() in include/common.inc.php. The code that appears to be relevant in include/functions_session.inc.php that sets the session/cookie settings is:
if (isset($conf['session_save_handler'])
and ($conf['session_save_handler'] == 'db')
and defined('PHPWG_INSTALLED'))
{
session_set_save_handler(new PwgSession());
if (function_exists('ini_set'))
{
ini_set('session.use_cookies', $conf['session_use_cookies']);
ini_set('session.use_only_cookies', $conf['session_use_only_cookies']);
ini_set('session.use_trans_sid', intval($conf['session_use_trans_sid']));
ini_set('session.cookie_httponly', 1);
}
session_name($conf['session_name']);
session_set_cookie_params(0, cookie_path());
register_shutdown_function('session_write_close');
}The various $conf settings should be coming from either include/config_default.inc.php or the local/config/config.inc.php if they have been changed locally. I don't think they would be affected by the database but maybe there is something I have missed.
The setting that got me wondering was "session_set_cookie_params(0, cookie_path());". The PHP cookie_path() function should be returning the default value of "/" but because you don't get the warning when you connect via the subdirectory it makes me wonder if it is being changed somewhere in the chain resulting in the cookie not being present on the root URL path. (You could inspect the pwg_id session cookie in your browser dev tools to see what parameters it has.)
On the other hand, maybe trying to switch the other $conf settings ('session_use_cookies', 'session_use_only_cookies', and 'session.use_trans_sid') in your local config might help. Unfortunately, I don't know enough about the code to fully understand the implications of doing that would be but they exist as configuration variables so they can be changed easily.
Last edited by moberley (2025-12-03 19:02:53)
Offline
I thank you again for trying to help ;)
I actually tried to install again from scratch a new Piwigo. New install, new database, but same cookies problem.
I guess Piwigo doesn't like much my server.
Thanks again for sharing your investigation. I actually also try to play with the cookies settings in the config files, but no luck.
Offline
question: is your Piwigo behind a reverse-proxy? how is your nginx/apache configuration? (what is your "root" parameter in your web server configuration)
Offline
1/ No reverse proxy, afaik. Standard 443 port.
2/ I can share by message the full PHP configuration. The subfolder is redirected to a subdomain in a htaccess:
RewriteCond %{HTTP_HOST} ^photos\.mysite\.com$
RewriteCond %{REQUEST_URI} !^/photos/
RewriteRule (.*)$ photos/$1
Let me know how I can send you the php config.
Offline