View Issue Details

IDProjectCategoryView StatusLast Update
0034431mantisbtattachmentspublic2024-05-21 05:35
Reporterj_schultz Assigned To 
Status acknowledgedResolutionopen 
Product Version2.26.1 
Summary0034431: Anti-spam measure counts individual file uploads separately, even when done as a single user interaction

The way Mantis' built-in anti-spam measures handle file uploads is a bit problematic for users, especially those that are not aware how the anti-spam feature works. I would say this became more problematic with Mantis 2.0 because its more modern user interface makes it a lot easier to run into this situation as it allows uploading multiple attachments at once.

So what's the problem? When you attach files to an issue, every individual file counts towards the anti-spam limit, even when they are uploaded within the same user interaction. So if a user were to attach, say, 11 image files to an issue (assuming the default $g_antispam_max_event_count = 10), the upload will fail for the 11th image file, and the user is not redirected to the updated bug page where they could see the result of their action. If they manually refresh the page, they will see that only 10 images were uploaded, and if they tried to upload the 11th image, it would fail again, this time with an error message (application error 27).

So what's the solution to this problem? For a start, I believe that batch uploads should count as a single anti-spam event, as they are a single user interaction, and will send a single notification mail. If you disagree with that assessment, I guess that the file picker should avoid being able to run into that situation, so if for example the remaining number of anit-spam actions is, say, 4, then the user should receive a warning that only 4 out of X attachments can be uploaded. But I would very much prefer the first solution.

TagsNo tags attached.




2024-05-21 05:35

developer   ~0068944

I agree with your assessment, indeed it would make sense to consider multiple, simultaneous file uploads as a single event. I have not looked a the code, so not sure about the complexity / feasibility of implementing that change.

As a workaround, you could adapt $g_antispam_max_event_count, taking $g_file_upload_max_num into consideration.