View Issue Details

IDProjectCategoryView StatusLast Update
0025452mantisbtattachmentspublic2019-03-16 20:21
Reportertitovetch Assigned Tocproensa  
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Product Version2.19.0 
Target VersionFixed in Version 
Summary0025452: there is no validation on $g_max_file_size
Description

i have set $g_max_file_size=500 by mistake and found that there is no validation on the attachments if you put a comments with attachment, only the comment will be posted

Steps To Reproduce

1 - set $g_max_file_size =500
2 - comment to any ticket with attachment

TagsNo tags attached.

Relationships

related to 0025463 closedcproensa Dropzone max-filesize option is not correct 
related to 0025464 closedcproensa Enforce max-filesize in dropzone to alert and drop big files before form submission 
related to 0025453 closedatrol attachments missed in the creation of the ticket 

Activities

atrol

atrol

2019-02-07 12:40

developer   ~0061440

I am not able to reproduce using the given information.

When trying I get

APPLICATION ERROR #500
File upload failed. This is likely because the filesize was larger than is currently allowed by this PHP installation.

Certainly not the best possible error message, as you get it if the file size is greater than one of 3 settings.
$t_max_file_size = (int)min( ini_get_number( 'upload_max_filesize' ), ini_get_number( 'post_max_size' ), config_get( 'max_file_size' ) );

titovetch

titovetch

2019-02-08 09:06

reporter   ~0061453

i have tried the same in 2 environment and there is no error in validation and the comment posted.

Steps To Reproduce:

1- this my default setting for PHP and MYSQL
2- try to comment without $g_max_file_size using RAR file with size 11M and the comments posed without the attachment or an error
3- try to comment using the $g_max_file_size = 5000000; with the same RAR file with size 11M and the comments posed without the attachment or an error



Setting.png (11,826 bytes)
Setting.png (11,826 bytes)
atrol

atrol

2019-02-10 07:22

developer   ~0061471

Do you store attachments in database or on disk?
Do you get any error or warnings when running admin/check/index.php ?
Are there any error or warnings in web server, database or PHP logs?
Have you any 3rd party plugins installed ?
Did you change any source of Mantis?
Did you change $g_display_errors setting?

cproensa

cproensa

2019-02-10 08:20

developer   ~0061472

Dropzone is configured with a max-files-size setting. When a file in its queue is bigger that that, the file is silently ignored and not uploaded.
Thus, there is no error, but no attachment either.

Additionally, that configuration is weak, see 0025463 and 0025464

i think the scenario reported here is believable.

cproensa

cproensa

2019-02-10 08:26

developer   ~0061473

The fact that atrol reproduces the server side error, also as i have experience usually, is probably:

  • config_get( 'max_file_size' ) = 5M (as mantis default)
  • ini_get_number( 'upload_max_filesize' ) = 2M (as php default)

files between 2M and 5M will be fine in dropzone, but gets an error at server side.
files >5M will be ignored by dropzone, and get no error nor attachment at server side.

atrol

atrol

2019-02-10 08:31

developer   ~0061474

Thanks @cproensa 0025452:0061473 probably explains it.

titovetch

titovetch

2019-02-11 06:13

reporter   ~0061479

Do you store attachments in database or on disk?
==> databse
Do you get any error or warnings when running admin/check/index.php ?
==>attached
Are there any error or warnings in web server, database or PHP logs?
==>no
Have you any 3rd party plugins installed ?
==>no
Did you change any source of Mantis?
==>no
Did you change $g_display_errors setting?
==>no

i'm using WAMP server and i have updated it to the new version and forget to increase all values needed in MYSQL and PHP thats why the error happen accidentally .

i think its related to tickets 0025453 as well



check.JPG (81,430 bytes)
check.JPG (81,430 bytes)
atrol

atrol

2019-02-25 15:50

developer   ~0061573

@titovetch I expect that this issue is fixed as the related issues have been fixed.
Can you confirm? Maybe you could try latest nightly build https://www.mantisbt.org/builds.php

titovetch

titovetch

2019-02-27 13:15

reporter   ~0061594

Thanks @artol,i have tested the last nightly version and i found that :
1- a warning pop messages appeared after dropping the file [good]
2- message appear when the mouse passes over the dropzone element which is good but the message hide the attachment information and it could be better if we put it after remove button
3-there is a different between the warning message size and dropzone element size
4- in case the attachment exceed the $g_max_file_size ,its accept to create comment/ticket without the attachment and i see its better if we prevent the process until the user upload relevant size

all scenarios have been done on commenting and creating ticket



IMG 1.PNG (7,118 bytes)
IMG 1.PNG (7,118 bytes)
1.PNG (7,809 bytes)
1.PNG (7,809 bytes)
2.PNG (7,613 bytes)
2.PNG (7,613 bytes)
cproensa

cproensa

2019-02-27 17:29

developer   ~0061598

Last edited: 2019-02-27 17:30

View 2 revisions

@titovetch
I see strange, that a file that exceeds the allowed size, which triggers the new dialog, stays enqued in the dropzone area.
The triggering of the dialog ALSO removes the file from the dropzone.
Have you cleared cached files in browser, to load the new javascripts completely?

2- message appear when the mouse passes over the dropzone element which is good but the message hide the attachment information and it could be better if we put it after remove button

That is an overlayed message, i wouldn't pay much care to the exact layout, considering thet the file should not be ther in the first place (as said before)

3-there is a different between the warning message size and dropzone element size

Probably becasue: one says MiB = (1024*1024 bytes), and the preview shows MB (1000*1000 bytes). That's one inconsistency in dropzone, i saw it commented in their project issues too.

in case the attachment exceed the $g_max_file_size ,its accept to create comment/ticket without the attachment and i see its better if we prevent the process until the user upload relevant size

Yes, that may be revised, but it's part of the server side code.
I tried the client side because it can now easily prevent most, almost all, errors caused by the file sizes, for web ui users.

thE_iNviNciblE

thE_iNviNciblE

2019-02-28 17:22

reporter   ~0061605

the screen explains my error on my server "File is to big"

titovetch

titovetch

2019-03-05 15:34

reporter   ~0061629

Last edited: 2019-03-05 15:34

View 2 revisions

I see strange, that a file that exceeds the allowed size, which triggers the new dialog, stays enqued in the dropzone area.
The triggering of the dialog ALSO removes the file from the dropzone.
Have you cleared cached files in browser, to load the new javascripts completely?

fixed after clearing the cash

Yes, that may be revised, but it's part of the server side code.
I tried the client side because it can now easily prevent most, almost all, errors caused by the file sizes, for web ui users.

unfortunately if file exceeds the allowed size during creating /commenting an misleading error message appear, do we need to create a new ticket to prevent any action if the size exceeds?

titovetch

titovetch

2019-03-05 15:38

reporter  

rr.PNG (11,024 bytes)
rr.PNG (11,024 bytes)
cproensa

cproensa

2019-03-05 16:37

developer   ~0061633

unfortunately if file exceeds the allowed size during creating /commenting an misleading error message appear, do we need to create a new ticket to prevent any action if the size exceeds?

Note that the image you attached is an unrelated error: "invalid form security token". Probably a token timeout, but still unrelated to attachment sizes.
If by any mean, the server side receives a request with a file that exceed the allowed size, an error is displayed, but the issue is created anyways (and the file silently dropped).
This is reported here: 0003759

cproensa

cproensa

2019-03-05 16:52

developer   ~0061637

@titovetch
Thanks for your feedback.
I'm going to set this issue as resolved, since all the points are either resolved, or previously reported, with the related issued

thE_iNviNciblE

thE_iNviNciblE

2019-03-06 04:26

reporter   ~0061641

i hope you solved it :-)

Issue History

Date Modified Username Field Change
2019-02-07 11:15 titovetch New Issue
2019-02-07 12:40 atrol Status new => feedback
2019-02-07 12:40 atrol Note Added: 0061440
2019-02-08 09:06 titovetch File Added: Setting.png
2019-02-08 09:06 titovetch Note Added: 0061453
2019-02-08 09:06 titovetch Status feedback => new
2019-02-09 14:37 cproensa Relationship added related to 0025464
2019-02-09 14:38 cproensa Relationship added related to 0025463
2019-02-10 07:22 atrol Status new => feedback
2019-02-10 07:22 atrol Note Added: 0061471
2019-02-10 08:20 cproensa Note Added: 0061472
2019-02-10 08:26 cproensa Note Added: 0061473
2019-02-10 08:31 atrol Note Added: 0061474
2019-02-11 06:13 titovetch File Added: check.JPG
2019-02-11 06:13 titovetch Note Added: 0061479
2019-02-11 06:13 titovetch Status feedback => new
2019-02-24 10:21 atrol Relationship added related to 0025453
2019-02-25 15:50 atrol Status new => feedback
2019-02-25 15:50 atrol Note Added: 0061573
2019-02-27 13:15 titovetch File Added: IMG 1.PNG
2019-02-27 13:15 titovetch File Added: 1.PNG
2019-02-27 13:15 titovetch File Added: 2.PNG
2019-02-27 13:15 titovetch Note Added: 0061594
2019-02-27 13:15 titovetch Status feedback => new
2019-02-27 17:29 cproensa Note Added: 0061598
2019-02-27 17:30 cproensa Note Edited: 0061598 View Revisions
2019-02-28 17:22 thE_iNviNciblE Note Added: 0061605
2019-03-05 15:34 titovetch Note Added: 0061629
2019-03-05 15:34 titovetch Note Edited: 0061629 View Revisions
2019-03-05 15:38 titovetch File Added: rr.PNG
2019-03-05 16:37 cproensa Note Added: 0061633
2019-03-05 16:52 cproensa Note Added: 0061637
2019-03-05 16:52 cproensa Assigned To => cproensa
2019-03-05 16:52 cproensa Status new => resolved
2019-03-05 16:52 cproensa Resolution open => fixed
2019-03-06 04:26 thE_iNviNciblE Note Added: 0061641
2019-03-16 20:21 vboctor Status resolved => closed