I am developing an external authentication module, but if core module "profile" is enabled, it generates these errors:
* warning: array_fill() [function.array-fill]: Number of elements must be positive in D:\Web\wwwroot\extauth\includes\database.inc on line 235.
* warning: implode() [function.implode]: Bad arguments. in D:\Web\wwwroot\extauth\includes\database.inc on line 235.
* warning: array_keys() [function.array-keys]: The first argument should be an array in D:\Web\wwwroot\extauth\modules\user\user.module on line 500.
* user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ')' at line 1 query: SELECT p.perm FROM role r INNER JOIN permission p ON p.rid = r.rid WHERE r.rid IN () in D:\Web\wwwroot\extauth\modules\user\user.module on line 500.

I attached my simplified module that raises these errors. But only if profile module is enabled!

This bug looks very similar to this one in 5.x:
http://drupal.org/node/165642

Windows XP SP2
Apache 2.0.59
PHP 5.2.4
MySQL 5.0.27
Druapl 6.0

CommentFileSizeAuthor
#3 profile_get_fields.patch468 bytesPaul Natsuo Kishimoto

Comments

edgarpe’s picture

edgarpe commented

Hm, I don't see my attachment, so here it is:

function extauth_form_alter(&$form, $form_state, $form_id) {
  if ($form_id == 'user_login' or $form_id == 'user_login_block') {
    $form['#validate'] = array ( 
      0 => 'user_login_name_validate', 
      1 => 'extauth_authenticate', 
      2 => 'user_login_authenticate_validate', 
      3 => 'user_login_final_validate', 
    );
  }
}

// everybody is welcome, with password '123'
function extauth_authenticate($form, &$form_state) {
  if ($form_state['values']['pass'] == '123') {
    user_external_login_register($form_state['values']['name'], 'extauth');
  }
}
Paul Natsuo Kishimoto’s picture

Paul Natsuo Kishimoto commented
Component: user system » profile.module

I am experiencing the same PHP errors with the 6.x-dev version of webserver_auth. The errors occur only on the first login; i.e. when the user is created.

Line 500 of user.module is in user_access(), so I tried to figure out where that was being called:

Why is this a problem? When the second argument of user_access is unspecified, it tries to use the $user global. We are still inside user_save() at this point, which, from examining the code, does not appear to access or modify the $user global. This is done by user_external_login_register(), which assigns the result of user_save() to the $user global. Before then, the global still has the FALSE value returned by user_load(). The attempt in user_access() to do array operations on $user->roles property then fails.

So this appears to be a bug in profile.module, because it's calling user_access() at a point when it can't be sure the $user global is appropriately populated; and I don't think it's the intent of the developers for user_access() to resolve that kind of ambiguous situation.

Thanks for the bit about profile.module, EdgarPE... I would have been stumped without that clue. I'll try to find a fix.

Paul Natsuo Kishimoto’s picture

Paul Natsuo Kishimoto commented
Assigned: Unassigned » Paul Natsuo Kishimoto
Status: Active » Needs review
StatusFileSize
new profile_get_fields.patch468 bytes

A patch is attached. The errors appear to be gone.

moshe weitzman’s picture

moshe weitzman commented
Status: Needs review » Reviewed & tested by the community

This looks like the least invasive fix that makes sense. More invasive would be changes to user_save() which we don't really want.

damien tournoud’s picture

damien tournoud commented
Status: Reviewed & tested by the community » Closed (duplicate)

Sorry, but we need to fix user_external_login_register(), so that it didn't mess with the global $user if user_load fails.

This is a duplicate of #165642: error in SQL syntax in user.module on line 368 (or 378).