Data too long for column 'password'

Omeka Classic
1

I’ve got a site with 192 users, running Omeka Classic 3.2, and am getting the following error when attempting to login. This appears to impact all users. In looking at the database configurations, it appears that the password column is set to varchar(40) / utf8mb3_unicode_ci, rather than varchar(255) / ascii_bin as one might expect just from looking at other unaffected Omeka databases on the same server. I don’t know if this issue resulted from an upgrade-related bug, or maybe a hosting issue. Any insights would be helpful, thanks.

Zend_Db_Statement_Mysqli_Exception: Mysqli statement execute error : Data too long for column 'password' at row 1 in .../application/libraries/Zend/Db/Statement/Mysqli.php:215
Stack trace:
#0 .../application/libraries/Zend/Db/Statement.php(303): Zend_Db_Statement_Mysqli->_execute(Array)
#1 .../application/libraries/Zend/Db/Adapter/Abstract.php(480): Zend_Db_Statement->execute(Array)
#2 .../application/libraries/Omeka/Db.php(80): Zend_Db_Adapter_Abstract->query('INSERT INTO `om...', Array)
#3 .../application/libraries/Omeka/Db.php(257): Omeka_Db->__call('query', Array)
#4 .../application/libraries/Omeka/Record/AbstractRecord.php(542): Omeka_Db->insert('omeka_users', Array)
#5 .../application/models/User.php(233): Omeka_Record_AbstractRecord->save()
#6 .../application/controllers/UsersController.php(429): User::upgradeHashedPassword('[user name]', '[password]')
#7 .../application/libraries/Zend/Controller/Action.php(516): UsersController->loginAction()
#8 .../application/libraries/Zend/Controller/Dispatcher/Standard.php(308): Zend_Controller_Action->dispatch('loginAction')
#9 .../application/libraries/Zend/Controller/Front.php(954): Zend_Controller_Dispatcher_Standard->dispatch(Object(Zend_Controller_Request_Http), Object(Zend_Controller_Response_Http))
#10 .../application/libraries/Zend/Application/Bootstrap/Bootstrap.php(106): Zend_Controller_Front->dispatch()
#11 .../application/libraries/Zend/Application.php(384): Zend_Application_Bootstrap_Bootstrap->run()
#12 .../application/libraries/Omeka/Application.php(73): Zend_Application->run()
#13 .../admin/index.php(28): Omeka_Application->run()
#14 {main}

Manually reverting the column structure does solve the problem, though it would still be nice to know why this might have happened.

`ALTER TABLE `omeka_users` CHANGE `password` `password` VARCHAR(255) CHARACTER SET ascii COLLATE ascii_bin NULL DEFAULT NULL;`
2

The upgrade to 3.2 should change the column there to 255 length and the ascii_bin collation, as you’re seeing on your other sites. I’d imagine this either means the upgrade was skipped, or undone after the fact. You might check what version the database says it is (in the options table, the “omeka_version” option) and which migrations it says have been done (the schema_migrations table, compare to the numbers in the application/migrations folder, for example 20240717204800 is the migration that makes this change).

3

Version 3.2 confirmed, but the highest number in scheme_migrations is 20200127165700. I do see the file 20240717204800_growUserPassword.php but I guess it did not run/complete for some reason?

4

(This was an automatic update via Installatron by the way)

5

My guess is that your database already was marked as being at 3.2 before the upgrade (whether the database was just like that to begin with or Installatron or something else changed that version option, I don’t know; a pre-upgrade backup of the database would show if the version option was already set to 3.2).

If the version option in the database is already “current” then you won’t get prompted to run the upgrades, which matches with what you’re seeing where none of the migrations ran. You could set the version option back to 3.1 and then you should get redirected to the page to run the database upgrade like usual.

6

Ok, looks like the simplest solution was to set the omeka_version number back to 3.1.2 in the _options database table. The _schema_migrations table now includes the recent updates. Thanks for your help!

7

Thank you for this thread. I just found the same occurrence in one of my Classic installs.