[3.0]: Guests cannot see boards when cookies are disabled

[sbulen]

Basic Information

Guests cannot see boards when cookies are disabled.

Note the board has the proper permissions, -1,0,2.

This is followup to #8615 . It's interfering with testing of #8399 . Works fine in 2.1.

Steps to reproduce

1. Install from current GitHub.
2. Logoff.
3. Disable cookies on your browser.
4. Navigate to newly installed forum.

Expected result

As in prior SMF versions, normally the guests can see boards & navigate around.

Actual result

No boards are visible. See screenshot above.

Version/Git revision

3.0 Alpha 3

Database Engine

All

Database Version

8.4.0

PHP Version

8.4.5

Logs

Additional Information

No response

[Sesquipedalian]

@sbulen, is this still happening? I cannot reproduce it.

[sbulen]

Hmmm... I think the behavior has changed a little... This is what I am seeing today:

If I just visit the forum with cookies disabled, e.g., https://myforum.org/index.php, I see the above, i.e., no boards or categories.

If I hit pretty much any form button, PHPSESSID is added to the url, and I can see all the boards/categories.

In 2.1, no such button press (to add PHPSESSID) is necessary. Upon first visit, boards are visible.

So... It seems the difference between 2.1 & 3.0 is that a session is now REQUIRED to see public boards & categories, and that wasn't the case before.

I could attempt to fix as part of #8399. But something changed upstream, e.g., there is no similar issue testing #8394 .

(It might take a while... looks like I spawned another round of merge conflicts with #8399...)

[sbulen]

I've been testing this & have discovered that navigating 100% by url, e.g., index.php?board=1 or index.php?topic=1 or index.php?msg=1 works fine.

So... It's probably not a permissions issue. Or even a session issue... Possibly just a simple board index display issue...

Or possibly a category issue. The only URLs that don't work are index.php & index.php#c1

[sbulen]

I've narrowed it down to this line of code here:

SMF/Sources/Actions/BoardIndex.php

Line 464 in 1b52517

$board = Board::init((int) $row_board['id_board'], [

When cookies are enabled, upon return from this call to Board::init, there are associations made between the parent category and the board, e.g., the category->children property is populated. For some reason, this isn't happening when cookies are disabled - category->children is always empty.

Then painting the template bails here, leaving the incomplete board index in the pic above:

SMF/Themes/default/BoardIndex.template.php

Line 71 in 1b52517

if (empty($category['boards']) && !$category['is_collapsed'])

Haven't yet nailed the exact line in Board::init yet though... It's obfuscated somewhere underneath layers of constructors, inits, slugs, property aliases, etc., etc., etc...

Initial suspicion is there is some confusion between the category's boardList property & the children property; different names, same function AFAICT.

[sbulen]

I believe I know what's going on here.

First, it's not unique to disallowed cookies - it's just more apparent then. It happens any time a session cannot be found, including your first visit to the site. Also the first visit after an install... You hit refresh & the problem goes away forever, so you figure it's just a glitch... You can reproduce the behavior in the pic above by deleting all sessions & visiting the site (with or without cookies or being logged on). As soon as the screen is refreshed the problem goes away.

What is happening is that without a session, you get a fresh call to load permissions. Doing so loads boards, with 0 params passed. So, this logic gets invoked:

SMF/Sources/Board.php

Line 2202 in 1b52517

// No props provided, so get the standard ones.

That logic uses all the field names as property names, and there are all kinds of issues with that, so it loads them as custom properties...

Thus, the board category is never loaded. Without the board category, the board is never added to the category's list of children, ie., this line is never hit:

SMF/Sources/Board.php

Line 2230 in 1b52517

$this->cat->children[$this->id] = $this;

So the relationship between boards & categories is lost, a bunch of empty categories is passed to the template, so the bulk of the template is skipped, as pointed out above.

The bottom line is that the Board constructor needs to be rethunk...

I hope this makes sense...

[Sesquipedalian]

That does make sense. Thanks for your sleuthing, @sbulen!

[jdarwood007]

I can't reproduce this

1. In Firefox, I blocked cookies to my test site
2. Deleted all cookies in my browser for my test site
3. Deleted all sessions from database (I have database driven sessions on)
4. Deleted any cache files from the cache folder and tmp folder on the server.

I hit the site and everything loads up.

[jdarwood007]

@sbulen and @Oldiesmann

Can you tell me what $props data looks like on Board.php line 2096

			$this->set($props);

I suspect that $props is coming in as $props[0]['id_cat'], but we expect it to be $props['id_cat']. So when it goes through the setter, it can't find the property. Because of that, it all gets dumped into $this->custom[$prop] with the 0 index and the array of properties.

I can produce a new error if I change the line to:

			$this->set($props[0] ?? $props);

But that gives:

Typed property SMF\Category::$new must not be accessed before initialization

But this is because $this->cat is still not setup.

The issue with that is the trait DynamicPropertyHelper. It is the magic that is called when we issue the $this->set. It calls $this->_set. Which instead of calling the one in Board class, calls the one in the DynamicPropertyHelper trait. So we never hit our custom logic in the Board class that will initialize the category. In my testing, the __set method on Board is never called during the set operations.