user_service.inc line 92
when user_authenticate() fails, it doesn't return a user object, so when the assignment occurs, the $user becomes null, which causes php errors.
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | 891520-user_login-fix.patch | 1.04 KB | dawehner |
user_service.inc line 92
when user_authenticate() fails, it doesn't return a user object, so when the assignment occurs, the $user becomes null, which causes php errors.
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | 891520-user_login-fix.patch | 1.04 KB | dawehner |
Comments
Comment #1
skyredwangThe PHP errors are caused by Views module:
function views_check_rolesThe BlogAPI module does the same thing as Services module: try to authenticate an account, and assign the result back to the global $user. However, if the user didn't succeed in logging in, then there is no $user object. That's why Views throw errors.
Since BlogAPI and Services use
user_authenticate()in the same way, I mark this as a Views bug.Comment #2
merlinofchaos commentedI don't understand this. You're talking about user_authenticate() -- how is Views even involved?
Comment #3
skyredwangI haven't tested BlogAPI, but for a service request, Services don't call
views_check_roles, but somehowviews_check_rolesgets called. In this particular example,user_authenticate()doesn't return a user object when the username or password is wrong, thereforeviews_check_rolesthrows errors.any idea why
views_check_rolesgets called in a service request indirectly?Comment #4
dawehnerviews_check_roles is called for the access plugin. I'm not sure whether it makes sense for services module to check access to a view,
but it might be possible.
Comment #5
skyredwangIt seems that
views_check_rolesusesglobal $useras its fall back plan, and assumes that$useris a legit object. However, both BlogAPI and Services has something like$user = $user = user_authenticate(array('name' => $username, 'pass' => $password));, whose return is not always a user object.I hope you guys could offer more advice, since I don't know enough about Views
Comment #6
dawehnerBased on http://api.drupal.org/api/global/user i think we can assume that it always has this data.
Comment #7
iamjon commentedI'm marking this as closed to due to lack of activity.
skyredwang, please feel free to reopen this issue if you would like to add more information or if you need more clarification.
Comment #8
iamjon commentedComment #9
skyredwangaccording to http://api.drupal.org/api/drupal/modules--user--user.module/function/use...,
user_authenticatedoes not always return a user object. So Views need to check if $user is empty or not?Comment #10
iamjon commentedAssigning this to merlinofchaos for followup
Comment #11
dawehnerHere here is a patch for this issue
Not sure whether return false is the right answer to an empty user object.
I'm 100% convinced that this empty user object causes a lot of modules to brake.
Comment #12
kattekrab commentedI'm doing a conference talk about views, so was looking through the queue and found this incredibly old issue.
I doubt the patch from 6 years ago is even vaguely relevant anymore, or if this is even still an issue that needs addressing.
Should we close this? Or is it worth re-rolling the patch and taking another look?
Comment #13
damienmckennaFirst off, PHP errors aren't "critical". Secondly, this is for D6, which is officially unsupported.
That said, I'll second @katekrab's question - is anyone still hitting this error?
Comment #14
skyredwangNo. we don't care about D6 services anymore.