[security] Piwigo should use https for authentication #193

New Issue

2026-10-04T23:46:33+02:00

adam commented

2026-10-04 23:46:33 +02:00

Reported by jeremyhu on 12 Jul 2012 01:36

Version: 2.4.1

If a user visits your site (http://mypiwigogallery.com) and registers for an account or logs in with the quickconnect form, their password will be sent unencrypted. Visitors must first manually edit the address in their browser's address bar (something I doubt more than 0.1% of visitors will do) in order to avoid this issue.

I want visitors to be able to goto my site using http, but use https for authentication. This is also an issue because my SSL cert is self-signed, and I don't want casual visitors and guests to have to accept the self-signed cert

Steps to reproduce: 1) Create a user account.
2) Feel insecure.

Piwigo Bugtracker #2689

**Reported by jeremyhu on 12 Jul 2012 01:36** **Version:** 2.4.1 If a user visits your site (http://mypiwigogallery.com) and registers for an account or logs in with the quickconnect form, their password will be sent unencrypted. Visitors must first manually edit the address in their browser's address bar (something I doubt more than 0.1% of visitors will do) in order to avoid this issue. I want visitors to be able to goto my site using http, but use https for authentication. This is also an issue because my SSL cert is self-signed, and I don't want casual visitors and guests to have to accept the self-signed cert **Steps to reproduce:** 1) Create a user account. 2) Feel insecure. [Piwigo Bugtracker #2689](http://piwigo.org/bugs/view.php?id=2689)

adam closed this issue

2026-10-04 23:46:33 +02:00

adam commented

2026-10-04 23:46:34 +02:00

Comment posted by jeremyhu on 12 Jul 2012 01:45

There should be an option in preferences to use https://... for all forms

The workaround for now seems to be setting the following manually:

identification.php: 'F_LOGIN_ACTION' => 'https://..../identification.php',
password.php: 'form_action'=> 'https://..../password.php',
register.php: 'F_ACTION' => 'https://..../register.php',

**Comment posted by jeremyhu on 12 Jul 2012 01:45** There should be an option in preferences to use https://... for all forms The workaround for now seems to be setting the following manually: identification.php: 'F_LOGIN_ACTION' => 'https://..../identification.php', password.php: 'form_action'=> 'https://..../password.php', register.php: 'F_ACTION' => 'https://..../register.php',

adam commented

2026-10-04 23:46:34 +02:00

Comment posted by jeremyhu on 14 Jul 2012 18:40

This isn't just a bug in the application itself. I just noticed that your http://piwigo.org and http://piwigo.org/bugs sites don't use secure forms for visitors! This is bad!

**Comment posted by jeremyhu on 14 Jul 2012 18:40** This isn't just a bug in the application itself. I just noticed that your http://piwigo.org and http://piwigo.org/bugs sites don't use secure forms for visitors! This is bad!

adam commented

2026-10-04 23:46:35 +02:00

Comment posted by kubrick on 21 Aug 2012 14:22

If I may : +1

**Comment posted by kubrick on 21 Aug 2012 14:22** If I may : +1

adam commented

2026-10-04 23:46:36 +02:00

Comment posted by rvelices on 27 Aug 2012 08:52

??? "This is also an issue because my SSL cert is self-signed" ???
OK I agree we should have a config allowing the registration / identification to be https but for sure it's up to you to have an ssl enabled server with the right certificate ...

**Comment posted by rvelices on 27 Aug 2012 08:52** ??? "This is also an issue because my SSL cert is self-signed" ??? OK I agree we should have a config allowing the registration / identification to be https but for sure it's up to you to have an ssl enabled server with the right certificate ...

adam commented

2026-10-04 23:46:36 +02:00

Comment posted by jeremyhu on 27 Aug 2012 18:09

@rvelices, I think you miss the point. I don't need every visitor to my site to have an encrypted connection. I only need MY administrative connection to be encrypted. Thus I am ok using a self-signed certificate for that. Nobody else needs to use it, so there's no point in paying a CA to sign something only I will be using.

**Comment posted by jeremyhu on 27 Aug 2012 18:09** @rvelices, I think you miss the point. I don't need every visitor to my site to have an encrypted connection. I only need _MY_ administrative connection to be encrypted. Thus I am ok using a self-signed certificate for that. Nobody else needs to use it, so there's no point in paying a CA to sign something only I will be using.

adam commented

2026-10-04 23:46:37 +02:00

Comment posted by rvelices on 27 Aug 2012 18:48

Sorry, but I dont get it. If we change identification/password and register links, this is going to be for everyone.

**Comment posted by rvelices on 27 Aug 2012 18:48** Sorry, but I dont get it. If we change identification/password and register links, this is going to be for everyone.

adam commented

2026-10-04 23:46:38 +02:00

Comment posted by kubrick on 27 Aug 2012 19:23

@jeremyhu: if you're happy with your workaround then I think you're misunderstanding rvelices' statement: all he said was that it wasn't going to solve your self-signed certificate situation, I think he just wanted to make sure you were aware of that. All he's offering is to do what you did with your workaround more easily, which is apparently what you (and I) want.

**Comment posted by kubrick on 27 Aug 2012 19:23** @jeremyhu: if you're happy with your workaround then I think you're misunderstanding rvelices' statement: all he said was that it wasn't going to solve your self-signed certificate situation, I think he just wanted to make sure you were aware of that. All he's offering is to do what you did with your workaround more easily, which is apparently what you (and I) want.

adam commented

2026-10-04 23:46:39 +02:00

Comment posted by jeremyhu on 27 Aug 2012 22:45

Yes, the login/registration links will definitely be https for everyone ... I understand that, and that does fix my problem. That is what I am doing as my workaround currently. Other users don't need to use the login/registration links; I'm the only user that logs in.

What I meant by my self-signing issue is that currently, in order for the links and form target URLs to be https://..., I would need to redirect all http://... traffic to https://... which would then send all my users to the secure site with my self-signed cert. They don't need an encrypted connection because they aren't going to be logging in. In other words, I'm just explaining why the obvious case of "just encrypt everything" doesn't work for me.

**Comment posted by jeremyhu on 27 Aug 2012 22:45** Yes, the login/registration links will definitely be https for _everyone_ ... I understand that, and that does fix my problem. That is what I am doing as my workaround currently. Other users don't need to use the login/registration links; I'm the only user that logs in. What I meant by my self-signing issue is that currently, in order for the links and form target URLs to be https://..., I would need to redirect all http://... traffic to https://... which would then send all my users to the secure site with my self-signed cert. They don't _need_ an encrypted connection because they aren't going to be logging in. In other words, I'm just explaining why the obvious case of "just encrypt everything" doesn't work for me.

adam commented

2026-10-04 23:46:39 +02:00

Comment posted by norbert on 30 Apr 2013 00:48

As posted on the forum, please see http://codex.wordpress.org/Administration_Over_SSL for a nice way to implement this. Two independent options, one for login over ssl, one for admin over ssl.

Of course, setting up ssl certificates etc is not the problem here, that is up to the hoster.

**Comment posted by norbert on 30 Apr 2013 00:48** As posted on the forum, please see http://codex.wordpress.org/Administration_Over_SSL for a nice way to implement this. Two independent options, one for login over ssl, one for admin over ssl. Of course, setting up ssl certificates etc is not the problem here, that is up to the hoster.

adam commented

2026-10-04 23:46:40 +02:00

Note that you need to force https on the whole domain.
If you just force https for the login, you can't set the secure flag on Cookies and that's a bad practice.
Issuing valid cert's shouldn't be a problem anymore since Let's Encrypt is available.

Note that you need to force https on the whole domain. If you just force https for the login, you can't set the secure flag on Cookies and that's a bad practice. Issuing valid cert's shouldn't be a problem anymore since Let's Encrypt is available.

adam commented

2026-10-04 23:46:41 +02:00

@J0WI Except that lets encrypt still can't be used for certain stuff like payments and other things. As was said before LetsEncrypt is still in beta and you should really think about what else is going to be on said domain before you decide to just force https on the whole domain using LetsEncrypt.

Also another thing that's bad practice which almost "everyone does" is using the same password on more than one site.

Also this issue is for the piwigo source code and not the piwigo domain itself unlike https://github.com/Piwigo/Piwigo/issues/464 which really should be placed on piwigo's forums and not here.

@J0WI Except that lets encrypt still can't be used for certain stuff like payments and other things. As was said before LetsEncrypt is still in beta and you should really think about what else is going to be on said domain before you decide to just force https on the whole domain using LetsEncrypt. Also another thing that's bad practice which almost "everyone does" is using the same password on more than one site. Also this issue is for the piwigo source code and not the piwigo domain itself unlike https://github.com/Piwigo/Piwigo/issues/464 which really should be placed on piwigo's forums and not here.

adam commented

2026-10-04 23:46:41 +02:00

@JOWI Let's Encrypt might be a nice solution to get SSL on every domain, this is not a Piwigo issue. We have a plugin "Force HTTPS" http://piwigo.org/ext/extension_view.php?eid=697 that looks like what you need.

What this plugin doesn't do is a simple "force HTTPS on authentication", ie the possibility to browse a Piwigo in HTTP anonymously and force login (including admins) on HTTPS.

@JOWI Let's Encrypt might be a nice solution to get SSL on every domain, this is not a Piwigo issue. We have a plugin "Force HTTPS" http://piwigo.org/ext/extension_view.php?eid=697 that looks like what you need. What this plugin doesn't do is a simple "force HTTPS on authentication", ie the possibility to browse a Piwigo in HTTP anonymously and force login (including admins) on HTTPS.

adam commented

2026-10-04 23:46:42 +02:00

I came across this thread searching for answer to issue i have viewing photos in albums. I have a secure padlock connection when i load piwigo page up to the point when I authenticate then the padlock disappears and I cannot view photos on iPad. The page https://www.mywebsite.com/piwigo/identification.php is secure but as soon as I login the site is then insecure.
I have added the
identification.php: 'F_LOGIN_ACTION' => 'https://..../identification.php',
password.php: 'form_action'=> 'https://..../password.php',
register.php: 'F_ACTION' => 'https://..../register.php',
parameters detailed above.
I have also added the Force HTTPS plugin which was working but now states that the web hosting server does not accept HTTPS and disables the plugin? Not sure why this has suddenly changed.
I have also checked the whole website for insecure and mixed content and resolved all http references.
I feel very close to a solution but I do not understand why the site resorts to insecure after I authenticate using the login option.
If anyone can assist would be greatly appreciated.

I came across this thread searching for answer to issue i have viewing photos in albums. I have a secure padlock connection when i load piwigo page up to the point when I authenticate then the padlock disappears and I cannot view photos on iPad. The page https://www.mywebsite.com/piwigo/identification.php is secure but as soon as I login the site is then insecure. I have added the identification.php: 'F_LOGIN_ACTION' => 'https://..../identification.php', password.php: 'form_action'=> 'https://..../password.php', register.php: 'F_ACTION' => 'https://..../register.php', parameters detailed above. I have also added the Force HTTPS plugin which was working but now states that the web hosting server does not accept HTTPS and disables the plugin? Not sure why this has suddenly changed. I have also checked the whole website for insecure and mixed content and resolved all http references. I feel very close to a solution but I do not understand why the site resorts to insecure after I authenticate using the login option. If anyone can assist would be greatly appreciated.

adam commented

2026-10-04 23:46:43 +02:00

Asking piwigo to secure your webserver isn't very logical. You should enforce TLS via server level configuration (apache conf/nginx conf), e.g. this guide (written for a synology hosted server, but the nginx conf configuration should work for anyone I think):
https://community.synology.com/enu/forum/16/post/123759?page=1&sort=oldest

Asking piwigo to secure your webserver isn't very logical. You should enforce TLS via server level configuration (apache conf/nginx conf), e.g. this guide (written for a synology hosted server, but the nginx conf configuration should work for anyone I think): https://community.synology.com/enu/forum/16/post/123759?page=1&sort=oldest

adam commented

2026-10-04 23:46:44 +02:00

All websites should be HTTPS nowadays. This is not a Piwigo issue.

Issue closed.

All websites should be HTTPS nowadays. This is not a Piwigo issue. Issue closed.

Sign in to join this conversation.

master

issue-2560-people

translation

16.x

feat/embedding-based-contextual-tagging

issue-2576-search-include-ai-in-search-results

feat/search-ocr-ai

issue-2391-update-menu-design

15.x

detect-container

issue-2386-update-filters-users-activity

issue-2362-add-filters-options-in-admin

issue-2367-imagemagick7

issue-2225-quicksearch-help

14.x

issue-2164-BatchManagerUnitMode-Redesign

13.x

12.x

issue-1657-SVG_Support

issue-1703-historySearchMethod

11.x

2.10

2.9

2.8

2.7

2.5

2.6

2.4

2.3

2.2

2.1

2.0

1.7

1.3

1.6

1.5

1.4

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/Piwigo#193