Add RangeValidator for take paramater

[bnematzadeh]

Description

In the user.get.js file, no validator has been implemented for the take field. A client could send a request to the following endpoint and set takes to a large value, which could lead to reduced performance and a potential DoS attack on the application. I have added a new validator called RangeError.

In all controllers, it’s better to check that the value provided by the client does not exceed a certain range before passing this parameter to the database. For this purpose, I wrote two different tests: one for when the takes value is out of range, and another for when it is within the valid range.

if (optionsWithDefault.take) {
    if (optionsWithDefault.take > DEFAULT_OPTIONS.limit) {
      throw new RangeError('The value of the limit parameter is out of range');
    }
    queryParams.limit = optionsWithDefault.take;
  }

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.52%. Comparing base (216f637) to head (071e253).
Report is 19 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2169      +/-   ##
==========================================
+ Coverage   98.50%   98.52%   +0.02%     
==========================================
  Files         867      867              
  Lines       14243    14277      +34     
==========================================
+ Hits        14030    14067      +37     
+ Misses        213      210       -3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[relativeci]

#2867 Bundle Size — 10.26MiB (0%).

071e253(current) vs 2540927 master#2858(baseline)

Warning

Bundle contains 3 duplicate packages – View duplicate packages

Bundle metrics  no changes

	Current #2867	Baseline #2858
Initial JS	5.56MiB	5.56MiB
Initial CSS	304.68KiB	304.68KiB
Cache Invalidation	0%	54.06%
Chunks	51	51
Assets	171	171
Modules	1495	1495
Duplicate Modules	21	21
Duplicate Code	0.84%	0.84%
Packages	124	124
Duplicate Packages	3	3

Bundle size by type  no changes

	Current #2867	Baseline #2858
JS	7.35MiB	7.35MiB
IMG	2.48MiB	2.48MiB
CSS	321.47KiB	321.47KiB
Fonts	93.55KiB	93.55KiB
Other	17.62KiB	17.62KiB
HTML	13.58KiB	13.58KiB

Bundle analysis report Branch bnematzadeh:gladys-sec-4 Project dashboard

---

^{Generated by RelativeCI Documentation Report issue}

[Pierre-Gilles]

@bnematzadeh Why not, but it's a bit of cherrypicking in the case of Gladys :) Don't forget that Gladys is a self-hosted/local software, and when you talk about the "client", it's the same person that started Gladys server, so if the "client" is asking for a big ?take, the user could ddos... his own server! :D

[bnematzadeh]

@bnematzadeh Why not, but it's a bit of cherrypicking in the case of Gladys :) Don't forget that Gladys is a self-hosted/local software, and when you talk about the "client", it's the same person that started Gladys server, so if the "client" is asking for a big ?take, the user could ddos... his own server! :D

You're right. In any case, this can also be added to the code to ensure the parameter is sent within a specific range. Overall, I agree with you.

[Pierre-Gilles]

In any case, this can also be added to the code to ensure the parameter is sent within a specific range.

Yes, but I don't think it's worth it to put it everywhere.

For example, the "GET user" should return only a few rows, as most people have from 1 to 5 users at home (depending on how many people are living in this home), so I don't think this route is a good candidate.

Routes with millions of rows are better candidates, but I still think that in some case it could be useful to query millions of rows.

For example, the other day, I wanted to know the minimum temperature recorded during this summer on my outside temperature sensor, so I asked for the last 200k rows, and I received them without any issues (it was 4.6Mb, retrieved in 500ms).

If there was a low limit, I couldn't have done it

[Pierre-Gilles]

@bnematzadeh So what so you think?

[Pierre-Gilles]

I'm closing this, don't hesitate if you have any other feedback :)