By Boinng on

I'm converting my Postnuke site to Drupal and thought I had the users table pretty much licked, but I've come accross an odd new problem. Logged in as admin (either as user 1 or myself in "god" role) I can see any other user's account page by clicking on their name or going directly to ?q=user/[uid], but when logged in as just a regular authenticated user most account pages return a "Page not found".

This doesn't appear to be an authorisation problem since it's "Page not found" and not "Access denied", and all users have their authorisation set correctly in user_roles.

The clue to this is probably in the fact that once one of these users (imported from the Postnuke site) actually logs into the new site, their account page is then visible again to all users. But many of these user accounts date back years and it's quite possible (sadly) that some of them won't ever come back to log into the new site, so that's not really a solution... anyone have any idea what's going on?

⋅ Categories: Drupal 4.7.x

Comments

geodaniel’s picture

geodaniel commented

I'd suggest checking in the database to see what the difference is between the users that have logged in and the ones that haven't. I presume you've copied their info directly into the users table in Drupal?

Maybe there is a field that gets filled in when they first log in to the new system - perhaps the updated date? - that you could try setting?

Boinng’s picture

Boinng commented

Fairly simple in the end, as you suggested - the imported users had nothing in the access or login fields (both of which require a date). I set these both the same as the created date, and voila - no more Not Found's.

jmarkantes’s picture

jmarkantes commented

I had the same issue with a clean 4.7 install- anon users would get a 404 page not found when viewing user profiles. Searched the forums and found this post, and was able to correct it.

The issue was that the anon user (uid 0) had nothing in the access and login fields in the db table. Set those to a similar value in the other users and everything works right now.

J

robjohnston’s picture

robjohnston commented

I'm working on a new site with 4.7.2 installed. I followed the suggestions above and added values for created, access, and login fields with no change. Have verified that access permissions are correct, and have played with adding other data to the anonymous user record, with no progress.

Any other suggestions?

---------
Rob Johnston

mquesada’s picture

mquesada commented

The suggestion worked for me, I just changed the access column default value in the users table to 1 and then I updated the columns that has 0 to 1. I don't think it actually matters that the user hasn't logged in because if other users can see their profile then they can invite them to join and use the site.

Hope this helps!!

CarAddict’s picture

CarAddict commented

User pages come up with page not found error only when the user has never logged in(last access = never).

Once the user logs in, the users page is available.

Problem does not occur with admin user.

Thought for sure there would have been a fix/workaround for this, but I can't find it.

Might have to do a search replace in the Users table - Access field and change those 0 entries as some people will never login.

jmarkantes@drupal.org’s picture

jmarkantes@drupal.org commented

I replied to this thread a while back, and still never found an answer. But, I did recently discover another interesting thing to note:

On certain users I'm getting a 404 not found when viewing their profile as an anonymous user. So I did the usual, and set the 'login' and 'access' fields in the user table to something non-zero. No luck.

However I'm noticing that the 404 I'm getting is not recorded in the log. I thought that was interesting.

Just wanted to update this thread in case anyone's searching and seeing this. I'll keep poking and update when I learn more.

J

jmarkantes@drupal.org’s picture

jmarkantes@drupal.org commented

Just gotta clear the cache.

Dammit, didn't do that in between changing the login and acces fields. So I don't know which one is the solution, one or the other. Probably access. But that's just what the login field wants us to believe... that cheeky bastard. I tell you, I don't trust either one of them. Sure, they sound innocent. "Oh, I just remember the last time you accessed a page, that's all." Or "Wait, I just remembered the last time you logged in!". Sure, watching over my shoulder. Like a STALKER.

Hey, wait, that's like a status symbol these days. I'm famous! This is awesome!

I gotta stop late-night-drunk-coding.
J

CarAddict’s picture

CarAddict commented

For users who have not logged in, in the Users table, I have copied across the value in the "created" field to the "access" field.

No problems with cache, the problem is instantly fixed.

Will need to create an SQL query to check if access = 0 then copy created field to access field. But my SQL is not that strong, so will be put on the back burner. Ideally it would be a good idea to add this workaround to cron.

3dsoft’s picture

3dsoft commented

Hi,
does anybody got this SQL query to check if access = 0, yet?
thanks for any help

horse ranch
-----------------
www.joelle.de

wmswms’s picture

wmswms commented

Well to see if someone has a 0 access time:

SELECT * FROM users WHERE access = 0

And to fix those:

UPDATE users SET access = created WHERE access = 0

anonymous562’s picture

anonymous562 commented

I am having the same issue -- is there a way that this can be done automatically, instead of having to run a SQL query every once in a while? I'm going to hand over this site to someone who's not very technical (and I'm not even that proficient with SQL), and they wouldn't be able to perform the queries.

Any other solutions?

cameron tod’s picture

cameron tod commented

This problem confused me for a while until I found this thread. The real issue here is not that it happens, but that it is logged as a 404 and not an access denied. It's difficult to debug without actually poking around in the user module.

I'm going to log a bug to change the call in user_view from drupal_page_not_found to drupal_access_denied or something like that.

jacoblane’s picture

jacoblane commented

I had this same problem and updated all 'access' and 'login' fields and refreshed the cache.
Now all site users (authenticated and anonymous) can access user profiles; however, the profile page for users that have not really logged in is very slow. This is the case no matter who is trying to access the profile (admin, anonymous, etc.). The response time for profile pages of users that have actually logged in is fine.
I am running Drupal 5 as well as the LDAP Authentication module.
Any ideas?

jacoblane’s picture

jacoblane commented

I resolved this problem by disabling the ldap_data module.

jenlampton’s picture

jenlampton
she / her
commented

Ok, so this MySQL solution changes the db to make the problem disappear for a while, but I think the real issue here is that somewhere something is checking if user.access is 0, and that result determines whether anon users can see other user's pages. That's what needs to be fixed, not the state of the db.

*~ current projects: www.customerthink.com ~*

rfay’s picture

rfay
he,him
Primary language English
Location Palisade, CO, USA
commented

This is actually written right into the code. (Drupal 5.3, user.module, lines 1507-1513):

function user_view($uid = 0) {
  global $user;

  $account = user_load(array('uid' => $uid));
  if ($account === FALSE || ($account->access == 0 && !user_access('administer users'))) {
    return drupal_not_found();
  }

Note that if $account->access is 0, and the requesting user does not have admin privileges, the request is turned into a 404.

Now the question is: WHY? There must be some history here...

I did check on a plain-jane drupal5 install, and access is actually 0 until the user logs in; it's not being inappropriately set by some rogue module.

dman’s picture

dman commented

My guess it was spam-bot fighting.
No point creating/allowing a page for an individual that never even logged in.
... pure speculation.

Actually that's pretty nifty to know, as I (for dark reasons) auto-subscribed an entire mailing list of people that never asked for an account. They don't deserve user pages.

(it was a non-profit action group who had requested to be added to the 'mailing list, so I used Drupal to send them updates using mass-mail)

.dan.
How to troubleshoot Drupal | http://www.coders.co.nz/

.dan. is the New Zealand Drupal Developer working on Government Web Standards

rfay’s picture

rfay
he,him
Primary language English
Location Palisade, CO, USA
commented

I'm experimenting with this in a key module's hook_user() op=='save' code.

Basically, it checks to see if the user is being unblocked for the first time, and if so, it sets the access time to the created time, avoiding the lockout of the profile.

// hook_module() $op == 'save' function
function wsuser_save(&$edit, &$user, $category) {
	$user = user_load(array('uid'=>$user->uid));
	// Default drupal behavior has the user profile unavailable for view until a login
	// (until access>0). Instead, we want to make it available immediately, since it's
	// been screened by an admin already.
	if ($user->status == 0 && $edit['status'] == 1 && !$user->access) { 
		db_query("update users set access=created where uid=%d",$user->uid);
	}
rinogo’s picture

rinogo commented

Note to Drupal 5 users - the op is 'insert' instead of 'save', and you may not need all of those 'if' conditions.

Pushkar Gaikwad’s picture

Pushkar Gaikwad commented

I made
if ($account === FALSE || ($account->access == 0 && !user_access('administer users'))) {

to

if ($account === FALSE || (!user_access('administer users')) {

and uploaded the user.module and got white screen of death! Just wondering what is the safest way to edit the user.module file ?

joancatala’s picture

joancatala commented

I tried many things... I read the user.module but I didn't find a solution.
At the end... I modified the SQL sentence of the Drupal database and everything works fine! :-)
In the default value '0' of access and login... put '1'. Easy and simple.

I did:

* mysqldum MY_DATABASE > my_copy.sql
* I deleted my database.
* I created a new one.
* mysql NEW_DATABASE_WHITE < my_copy.sql

And... this works!!!!