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.

CommentFileSizeAuthor
#11 891520-user_login-fix.patch1.04 KBdawehner

Comments

skyredwang’s picture

Project: Services » Views (for Drupal 7)
Version: 6.x-2.2 » 6.x-2.x-dev

The PHP errors are caused by Views module: function views_check_roles

The 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.

merlinofchaos’s picture

I don't understand this. You're talking about user_authenticate() -- how is Views even involved?

skyredwang’s picture

I haven't tested BlogAPI, but for a service request, Services don't call views_check_roles, but somehow views_check_roles gets called. In this particular example, user_authenticate() doesn't return a user object when the username or password is wrong, therefore views_check_roles throws errors.

any idea why views_check_roles gets called in a service request indirectly?

dawehner’s picture

views_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.

skyredwang’s picture

It seems that views_check_roles uses global $user as its fall back plan, and assumes that $user is 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

dawehner’s picture

Based on http://api.drupal.org/api/global/user i think we can assume that it always has this data.

iamjon’s picture

I'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.

iamjon’s picture

Status: Active » Closed (works as designed)
skyredwang’s picture

Status: Closed (works as designed) » Active

according to http://api.drupal.org/api/drupal/modules--user--user.module/function/use..., user_authenticate does not always return a user object. So Views need to check if $user is empty or not?

iamjon’s picture

Assigned: Unassigned » merlinofchaos

Assigning this to merlinofchaos for followup

dawehner’s picture

Status: Active » Needs review
StatusFileSize
new1.04 KB

Here 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.

kattekrab’s picture

Issue summary: View changes

I'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?

damienmckenna’s picture

Priority: Critical » Major

First 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?

skyredwang’s picture

Status: Needs review » Closed (outdated)

No. we don't care about D6 services anymore.