Cannot login more than once per user

PHPMaker General Discussion (PHPMaker)
1

After updating to v2025 I cannot login more than once per user.

Subsequent logins fail.

Hashed password (deprecated) - Enabled
Encrypt usernames and passwords - Enabled
Migrate password algorithm - Enabled
Password algorithm - bcrypt
And both encryption keys are filled in properly.

I was having issues with mfa as well. Logins with mfa were resulting in a blank popup box with an ok button. Disabled it temporarily for testing.

When updating to v2025 I also changed password field to varchar(255) as recommended in the documentation and synced/regenerated the site.

I also cleaned out the webroot so old files from v2024 aren’t in there at all.

2

Can’t really tell your setup from your post but I had these problems when converting a large project to 2025 previously.

Logins

Possibly check “Concurrent Logins” options under Advanced Security?

image
image811×248 11.8 KB

MFA

Also, with MFA, I had a custom setup and converted it to PHPMaker’s version when I upgraded. Required taking the key and re-creating the profile field with the correct JSON format.

3

That usually means there was some unexpected server side error (not caught) so the JavaScript could not get and display. You may:

  1. Press F12 in your browser, go to the Network panel to check HTTP response,
  2. Enable Debug and check the error log.
4

Enabled mfa to test this again.

There is a JS console error “Failed to load resource: the server responded with a status of 502 () login1fa:1”.

5

Disallow concurrent login is off.

Good tip with the profile field. PHPMaker2025 expects longtext instead of text.

However changing it to longtext made it so logins can’t happen at all.

There are no exceptions thrown at all on login attempts, unless MFA is enabled.

7

After further investigation I found I had some nginx errors about header being too large on login which these config lines fixed.

fastcgi_busy_buffers_size 64k;
fastcgi_temp_file_write_size 64k;

However it didn’t solve my login issues.

I then scrolled down in the php logs and found

log.ERROR: Symfony\Component\Security\Core\Exception\BadCredentialsException: The presented password is invalid. in /home/[siteuser]/htdocs/[sitesubdomain]/vendor/symfony/security-http/EventListener/CheckCredentialsListener.php:67

Which happens on any attempted login.

This is without mfa enabled. Need to debug this first.

This is with password changed from char(40) to varchar(255) and with profile field changed from text to longtext. Tried with the original hashed password and also tried resetting to a plaintext one in the db. Also tried clearing the profile field for a test user. Nothing works.

8

Since you use char(40) before, you might have whitespaces in the passwords, try execute an update statement to trim the password values.

9

Thanks, just checked. Sadly going from char(40) to varchar(255) the test user’s password remains identical with no white spaces.

10

I just tried disabling hashed passwords entirely and it works now.

But I cannot keep hashed passwords turned off for production.

So I am at a loss.

11

Simply enable the advanced setting Migrate password algorithm.

12

Hashed passwords don’t work with or without “Migrate password algorithm” turned on. This setting does convert hashed passwords in the DB, but still cannot login.

13

After enabling Migrate password algorithm, the password are hashed, the Hashed password setting (and other old password settings) are no longer relevant.

If you see the passwords are converted to hashed passwords, that means the user did login successfully so the password is migrated.

However, as docs says:

Hashed passwords are 60 characters long, so make sure to allocate enough space for them to be persisted.

You better revert to your original settings first:

  1. Restore the plain passwords in the user table (use your database backup),
  2. Reset the old password settings in your project to use plain password, if you enable Hashed password, the passwords will be migrated incorrectly.
  3. Generate project and make sure users can login. (now you are back to the original settings).
  4. Then make sure the password field size is large enough and then simply enable Migrate password algorithm and generate again.
14

Sorry for the confusion, the original DB uses hashed passwords from PHPMaker 2024 but I still tried to follow your steps. Here’s what I just did:

  1. Restored original database
  2. Change password from char(40) to varchar(255) and profile from text to longtext.
  3. Generated and uploaded PHPMaker 2025 site with hashed passwords and migrate password algorithm disabled.
  4. Can’t login since passwords in the DB are hashed but if I just change a pass in the DB to a random plaintext for a user that works.
  5. Regenerate and upload the site again with same settings but with migrate password algorithm enabled.
  6. Users can’t login regardless of if I keep the passwords the same as original PHPMaker 2024 hashed version or if I change to a plaintext password.
15

To recap:

  1. You should disable Migrate password algorithm first (make sure it is false, an unchecked checkbox like [ ], not the “indeterminate” state like [-]), then restore you project and user table to the original settings until users can login first, i.e. back to your original project settings.
  2. Since you use char(40) before, you might have whitespaces in the passwords, your varchar(255) may contain old password with spaces like 'oldpassword<spaces>' (40 chars). If that is case, you should fix first. (Profile field should be irrelevant regarding to password.)
  3. When you can login normally with your old settings, just enable Migrate password algorithm and generate again.
  4. You may test with a new project first.
16

Doing that and keeping the settings exactly the same from 2024 to 2025 means I can successfully login even when changing char to varchar, also no whitespaces are added to the varchar during the conversion process.

But after doing that, trying to enable “Migrate password algorithm” lets me login once per user, it updates the hash in the db, and then it never lets the user login again which brings us back to the issue when I started this thread.

17

If you have used Activated field, make sure the user is activated. Also enable Debug, login again and then check the error log.

18

I do not use Activated field.

Only error is still

log.ERROR: Symfony\Component\Security\Core\Exception\BadCredentialsException: The presented password is invalid.

in monolog.

No errors in NGINX log and no errors in JS console.

19

I cannot reproduce. If you are a registered user of v2025, you better send your project file and database to support for their testing directly.

20

Upon further investigation it looks like enabling MFA requests the file login1fa which doesn’t exist whether the site is generated with MFA or not which explains my issues with MFA. Perhaps it is related to the hash migration issue as well? From looking at other posts shouldn’t MFA be requesting login2fa not login1fa? I have no custom code related to this.

Also successful logins result in a JS error:

Failed to load resource: the server responded with a status of 502 () api/lookup:1

I also have no custom code related to this. From my understanding PHPMaker 2025 doesn’t use the api folder anymore and the migration steps say to delete that folder which I already did.

The api error seems to be related to an extended search field “Style” on the table users are directed to on login. This field uses a lookup table.

21

Not using the physical “api” folder does not mean the route /api/{action} is not used. (Route is not physical path.) In fact, there is many API actions being used, including lookup. 502 is Bad Gateway error, make sure:

  1. URL rewrite of your web server is properly set up, especially if you using Nginix web server,
  2. Lookup user level permission is enabled for the user, if you use User Level Security.
  3. Enable Debug and check HTTP response and the log to find the server error.