This issue arose from Drupal beta 12 because it now uses the utf8mb4_general_ci DB collation, which makes halves the potential key lengths.
A possible fix is to halve both the pgt and pgt_iou field lengths from 255 to 127. The CAS protocol defines Proxy-granting tickets and IOUs as being 64 chars long, but "recommends" supporting up to 256 chars in length.
exception 'PDOException' with message 'SQLSTATE[42000]: Syntax error
or access violation: 1071 Specified key was too long; max key length
is 767 bytes' in
/vagrant/app/core/lib/Drupal/Core/Database/Statement.php:61
Stack trace:
#0 /vagrant/app/core/lib/Drupal/Core/Database/Statement.php(61):
PDOStatement->execute(Array)
#1 /vagrant/app/core/lib/Drupal/Core/Database/Connection.php(548):
Drupal\Core\Database\Statement->execute(Array, Array)
#2 /vagrant/app/core/lib/Drupal/Core/Database/Schema.php(522):
Drupal\Core\Database\Connection->query('CREATE TABLE {c...')
#3 /vagrant/app/core/includes/database.inc(435):
Drupal\Core\Database\Schema->createTable('cas_pgt_storage', Array)
#4 /vagrant/app/core/includes/schema.inc(124):
db_create_table('cas_pgt_storage', Array)
#5
/vagrant/app/core/lib/Drupal/Core/Extension/ModuleInstaller.php(212):
drupal_install_schema('cas')
#6 /vagrant/app/core/includes/install.core.inc(1887):
Drupal\Core\Extension\ModuleInstaller->install(Array, false)
#7 [internal function]: _install_module_batch('cas', 'CAS', Array)
#8 /vagrant/app/core/includes/batch.inc(260):
call_user_func_array('_install_module...', Array)
#9 /vagrant/app/core/includes/form.inc(850): _batch_process()
#10 /vagrant/app/core/includes/install.core.inc(607):
batch_process(Object(Drupal\Core\Url), Object(Drupal\Core\Url))
#11 /vagrant/app/core/includes/install.core.inc(528):
install_run_task(Array, Array)
#12 /vagrant/app/core/includes/install.core.inc(117):
install_run_tasks(Array)
#13 /vagrant/vendor/drush/drush/includes/drush.inc(720):
install_drupal(Object(Composer\Autoload\ClassLoader), Array)
#14 /vagrant/vendor/drush/drush/includes/drush.inc(705):
drush_call_user_func_array('install_drupal', Array)
#15
/vagrant/vendor/drush/drush/commands/core/drupal/site_install.inc(78):
drush_op('install_drupal', Object(Composer\Autoload\ClassLoader),
Array)
#16
/vagrant/vendor/drush/drush/commands/core/site_install.drush.inc(289):
drush_core_site_install_version('ua', Array)
#17 [internal function]: drush_core_site_install('ua')
#18 /vagrant/vendor/drush/drush/includes/command.inc(359):
call_user_func_array('drush_core_site...', Array)
#19 /vagrant/vendor/drush/drush/includes/command.inc(210):
_drush_invoke_hooks(Array, Array)
#20 [internal function]: drush_command('ua')
#21 /vagrant/vendor/drush/drush/includes/command.inc(178):
call_user_func_array('drush_command', Array)
#22 /vagrant/vendor/drush/drush/lib/Drush/Boot/BaseBoot.php(62):
drush_dispatch(Array)
#23 /vagrant/vendor/drush/drush/drush.php(70):
Drush\Boot\BaseBoot->bootstrap_and_dispatch()
#24 /vagrant/vendor/drush/drush/drush.php(11): drush_main()
#25 {main}
Next exception 'Drupal\Core\Database\DatabaseExceptionWrapper' with
message 'SQLSTATE[42000]: Syntax error or access violation: 1071
Specified key was too long; max key length is 767 bytes: CREATE TABLE
{cas_pgt_storage} (
`pgt_iou` VARCHAR(255) NOT NULL COMMENT 'PGTIOU is the key returned
from the CAS server for the PGT',
`pgt` VARCHAR(255) NOT NULL COMMENT 'The actual ProxyGrantingTicket
value.',
`timestamp` INT NOT NULL COMMENT 'Created time. Used to delete
unused, stale PGTs',
PRIMARY KEY (`pgt_iou`),
UNIQUE KEY `pgtiou_pgt` (`pgt_iou`, `pgt`)
) ENGINE = InnoDB DEFAULT CHARACTER SET utf8mb4 COMMENT 'Stores
PGT/PGTIOU relationships.'; Array
(
)
' in /vagrant/app/core/lib/Drupal/Core/Database/Connection.php:609
Comments
Comment #1
caseyfw commentedShrink pgt and pgt_iou to lengths to 127, which is still much larger than the 64 characters defined by the CAS protocol, but smaller than the 256 chars it "recommends".
Comment #2
yalet commentedI'd prefer to continue to support the full 256 character pgt length, so I think some hashing is in order.
Comment #3
yalet commentedI think we can get away with changing the type from 'varchar' to 'varchar_ascii'. This would allow us to keep the length, at the expense of not allowing tickets with non-ascii characters in them. The CAS spec says nothing about the characters that are allowed in tickets, but I don't think this is a problem.
Comment #4
ravenstar commentedIt looks like the CAS 3.0 spec restricts the ticket character set to [-A-Za-z0-9] (section 3.7), so varchar_ascii should be fine.
Comment #5
yalet commentedHere is a patch that makes the fields varchar_ascii (and raises the length from 255 to 256).
Comment #6
pingers commentedSounds fine to me! I'll test and report back... thanks!
Comment #7
pingers commentedPatch #5 also worked great in our build.
Comment #8
yalet commentedCommitted. Thanks everyone.