Issue: [4.1 Alpha 2] Public navigation: Most sub menu items not showing outside of admin cp

Try this query:

That has fixed the affected sub-navigation links, thanks

I suspect this might have happened because the public forum pages were accessed while the upgrade was still processing templates and such. In the next build we'll swap the order of some operations which should reduce the likelihood of this occurring.

I've had this issue occur again while placing one page into and out of the approval queue several times. After truncating vw_cache again, I've unapproved and reapproved the same page a few more times but couldn't reproduce the hidden link issue.

So I think there could be some other factor that is causing this issue and not just the upgrade steps. Scratching my head with this one!

vw_cache exported to *.sql before truncating was 3.98kb (data only, no structure). After refreshing the wiki to see the links again, a second data-only table export provides a 9.71kb file.

phpMyAdmin says the cache_value column was a 1.5kb BLOB before I truncated the table. Afterwards, this same column is a 4.4kb BLOB. cache_key and permission_hash values are identical without any changes.

If you'd like, I can send you two *.bin files of cache_value privately.

I'm not sure, but this might occur if you test permissions of a specific user who can't do most wiki things, and then switch back to your main user. The main user might still see the nav links of the test user.

The simplest explanation I can see is that when cache_value is missing links, the cache_key does not actually have your user's ID at the end of it. Otherwise it would seem like multiple xf_data_registry entries are missing or incomplete (vw_nodetypes and options).

With Alpha 3, I experience the hidden link problem again. This time, the entire wiki tab is missing. From the investigation described below, whichever links disappear seems to depend on what the view permissions are for the Unregistered group.

This time, the problem is caused by switching between https and http within my development server, which switches me from a logged in and logged out state due to cookie configuration. This server does not have a public facing URL, so I don't bother with redirecting http to https.

When initially logged into XenForo with https:// ... the Wiki tab is viewable and the vw_cache.cache_value column is 4.6KB. When I switch to http://, I am now viewing the site logged out and the vw_cache.cache_value becomes 58B. When I switch back to https:// I am again viewing logged into XenForo, except the vw_cache.cache_value stays as 58B and all of the Wiki navigation link items are hidden. Despite the hidden links, I can still manually type in a particular wiki URL and view the contents that I have permission to view for the account.

A further experiment: With vw_cache.cachevalue still 58B and all Wiki links hidden, if I change index_permissions[canview] to 1 (Yes) and then reload the https:// logged-in link, I still can't see the Wiki tab. However, if I reload the http:// logged-out link, I can now see the tab (with only Search Wiki Pages sub-navigation) and vw_cache.cache_value becomes 1.8KB. Now if I load up https:// again logged in, I can see the Wiki tab, but also only with the single sub-navigation item (Search Wiki Navigation).

---

I have also experienced the opposite, where I initially view the wiki logged out over http://, then switch to logged in https://, which will show the "Wiki" tab and sub-navigation. Then changing back to http:// (logged out), the full "Wiki" sub-navigation items are visible contrary to the wiki permissions for Unregistered. Clicking on the items that shouldn't be visible (e.g. create new page) leads to a no permission page, at least.


TL;DR reproduction steps: (assuming no http to https redirection in htaccess)
1. Truncate vw_cache table
2. View Wiki with http:// (logged out), nav items are correct for Unregistered - cache_value generated or changed
3. View Wiki with https:// (logged in), nav items are correct for Registered - cache_value generated or changed
4. View Wiki with http:// (logged out) again, nav items remain in the Registered state - cache_value not changed (some items visible when they shouldn't be).

Or

1. Truncate vw_cache table
2. View Wiki with https:// (logged in), nav items are correct for Registered - cache_value generated or changed
3. View Wiki with http:// (logged out), nav items are correct for Unregistered - cache_value generated or changed
4. View Wiki with https:// (logged in) again, nav items remain in the Unregistered state - cache_value not changed (Some items hidden when they should be visible).

Please explain your cookie configuration.

I cannot duplicate this using a method of viewing http/https in different login/out states within the same browser session (assuming unregistered can't view the wiki and the logged in user can). When I log in/out of one, the state is reflected in the other http/https state when switched and refreshed. So it seems that XenForo is automatically sending out both secure and http-only cookies at the same time. With logged in vs logged out in different browser sessions, I don't have an issue either; the cache entry is associated with the correct user.

I have tried removing the session cookie manually, without actually logging out, and this doesn't really change anything either. Some stuff gets weird but fixes itself after a refresh.

I have development instances of XF1.5, 2.0 and 2.1 all running from the same local IP. I make full use of the XF license agreement changes that now permit multiple "test" installations . So that cookies from one instance do not conflict with another, I add extra cookie settings to src/config.php as documented at https://xenforo.com/xf2-docs/manual/...ookie-settings

path is '/', domain is '' and prefix is unique to each forum instance. With this configuration, if I log into XF with https, then http remains logged out (and vice versa).

Any luck in reproducing this? I've experienced this a few times over the last few days. Perhaps it is best to unmark this issue as Fixed for the time being.

I've run into this issue again, just from logging in/out of various user accounts from the same URL (all https). So it seems like the relation between http/https changes is just coincidental. I think that the hidden sub-menu link issue could actually be related to a particular user account pattern. The following steps reproduce the hidden link issue for me in Beta 1 b002:
1. Log in to user account (e.g. ID 1) (Sub-menu is OK)
2. Truncate vw_cache
3. Refresh any page within the Wiki section (Sub-menu still show OK)
4. Log out (Sub-menu correctly limited to guest accessible links)
5. Log in to the same user account (e.g. ID 1) (Sub-menu wrongly limited to guest accessible links just as if I were not logged in, except I am logged in...)

If vw_cache is truncated while logged out, logging in does not appear to trigger the missing link issue.

Also, if vw_cache is truncated while logged in to a particular user account, logging out and then logging in to a different account avoids the sub-menu missing links issue ... until I go back to the original account again.


With these new details are you able to reproduce the disappearing sub-menu links problem? If not, is there any temporary debug code/logging that you want me to try?

Today another user reported this happening when the main forum was set to https, but the wiki was set to http, with the wiki being enforced to https. With this combination, I had a problem where forum-based URLs were being improperly redirected to the wiki index. However, on the different logged in/out states https vs http, the navbar contained the correct links for the respective states.

It is more likely the user today did not notice they were being logged in/out as they navigated around the site, as the https/http state was changing.

However, I still wonder if there is a problem with the guest cache, or possibly an add-on that extends it, that you may be using.

I believe I have an explanation for this finally. It does not happen on our test sites or on our demo due to their databases having been upgraded from pre-4.0.24.

If the database was installed fresh post-4.0.24, there is a typo in the definition file for vw_cache (where the 'attributes' for column cacheid is mispelled 'attibutes'). As a result, vw_cache.cacheid does not become an auto-increment field. Since we assume it is and don't fill it manually, this means the value is always defaulted to 0. Since it is also the primary key, this means that all inserts to the table end up with cacheid = 0, so every new update overwrites the previous one.

Now the weird part. We never fetch cache records by cacheid. Instead, we fetch by another unique combination (cache_key + permissionhash). A reasonable person might expect the query to fail since this combination would not match once another user overwrites the same row. But it appears that if a primary key exists on a table, then MySQL is treating all other keys as aliases of the corresponding primary key. So "cache_key+permissionhash A" points to cacheid = 0, and "cache_key+permissionhash B" points to cacheid = 0. A reasonable person might expect that overwriting the row would clear other indexes to the same row. But I have a feeling that MySQL is getting confused due to not specifying the primary key in the insert, and treating it as a new row only, even though an old row was overwritten.

Run the following MySQL query:
And I believe this issue should subside.

Per the implications, this has been treated as a Permissions Escalation.
Marking this as fixed in the next patch.

Oh wow, you might be onto something! This would explain why I have only experienced the disappearing navigation items within my local development/testing environment (VW 4.1 new install) and not from tests carried out elsewhere using duplicated live site data (VW <4.0.24 upgraded to 4.1).

Comparing the vw_cache table structure between 4.1 new and upgraded installations, yes I do see a difference with how cacheid is defined. There are also some differences for other columns in this table with their default values (and whether a null value is permitted for cache_value).

Dev site new install as at XF2.0/VW4.1.0 Alphas: (Current version v4.1.1 PL1)
Test site with existing install upgraded from XF1.5/VW4.0 with initial version <4.0.24 (Current version v4.1.1 PL1)
I have altered my local dev site's vw_cache table to match the structure found on my duplicated live site. From initial tests the issue seems resolved . I'll reply again if the situation changes.