Cannot Access Image Wiki Pages (Logged Out)

Hi there,

When I try to access my Image namespace/forum, I am shown as not being logged in. However, I was able to post an article to the Image namespace/forum. Viewing the specific Image Wiki Article, however, was denied to me and I am shown as logged out. I try and log in, but I a not shown as being logged in on the Image Wiki Article.

Is there a way that I can fix this? By default, I permit only signed-in users to view attachments.

Have you double checked that your usergroup (your default one) is set to allow access to that forum's attachments? That particularly applies if your default one isn't the normal Admin group.

Quote:

---

Originally Posted by Mokonzi

Have you double checked that your usergroup (your default one) is set to allow access to that forum's attachments? That particularly applies if your default one isn't the normal Admin group.

---

Absolutely. My usergroup (a custom usergroup) has all default permissions set to "Yes", including Downloading Attachments. My issue doesn't seem to be that my account can't access an Image:Imagefile.ext wiki page. It's that whenever I try to access that wiki page, I am shown as being "logged out" and then I get a standard vB no-permission error. Any thoughts?

If you're using a custom usergroup, have you got Administrator set as a secondary additonal group? Does that make a difference if not?

If that doesn't, temporarily try setting the Administrator as your main usergroup.

If that doesn't help, are you a Super Administrator as defined in the config file?

These suggestions are the only ones I can think of to help, and if any fix the problem, there's probably still a bug, but Pegasus is the main developer, and my limit is purely settings within the software, I've little programming experience. :)

Unfortunately, those suggestions didn't help. It seems that whenever I look at the Image:Filename.jpg post in my wiki (e.g., www.domain.com/wiki/Image:Filename.jpg), I receive a no-permission error and I appear as "logged out" in the Navbar, and I am prompted to log back in. This seems to occur on all account configurations. That said, I am not really "logged out", because accessing any other page on my site shows me as properly logged in.

I am going to escalate this as a bug.

I assume this is happenig with every image you've uploaded? Can you access other images across your site?

I'm beginning to wonder if it's .htaccess related. Have you got any subdomains registered at your site? http://wiki.mysite.com for example?

I've not got vbSEO installed at my site, so can't help much with related settings in that that may conflict.

Hi Mokonzi,

The "being logged out" happens with every instance of Image:Whatever.ext -- whether or not that image exists. That said, I do not have any subdomains on my site and I am using the .htaccess rules that pegasus gave me earlier for vBSEO compatibility issues. One thing I did notice (and I mentioned in my bug report) is that I am only given a no-permissions error when I try to access an image file that was actually uploaded, but when I try to access a non-existent image, I see the standard "there is currently no text in this page" notice from VaultWiki. However, I still appear as "logged out" in the vBulletin Navbar.

I am assuming that this is a problem with VaultWiki itself and the Image Namespace.

Any thoughts on what might be causing this, pegasus? I also updated the bug/issue report with a new discovery: I can include the image just fine using the IMAGE tag in posts and wiki articles, but viewing the actual Image wiki page returns a not-logged-in situation. As a reference, here are my .htaccess files (since it's been suggested this might be an .htaccess issue).

domain.com/.htaccess:

Code:

---

RewriteEngine On
RewriteCond %{HTTP_HOST} ^aelyria\.com [nc]
RewriteRule (.*) http://www.aelyria.com/$1 [R=301,L]

RewriteBase /
RewriteRule ^forums/showwiki.php?title=(.*)$ wiki/$1 [L,R=301]
RewriteRule ^wiki/Default:(.*)$ wiki/$1 [L,R=301]
RewriteRule ^wiki$ wiki/ [L,QSA,R=301]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^wiki/(.*)?$ forums/showwiki_proxy.php [L,QSA]

---

domain.com/forums/.htaccess:

Code:

---

RewriteEngine On
RewriteBase /forums/

RewriteRule ^wiki.php$ showwiki.php [L,QSA]
RewriteRule ^showwiki.php?title=(.*)$ http://www.aelyria.com/wiki/$1 [L,R=301]

RewriteRule ^((urllist|sitemap_).*\.(xml|txt)(\.gz)?)$ vbseo_sitemap/vbseo_getsitemap.php?sitemap=$1 [L]

RewriteCond %{REQUEST_URI} !(admincp/|modcp/|cron)
RewriteCond %{REQUEST_URI} !showwiki_proxy.php
RewriteRule ^((archive/)?(.*\.php(/.*)?)?)$ vbseo.php [L,QSA]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !^(admincp|modcp|clientscript|cpstyles|images)/
RewriteRule ^(.+)$ vbseo.php [L,QSA]

---

First, make sure that GUESTS have both permissions for the Image forum:

• Can Download Attachments
• Can See Thumbnails

Then, check your site's Cookie Path - make sure it's set to the domain root (that would be just a / ) and not /forums/. Based on your current setup, having it at /forums/ will log you out on all wiki pages unless you specifically log in there. You can check this value at:

vBulletin Options > Cookie and HTTP Header Options > Path to Save Cookies

!! Be careful about changing this, because having an invalid setting could leave you and your users unable to login until you fix the setting manually. If you bollocks this, many people think you need to restore your database, but it really only requires some temporary file edits.

Thanks, pegasus, but that doesn't fix the problem.

1. Guests have both permissions for the Image forum (they can download attachments and see thumbnails).
2. Now I can see the Image wiki page in question -- but I am shown as having been logged out still, and cannot interact with it.
3. My cookie path is set to the domain root -- just a / -- and has not been touched.

Any thoughts as to what else could be causing this? Here is the link to the particular spot in question -- www.aelyria.com/wiki/Image:King.jpg -- feel free to create an account if you wish to experiment with how this seems to spontaneously log you out.

Another thing I noticed -- and I'm not sure if this is relevant -- but when clicking on the "Discussion" tab of the Image file (where, no matter what, the system views you as logged out and a guest), the AJAX keeps spinning and loading up endlessly (it never loads the non-existent discussion). Conversely, even if you're not logged in and are a guest, you can at the very least load up the discussion tab via AJAX. Comparison:

http://www.aelyria.com/wiki/Image:King.jpg

versus

http://www.aelyria.com/wiki/Aelyria

I'm at the point where I think this may be a conflict with something else on your site. I haven't been able to reproduce this on my 3.8 board.

This is a cookies issue, where either vBulletin isn't able to read the cookies on Image pages, or where $vbulletin->userinfo is cleared on Image pages (or pages containing attachments). I've been through the code several times over today trying to find a spot that might do this with no success.

You appear to have some custom cookies on the site. Aside from the Google Analytics (utm) ones, are these from any modifications I can find and have a look at?

--snip-- see the solution below. We need to find a way to suppress the file extension from the Wiki URL, or, even better, not require the Images Namespace Wiki Pages to have the same titles as the uploaded files.

Additionally, here is a non-Wiki post where I attach an image file -- there's no problem here. I remain logged in:

http://www.aelyria.com/forums/genera...ting-post.html

I figured it out!

Apparently, this is a vBSEO issue. For some reason, in order for attachments to display properly, vBSEO advised me to add .att to my rewrite rules for images. Specifically, because my server was not passing .jpg and other image files to vBSEO (for rewriting purposes), vBSEO had me include a rewrite incorporating .att in my attachment files in my vBSEO Rewrite Rules.

This is the Attachment Rewrite Rule that vBSEO had me use:

Code:

---

[forum_title]/[attachment_id]-[thread_title]-[original_filename].att

---

You can see this in action by appending ?redirect=no to the URL.

http://www.aelyria.com/wiki/Image:Fl...ng?redirect=no

versus

http://www.aelyria.com/wiki/Image:FlagIkerael.png

The file extension results in some quirky behavior by the web server because of the .att attachment rewrite that vBSEO required me to do. I'm not sure if you know how to fix this particular situation, but this is important because on most Cloud platforms, the static file extensions (.jpg, .doc, .gif, etc.) are not allowed to be fed to a parser/script. This is why vBSEO had to rewrite their rewrite rules for use on a Cloud platform.

Is there any way we can allow an Image page name without the extension?

I'm not sure if the issue is that they aren't allowed. It seems more like the server detects the static file extension, and transfers it as a cookie-less request.

I'll make the file extension optional (by replacing the dot with a space replacement) for the next build. In the mean time, you can avoid this issue in 2 steps.

1. Create a new plugin.

Product: VaultWiki
Hook Location: vault_url_encode
Execute Order: 5
Title: Fix for Cloud platform
PHP Code:

Code:

---

if (IMAGE_SPACE AND $namespaceid == IMAGE_SPACE)
{
        if ($this->setcache["$langid"] == 'U')
        {
                $replacementlist['.'] = ' ';
        }
        else
        {
                $allowstring = str_replace('\.', '', $allowstring);
        }
}

---

2. Go to AdminCP > Namespace Manager. In the Controls for "Image", click "Rebuild". This should remove the dot from the page URLs to prevent it from being detected as a file extension.

Thanks, pegasus! That fixed it. A few quick questions:

1. So users should still be advised to post article names that match the name-and-extension of the file that they are uploading, correct?

2. Will using [image]Image:Imagename_ext[/image] work? Or should they use the actual page title -- Image:Imagename.ext?

3. When we upgrade to the next build of VaultWiki, will we need to remove this plugin, or will it be automatically accepted (and not duplicated)?

Thanks again!

1/2. Both works, but they should continue to use the actual page title to avoid confusion.

3. This plugin will not be needed in the next build - it will be overwritten by the upgrade process. Instead, there will be a setting that addresses this.