Attachments not uploading on boardless posting page

[shawnb61]

Anyway, he did find one rule that was being triggered (ID 77317957) and disabled that. I then did another test and there were no errors in the Apache log this time. Just did a second test and no errors again.

Is the issue resolved?

[davo88]

No, same thing still happening.

[shawnb61]

Does the error happen any time a user attempts to post with an attachment, e.g., when replying to an existing topic?

Or does it only fail when using the quick New Topic button?

[shawnb61]

@Sesquipedalian - I believe we are dealing with two different underlying issues here, that produce the same mode of failure. 

The first is a general memory problem, which I saw on my forum and that can be seen here on SMF.  Certain combinations of ~low-ish memory, attachment settings, & attachment dimensions will cause failure upon thumbnail generation.  I believe even certain point releases of php are more sensitive than others.  The response back to the browser is actually a 'memory exhausted' error, which of course cannot be parsed for filenames, mime types, etc.  Enabling Adaptive Thumbnail Memory usually fixes this.  (If you haven't yet, I'd try it here on SMF...)

The second, I believe, is an issue with Quick New Topic Button.  I cannot get QNTB to post when a user posts an attachment via the New Topic button.  At issue, I think, is this line:
https://github.com/SimpleMachines/SMF/blob/7a757ab13e42ac20f88e9b30b807fd857defdec8/Sources/Attachments.php#L121

allowedTo() always returns true for admins, which is why it always works for admins.  But when an end user gets here via QNTB, there is no board yet, so $this->_board is NULL and allowedTo() returns false.

For both issues, since the attachment could not be created, the response is either incomplete or missing, so it cannot be parsed by .js.  Different browsers fail with slightly different messages, even on different lines in the console.  Further confusing is that FF, for me, yields the exact same console messages for the two different errors above...


I think we will see more of these given the extremely high resolution of current smartphone cameras.  A while back, I'd have occasional issues when posting uncropped pics from my full-frame Nikon.  But even my current cheapie Android pic dimensions far exceed my full-frame DSLR... 

[davo88]

Does the error happen any time a user attempts to post with an attachment, e.g., when replying to an existing topic?

No, everything works fine for regular members when starting a new topic via the regular New Topic button within a forum, or via the Reply button.

Or does it only fail when using the quick New Topic button?

Yes. Either the QNTB or the command shown by Sesquipedalian in post #5 above '... index.php?action=post'.

[Sesquipedalian]

As explained above, it's not due to QNTB. That mod merely makes SMF's boardless posting page more discoverable. The problem is with the boardless posting page itself.

Aside from that qualification, I agree entirely with your diagnosis, @shawnb61.

[davo88]

At issue, I think, is this line:
https://github.com/SimpleMachines/SMF/blob/7a757ab13e42ac20f88e9b30b807fd857defdec8/Sources/Attachments.php#L121

allowedTo() always returns true for admins, which is why it always works for admins.  But when an end user gets here via QNTB, there is no board yet, so $this->_board is NULL and allowedTo() returns false.

For both issues, since the attachment could not be created, the response is either incomplete or missing, so it cannot be parsed by .js.

So if all boards and all members are allowed to post attachments, is there any small code edit we can do, so that allowedTo() returns true and the attachment process completes OK?

[shawnb61]

A bug fix is needed in 2.1.x.

It is all setup to work properly, it's just that the requested board isn't passed.  That needs to be fixed.  Securely.

[Arantor]

Hypothetical: if you start a new topic today in board 1 where you already have permission, perform the uploads so that they're already on the server, then edit the form in the inspector to change the board id, what happens?

This is really the same scenario you actually face with the editor, that the point at which attachment permissions are checked for the board you're 'on' is not the same as the one potentially being checked when you submit the post.

In 2.0 they get garbage collected if not attached to anything but in 2.1 I think there's something more complex going on because they must somehow get attachment ids to be able to embed which means they must end up in the attachments table, meaning it could be possible today to bypass the permissions if there is a board you can post attachments to, even if it's not the one you're creating a new post in.

I don't have the brainpower to investigate this fully (work sucks), but I think there is already a deeper problem on hand than the board-less posting page just pretending you don't have proper permissions.

[Sesquipedalian]

meaning it could be possible today to bypass the permissions if there is a board you can post attachments to, even if it's not the one you're creating a new post in.

It's not. The permissions are checked again at submit, and if attachments are not allowed, they are removed then.

What is needed on the boardless posting page is a way to dynamically enable or disable the attachments UI depending on which board the user chooses in the select menu.