Wedge

Public area => The Pub => Bug reports => Topic started by: Arantor on December 23rd, 2012, 11:44 PM

Title: in_array() expects parameter 2 to be array
Post by: Arantor on December 23rd, 2012, 11:44 PM
 Guest
 Today at 10:29 PM
 Type of error: General
http://localhost/wedge/index.php?localhost/wedge/index.php?action=admin;area=ban;sa=soft;ace465ae=80b35724d62f371a37399bdcebf8345e
 2: in_array() expects parameter 2 to be array, null given
 File: C:/wamp/www/wedge/Sources/Security.php
Line: 804

This is interesting. That particular line is:

Code: [Select]
if (!is_array($permission) && in_array($permission, we::$user['permissions']))

That implies that we::$user['permissions'] never gets declared properly for guests. The code changes are so vast that I can't practically review them line by line. I'm not sure why the reported URL is even flagged, because I see no reason why it should be called.

What I need to do is extend error handling to be able to provide a full backtrace as well on errors. That might at least explain how we get to where we are.
Posted: December 23rd, 2012, 11:37 PM

Note: at no point have I been a guest in this installation; I've been logged in as an admin the whole time.
Title: Re: in_array() expects parameter 2 to be array
Post by: Nao on December 24th, 2012, 01:27 PM
I've been having that error regularly since I made the we object, but never got time to look into it.
I'll take some time in a few minutes.

My quick suggestion: maybe Security is called BEFORE we::getInstance...? Or isn't it?
Title: Re: in_array() expects parameter 2 to be array
Post by: Arantor on December 24th, 2012, 01:32 PM
Yes, it is.

See topic 7677 in the team board. It's been broken for a very long time.
Title: Re: in_array() expects parameter 2 to be array
Post by: Nao on December 24th, 2012, 06:31 PM
Don't we have simply a way to bypass this issue until fixed..?
Or are we screwed because the we object needs to be initialized for us to put a dummy value in it? :P
Title: Re: in_array() expects parameter 2 to be array
Post by: Arantor on December 24th, 2012, 06:36 PM
We have no way to actually fix this without MAJOR changes as per my other topic.

It's nothing to do with the we object being initialised; this problem is architectural and predates the we object. It's only that the we object brings the symptoms to the fore.

As far as bypassing it goes strictly as a temporary measure, the checks at the front of allowedTo() could be expanded to whether we::$user['permissions'] is defined or not. It will hide the error message but won't fix the fact we're calling permissions tests before permissions are even loaded.