CLDSRV-623: Bump arsenal for perf around error#5761
Conversation
Hello bourgoismickael,My role is to assist you with the merge of this Available options
Available commands
Status report is not available. |
32ac11a to
3c1ba0c
Compare
| As seen in https://scality.atlassian.net/browse/ARSN-477 | ||
| the `isValid` does the same parsing as `parseCIDR` but | ||
| encapsulate in try catch to return a boolean. | ||
| The `isValid` in catch is useless and the double try | ||
| discards completely any error from ipaddr.parseCIDR. | ||
|
|
||
| Meaning in case of invalid ip there will be 2 ipaddr.js parsing, | ||
| reducing perf for an ignored error. | ||
|
|
||
| Fixing this breaks the tests. | ||
|
|
||
| I'm not even sure of the purpose of using ipaddr.js | ||
| and using our regex after as our regex seems to be | ||
| more restrictive. | ||
|
|
||
| ipaddr.js accepts valid ip like: | ||
| - 0010.0xa5.1.1 | ||
| - ::ffff:222.1.41.900 |
There was a problem hiding this comment.
An if instead of a catch for isValid should be used, but do we really need to use ipaddr.js ?
There was a problem hiding this comment.
I think we can try to drop it but we need to be careful that it doesn't break the IP conditions in IAM/Bucket policies. These policies can test ranges and mix of ipv4 & ipv6 addresses.
There was a problem hiding this comment.
Note: this was implemented 1 year ago here: https://github.com/scality/cloudserver/pull/5501/files#diff-773344fcfc0f64145ff95eb6eccd556588c19449dc2c263a2532d4030bf00dffR490-R515
Since then the ipaddr.js parsing error has always been ignored due to the double try.
So removing it won't change the behavior but improve perf in case of invalid IP.
Now I don't know if we should handle special variations of ipv4 or ipv6 like it's done by ipaddr.js: https://www.npmjs.com/package/ipaddr.js/v/2.2.0?activeTab=code
And maybe our ipv6 regex is missing the cidr suffix: https://github.com/scality/cloudserver/blob/development/9.0/constants.js#L236-L237 ?
There was a problem hiding this comment.
Now I don't know if we should handle special variations of ipv4 or ipv6 like it's done by ipaddr.js
We control the ip we get in the request, from the code we have in arsenal, so as long as we guarantee the right IP format is returned, we are fine. In AWS, the condition either supports ipv4 or ipv6: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceip.
So I would say it's fine not to use ipaddr, as long as the regex is enough to ensure the lib will accept it in the actual logic (in Arsenal).
And maybe our ipv6 regex is missing the cidr suffix
Indeed.
There was a problem hiding this comment.
I'll drop the commit about ipCheck and have another ticket to compare with aws if the current regex is good and if we need to handle special ip
There was a problem hiding this comment.
Dropped and ticket is https://scality.atlassian.net/browse/CLDSRV-627
| As seen in https://scality.atlassian.net/browse/ARSN-477 | ||
| the `isValid` does the same parsing as `parseCIDR` but | ||
| encapsulate in try catch to return a boolean. | ||
| The `isValid` in catch is useless and the double try | ||
| discards completely any error from ipaddr.parseCIDR. | ||
|
|
||
| Meaning in case of invalid ip there will be 2 ipaddr.js parsing, | ||
| reducing perf for an ignored error. | ||
|
|
||
| Fixing this breaks the tests. | ||
|
|
||
| I'm not even sure of the purpose of using ipaddr.js | ||
| and using our regex after as our regex seems to be | ||
| more restrictive. | ||
|
|
||
| ipaddr.js accepts valid ip like: | ||
| - 0010.0xa5.1.1 | ||
| - ::ffff:222.1.41.900 |
There was a problem hiding this comment.
I think we can try to drop it but we need to be careful that it doesn't break the IP conditions in IAM/Bucket policies. These policies can test ranges and mix of ipv4 & ipv6 addresses.
70ef4e8 to
3c09b1a
Compare
ghost
left a comment
There was a problem hiding this comment.
LGTM
There is a merge commit that should be properly removed by rebasing the PR (it's hard to review with it)
|
Maybe a github display issue, all good if we see only your changes 🙂 |
e88ce9f to
94d0ffe
Compare
Request integration branchesWaiting for integration branch creation to be requested by the user. To request integration branches, please comment on this pull request with the following command: Alternatively, the |
|
/create_integration_branches |
|
/create_pull_requests |
Integration data createdI have created the integration data for the additional destination branches.
The following branches will NOT be impacted:
Follow integration pull requests if you would like to be notified of The following options are set: create_pull_requests, create_integration_branches |
Waiting for approvalThe following approvals are needed before I can proceed with the merge:
The following options are set: create_pull_requests, create_integration_branches |
|
/approve |
|
I have successfully merged the changeset of this pull request
The following branches have NOT changed:
Please check the status of the associated issue CLDSRV-623. Goodbye bourgoismickael. The following options are set: approve, create_pull_requests, create_integration_branches |

Check by commit