Issue: No permissions to add/change an attachement (ErrorException: [E_NOTICE] Trying to access array offset on value of type bool

Issue Tools
- View Changes

February 15, 2022 1:49 PM

wolven

New Member

No permissions to add/change an attachement (ErrorException: [E_NOTICE] Trying to access array offset on value of type bool

all rights granted but no chance to get an attachement uploaded

Hi all,
Error message after I tried to upload or change an attachment:

Code:

Stack-Trace

#0 src/addons/vw/vw/_core/view/ui/history/base/vw.php(354): XF::handlePhpError(8, '[E_NOTICE] Tryi...', '/var/www/vhosts...', 354, Array)
#1 src/addons/vw/vw/_core/view/reply/view/vw.php(48): vw_UI_History_Base_View->view(Array)
#2 src/addons/vw/vw/_core/view/reply/base/vw.php(134): vw_Reply_View_View->render_type('html')
#3 src/addons/vw/vw/_core/view/reply/stack/vw.php(45): vw_Reply_base_View->render('html')
#4 src/addons/vw/vw/_core/view/reply/stack/vw.php(45): vw_Reply_Stack_View->render('html')
#5 src/addons/vw/vw/XF/Mvc/View.php(25): vw_Reply_Stack_View->render('html')
#6 src/XF/Mvc/Renderer/AbstractRenderer.php(91): vw\vw\XF\Mvc\View->renderHtml()
#7 src/XF/Mvc/Renderer/Html.php(47): XF\Mvc\Renderer\AbstractRenderer->renderViewObject('vw\\vw:Wiki', 'public:vw_gener...', Array)
#8 src/XF/Mvc/Dispatcher.php(460): XF\Mvc\Renderer\Html->renderView('vw\\vw:Wiki', 'public:vw_gener...', Array)
#9 src/XF/Mvc/Dispatcher.php(442): XF\Mvc\Dispatcher->renderView(Object(XF\Mvc\Renderer\Html), Object(XF\Mvc\Reply\View))
#10 src/XF/Mvc/Dispatcher.php(402): XF\Mvc\Dispatcher->renderReply(Object(XF\Mvc\Renderer\Html), Object(XF\Mvc\Reply\View))
#11 src/XF/Mvc/Dispatcher.php(60): XF\Mvc\Dispatcher->render(Object(XF\Mvc\Reply\View), 'html')
#12 src/XF/App.php(2351): XF\Mvc\Dispatcher->run()
#13 src/XF.php(517): XF\App->run()
#14 index.php(20): XF::runApp('XF\\Pub\\App')
#15 {main}

Status of request

array(4) {
  ["url"] => string(74) "/forum/wiki/?title=18-201-Tabellarischer-Lebenslauf&do=history&type=attach"
  ["referrer"] => string(74) "https://www.tt-board.de/forum/wiki/?title=18-201-Tabellarischer-Lebenslauf"
  ["_GET"] => array(3) {
    ["title"] => string(32) "18-201-Tabellarischer-Lebenslauf"
    ["do"] => string(7) "history"
    ["type"] => string(6) "attach"
  }
  ["_POST"] => array(0) {
  }
}

Version 4.1.4 Build 002

Issue Details

Issue Number 6295

Issue Type Bug

Project VaultWiki 4.x Series

Category Attachments

Status Fixed

Priority 3 - Loss of Functionality

Affected Version 4.1.4

Fixed Version 4.1.4

Milestone (none)

Software DependencyXenForo 2.x

License TypePaid

Users able to reproduce bug 0

Users unable to reproduce bug 0

Attachments 0

Assigned Users (none)

Tags (none)

February 15, 2022 3:33 PM

pegasus

VaultWiki Team

What file type are you trying to upload?
When you attempt to upload, does the uploader display an error message?

For the error when attempting to view the attachment history, it looks like the attachment is damaged and has no history (there is no filedata connected). Was this working correctly for the same attachment before you attempted to change the attachment? When trying to change the attachment, how far did you get (what steps did you take)? Did the uploader complete? Did you click save? Do you have any other errors in your log from the upload attempt?

Reply
February 16, 2022 2:54 AM

wolven

New Member

Ok, one by one:
For the new upload:
Filetype: PDF, No error messages. File is uploaded and symbolized with a tick. When I try to press "save", I get the standard message "oops, we ran in a problem". Thats it.

For the old file exchange:
Same. I can upload the file, it is shown as uploaded. Saving with the error message above.
I would have expected to see something like versioning as I upload a newer version of an existing file. But I shows just the error message and thats it.

For the history.
Yes the file is flagged as damaged. But it is not clear why. In test environment the same file is there. The history shows nothing, noone has touched it since 2017.

Reply
February 16, 2022 2:11 PM

pegasus

VaultWiki Team

Thank you for this additional information. I will try to reproduce the problem on a test board.

In the mean time, it sounds like you may not have file history turned on, and you expect it. There may be a problem saving the file when history is turned off. In AdminCP > Setup > Options > VaultWiki: Content Types, make sure that "Track attachment history" is ticked.

If attachment history needs to be turned on, please try uploading the file again after it is activated. Do you receive the same error messages?

Reply
February 16, 2022 6:17 PM
pegasus

VaultWiki Team
Okay I found the issue. When making a new file upload, the old upload is supposed to be deleted when attachment history is turned off. However, it is still deleting it even when the old upload is the current one (since there is no history, the old upload is usually the current one). So you should not have issues if you continue using attachment history, but if you would rather not turn it on, this can be fixed by editing src/addons/vw/vw/_core/controller/dm/attach/edit/vw.php. Find:

Code:

// delete the old attachedit $oldedit = vw_Hard_Core::controller('Fetch')->get('AttachEdit', $oldeditid); if ($oldedit)

Replace with:

Code:

// delete the old attachedit $oldedit = vw_Hard_Core::controller('Fetch')->get('AttachEdit', $oldeditid); if ($oldedit AND $oldeditid != $attacheditid)

In order to reupload the same file that was affected in this way, and avoid getting a permission error, you either have to wait 1 hour, or run the following MySQL query:

Code:

DELETE FROM xf_vw_attachmentfile WHERE userid = 0 AND attachmentid = 0

The permission error is happening because a user is not allowed to view a file uploaded by a different user if the file hasn't been saved yet. When all edits for the file disappeared, information about the user who uploaded it also disappeared, so the uploader assumed it was a different user.
Reply
February 17, 2022 4:03 AM

wolven

New Member

Originally Posted by pegasus

Thank you for this additional information. I will try to reproduce the problem on a test board.

In the mean time, it sounds like you may not have file history turned on, and you expect it. There may be a problem saving the file when history is turned off. In AdminCP > Setup > Options > VaultWiki: Content Types, make sure that "Track attachment history" is ticked.

If attachment history needs to be turned on, please try uploading the file again after it is activated. Do you receive the same error messages?

To answer this: Yes, I got the same error.

Reply
February 17, 2022 4:07 AM
wolven

New Member
Originally Posted by pegasus

Okay I found the issue. When making a new file upload, the old upload is supposed to be deleted when attachment history is turned off. However, it is still deleting it even when the old upload is the current one (since there is no history, the old upload is usually the current one). So you should not have issues if you continue using attachment history, but if you would rather not turn it on, this can be fixed by editing src/addons/vw/vw/_core/controller/dm/attach/edit/vw.php. Find:

Code:

// delete the old attachedit $oldedit = vw_Hard_Core::controller('Fetch')->get('AttachEdit', $oldeditid); if ($oldedit)

Replace with:

Code:

// delete the old attachedit $oldedit = vw_Hard_Core::controller('Fetch')->get('AttachEdit', $oldeditid); if ($oldedit AND $oldeditid != $attacheditid)

In order to reupload the same file that was affected in this way, and avoid getting a permission error, you either have to wait 1 hour, or run the following MySQL query:

Code:

DELETE FROM xf_vw_attachmentfile WHERE userid = 0 AND attachmentid = 0

The permission error is happening because a user is not allowed to view a file uploaded by a different user if the file hasn't been saved yet. When all edits for the file disappeared, information about the user who uploaded it also disappeared, so the uploader assumed it was a different user.

Before I start this, I wondering why I can't upload even a new file while I have all permissions granted?
So the upload problem affects not only the existing files but also the attempt to upload new files.

Any ideas?
Reply
February 17, 2022 4:23 AM

wolven

New Member

Interesting observation: It seems to be that I have no permissons, not even as super admin to upload anything. No difference in putting additonal files to existing attachements or uploading complete new attachments.

This is weird as I am sure to have the same permissions on staging and live environment. Staging works, live doesn't.
I'm going now down to compare all permissions on both platforms.

Update1:
After checking the permissions I can't see any missing. Both accounts, I have tried withe, are admins. One is super admin, both wiki moderators. both have all permissons for pages and attachements.

So, where is the general key to this?

Reply
February 17, 2022 2:31 PM

pegasus

VaultWiki Team

Just to clarify the behavior... it is letting you use the uploader, and the uploader shows the file as uploaded, but if you click save it tells you you don't have permission?

Or are you receiving a permission error at a different stage?
If you are receiving a specific error message that prevents you uploading, the message text is key to understanding why it is blocking you. There are error messages for running out of disk space, etc.

In the editor, if you upload the file, and choose the area where you will save it afterwards, I believe it is more likely that you will receive a permission error after saving (this would only explain a permission error when the attachment is new).

If you already had the area selected (or the attachment exists already and you are changing it), then the permission error should be given by the uploader itself.

In this case, it sees that you do not have permission to upload that file extension within that area. I assume you have checked this already, but just in case, you can go to AdminCP > Wiki > Content > Attachment rules > Modify permissions, to see the permissions for your file extensions, as well as any areas where they may be customized (by clicking the affected usergroup).

Reply
February 18, 2022 8:50 AM

wolven

New Member

Originally Posted by pegasus

Just to clarify the behavior... it is letting you use the uploader, and the uploader shows the file as uploaded, but if you click save it tells you you don't have permission?

Yes. The file is shown as uploaded. By clicking "save" I get an "Oops, we ran in a problem. You have no permissions" That's all. no more messages, no errors in system log

Originally Posted by pegasus

JOr are you receiving a permission error at a different stage?
If you are receiving a specific error message that prevents you uploading, the message text is key to understanding why it is blocking you. There are error messages for running out of disk space, etc.

No. Everywhere the same error message. No difference between attaching a new file to an existing attachment or try to make a new attachment.

Originally Posted by pegasus

If you already had the area selected (or the attachment exists already and you are changing it), then the permission error should be given by the uploader itself.

In this case, it sees that you do not have permission to upload that file extension within that area. I assume you have checked this already, but just in case, you can go to AdminCP > Wiki > Content > Attachment rules > Modify permissions, to see the permissions for your file extensions, as well as any areas where they may be customized (by clicking the affected usergroup).

I've checked this. According to this I have all permissions to all file types been granted. I tried with a Xenforo Superadmin and an ordinary Admin with wikimod permissins. More is barely possible.
So I assume a general problem somewhere.

Reply
February 18, 2022 2:38 PM

pegasus

VaultWiki Team

So based on this information...

If the file uploaded, and you click save, and now you see a permission error, the possible ways the code sends this error are:
1. The file was uploaded by a different user in the past 1 hour, OR
2. Your usergroup does not have permission for that File-type under Attachment Rules, OR
3. You changed the selected area, but the admin disabled permission in that area before you clicked save, OR
4. The admin reduced the maximum allowed file size before you clicked save.

For #1, if you keep trying to upload the same file over and over, maybe the 1 hour cutoff is not working. It does not care if you are trying to make a new attachment or updating an old one. Just if the file itself is the same. Did you make the edits and database changes I suggested above?

For #2, it sounds like you have ruled this out.

For #3 and #4, this is extremely rare, and would only happen 1 time, and needs two admins, or you would know that you did this.

I had the same problem as you 2 days ago, but when I made the edits I posted above, the problem went away. I can no longer reproduce the problem. So if you are still having the problem now even after making the changes, I will need access to an installation where it is still occurring in order to investigate further. I would ask you to submit a ticket here: https://www.vaultwiki.org/members/?do=newticket

Reply
February 20, 2022 11:25 AM

wolven

New Member

Originally Posted by pegasus

So based on this information...

If the file uploaded, and you click save, and now you see a permission error, the possible ways the code sends this error are:
1. The file was uploaded by a different user in the past 1 hour, OR
2. Your usergroup does not have permission for that File-type under Attachment Rules, OR
3. You changed the selected area, but the admin disabled permission in that area before you clicked save, OR
4. The admin reduced the maximum allowed file size before you clicked save.

For #1, if you keep trying to upload the same file over and over, maybe the 1 hour cutoff is not working. It does not care if you are trying to make a new attachment or updating an old one. Just if the file itself is the same. Did you make the edits and database changes I suggested above?

For #2, it sounds like you have ruled this out.

For #3 and #4, this is extremely rare, and would only happen 1 time, and needs two admins, or you would know that you did this.

I had the same problem as you 2 days ago, but when I made the edits I posted above, the problem went away. I can no longer reproduce the problem. So if you are still having the problem now even after making the changes, I will need access to an installation where it is still occurring in order to investigate further. I would ask you to submit a ticket here: https://www.vaultwiki.org/members/?do=newticket

I've checked #1 to #4, I can't see nothing what prevents an upload.
I open a private ticket, so you can take a look. I can't find any errors.

Reply
February 25, 2022 4:31 PM

pegasus

VaultWiki Team

As suspected, there is a record of 1 PDF upload that is not assigned to any versions, and the upload belongs to a guest. Since I can upload other files and save them with no problems, I assume you are trying to upload the same PDF file as before and you only have problems with this 1 file (uploading a different PDF works, even if you attach it the same place).

(Note that I believe that the file was not actually uploaded by a guest, but the user was changed to guest accidentally by another bug, which also triggered a rollback and reattached the same file so it was not cleaned.)

So when you try to save a file edit using this file, even if you just reuploaded it yourself, the editor finds that you are trying to attach a file that was uploaded by someone else (a guest) -- users aren't allowed to attach uploads made by someone else until they attach it to something first and it verifies they are allowed to see what they attached it to. The reason for this is that it is theoretically possible for a user to attach anything, without having a copy of the file, as long as they guess the ID number, so we need to check if they are actually allowed to see that ID.

However, I think it is safe to assume that if a file was uploaded by a guest, it will have more relaxed permissions than any logged in user (a logged in user should always have more access than a guest). Therefore, I have changed the editor to ignore uploads made by guests when it checks if the user is attaching a file they have access to.

You should be able to re-upload this 1 file now. As I mentioned, I think other files were already working. Please let me know if you still have any issues.

Reply

+ Reply

All times are GMT -4. The time now is 8:10 AM.

This site uses cookies to help personalize content, to tailor your experience, and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.

Learn more… Accept Remind me later

Welcome to VaultWiki.org, home of the wiki add-on for vBulletin and XenForo!

Issue: No permissions to add/change an attachement (ErrorException: [E_NOTICE] Trying to access array offset on value of type bool

Issue Tools