[fixed] Registered users posting as guests

[mickmel]

For the last few days, I've had about a half-dozen users complaining that their posts are showing as guests, when they shouldn't be. I think this started with the 2.2.6 upgrade, but it may have started just before I upgraded - I'm not sure.

What happens is that a lot of our users simply type their username and password at the top of each post, and that credits the post to them. Lately, they do that, but the post credits to their username, but as a guest. Obviously, I allow guests to post on the boards, but it never did this before. If their password was incorrect, shouldn't it tell them that? Also, I didn't think guests could use a "username" that was in use by a real member.

If they go out to the front page and log-in, it seems to do better. Still, this is a weird problem. Any ideas?

Mickey

http://www.christianguitar.ws/forums/

[Scott MacVicar]

Yep its a bug thats been created since 2.2.5

The code changed to stop people posting as a guest even when guest posting wasn't allowed.

Im moving this to bug forums for a developer to look at, pretty much the checking for user+pass has to be done before it checks if its a guest or not.

[mickmel]

Cool - glad it's not just me. :) So what do I do to fix it?

Mickey

[Paul]

And here I thought I was going crazy.

This is a *major* problem. Users can now post using the nicknames of registered guests. I posted a message earlier today on vbulletin.org asking for a hack to prevent this sort of behavior. I don't remember it arising before. The problem occurs when:

1. A user is not logged in and posts using a username and password--messages will be shown as posted by a guest
2. A user posts as a guest (when guest posting is allowed--I haven't tested it with guest posting disabled as I don't use this setup) and can use the nicknames of registered users without having a password. They are shown as guests though in the status line.

A temporary workaround would be appreciated. I can foresee this causing major problems.

Paul

[Scott MacVicar]

Open up your newreply.php and newthread.php

if (isset($username) and !isset($bbuserinfo['username'])) {

needs changed to

if (isset($username) and $bbuserinfo['userid']==0) {
Edited the code a little.

[Paul]

PPN,

Thanks for the suggested fix. I have applied it and the following issue occurs:

When user that is not logged in supplies a username and password in the newthread or newreply pages, they are taken to error_wrongpassword. Pressing back shows that they were successfully logged in, however the message is not posted.

This does remove the ability for guests to be able to use registered nicknames.

I will look at the code and see if I can spot the reason why this is happening. I'm assuming it's a question of position of the code.

Paul

Update: I have not been able to spot where this problem lies. The code appears to be correct, but in fact isn't. Any developers looking into this?

[Scott MacVicar]

I found the problem, it appears that the getpermission array isnt getting logged after the checks for username.

Yes there is a small problem with the original code in 2.2.6, it says

and empty($bbuserinfo['username'])
this should be
and $bbuserinfo['userid']==0

The
$permissions=getpermissions($threadinfo['forumid']);

is not returning a valid array.

I leave for the airport in a little under two hours, hopefully a dev can help you.

[Paul]

PPN,

Thanks for trying to help. I reverted to the original 2.2.6 code and made the new changes in your edited post with the same results--everything works with the exception of making a post while not logged in and supplying a password.

I can't find: and empty($bbuserinfo['username']) in newthread or newreply. Perhaps it's in another file?

In any case have a safe trip! :D

Paul

[nuno]

It's not empty($bbuserinfo['username']), it's ($bbuserinfo['username']) ;)

[Paul]

Oh, so he was just reiterating it. Okay ;)

The problem still exists, though. :: waits for developer ::

[Paul]

Well, I've stared at php code all day trying to figure this one out and I just don't see the problem. How can we get that array to return the right value? I imagine not many people enable guest posting. It still turns away valid usernames and passwords.

Paul

[Paul]

Seeing as no one from devel has posted here yet, I've been frantically trying to find a fix for this bug which is causing a bit of an uproar on my site.

I assume, from the error displayed after applying PPN's suggested fix, that the issue appears to be related with this code:

In newthread.php:


$permissions=getpermissions($forumid);
if (!$permissions[canview] or !$permissions[canpostnew]) {
show_nopermission();
}


That is the only occurance of show_nopermission I can find in newthread.

Newreply uses show_nopermission four times.

If there is a developer looking into this, I'd appreciate a quick note stating so.

Thanks,
Paul

[awilner]

I'm having the same problem since I upgraded to 2.2.6., it's very frustrating since I upgraded to fix previous bugs. Can you please tell me exactly what I need to do to fix it, without causing new bugs?

[Paul]

Thanks to inph of #vborg for helping me troubleshoot and writing the following "quick and dirty" fix. I'm not sure if this is the best way to do this, or if it will cause additional problems, but it seems to work.

For version 2.2.6:

AFTER following PPN's instructions above and making the changes he specified...

Originally posted by PPN
Open up your newreply.php and newthread.php

if (isset($username) and !isset($bbuserinfo['username'])) {

needs changed to

if (isset($username) and $bbuserinfo['userid']==0) {


in newthread.php find:


if (!isset($iconid) or $iconid=="") {
$iconid=0;
}
$iconid = intval($iconid);

$permissions=getpermissions($forumid);


immediately after insert:


// inph guest posting work around start
if ($bbuserinfo['userid']!=0 and md5($password)==$userinfo['password']) {
$permissions=getpermissions($forumid, $userinfo['userid'], -1);
if (!$permissions) {
$permissions=getpermissions(0, $userinfo['userid'], -1);
}
}
// inph guest posting work around end


in newreply.php find:


if (!isset($iconid) or $iconid=="") {
$iconid=0;
}
$iconid = intval($iconid);

$permissions=getpermissions($threadinfo['forumid']);


immediately after that insert:


// inph guest posting work around start
if ($bbuserinfo['userid']!=0 and md5($password)==$userinfo['password']) {
$permissions=getpermissions($threadinfo['forumid'], $userinfo['userid'], -1);
if (!$permissions) {
$permissions=getpermissions(0, $userinfo['userid'], -1);
}
}
// inph guest posting work around end


This is a quick and dirty fix. I cannot guarantee it won't screw something else up, but at least it's something that seems to work. Hopefully one of the developers will stop by and look into this sometime today. Steve Machol has informed me that he's notified the developers of this thread.

Paul

Edited code to include fix inphinity suggested below.

[inphinity]

in this particular case, where guest posting is enabled and a user enters his/hers username and password on the newthread page

after calling $permissions=getpermissions($forumid)

var_dumping $permissions showed a NULL array

then try to re-populate the array with:

$permissions=getpermissions($forumid, $userinfo['userid'], -1);

however it returns NULL when the user has permission to post new threads and the correct array if the user has no permission to post new threads.

so call it again with forumid = 0
$permissions=getpermissions(0, $userinfo['userid'], -1);

returns a filled permissions array.

as for the quick n dirty fix i would change the first line to check to make sure that bbuserinfo isnt set to guest (0)
if ($bbuserinfo['userid']!=0 and md5($password)==$userinfo['password']) {


again, no guarantees blah blah use at your own risk, better still wait for the developers to clarify and even better still turn off guest posting ;)

[Mike Sullivan]

This fix has seemed to work for me in all my tests. Let me know if you have any problems with it.

In admin/functions.php, find:

if (!isset($usergroupcache)) {

Replace it with:

if (!isset($usergroupcache["$usergroupid"])) {

(That fixes getpermissions() returning NULL.)

In newreply.php and newthread.php, find:

if (isset($username) and !isset($bbuserinfo['username'])) {

Replace it with:

if (isset($username) and $bbuserinfo['userid'] == 0) {

That should do it.

[Paul]

Thanks Mike,

Confirmed Ed Sullivan's fix corrects all issues with this bug.

He makes it look too easy ;D

Paul

[CB_Tommy]

Will there be an official fix in the next release of vBulletin 2?

[Paul]

Originally posted by CB_Tommy
Will there be an official fix in the next release of vBulletin 2?

The standard convention used here says that since the topic of this thread has been prefixed with "[fixed]", it will be included in the next release. As to whether or not there will be a 2.2.7? A developer will have to answer that, but I wouldn't be surprised.

Paul