Support wildcards in json:// and yaml:// so that values can be retrieved with slice

[k1LoW]

ref: #534

Proposal

Support wildcards in json:// and yaml:// so that values can be retrieved with slice.

Only when a wildcard ( * ) is used, the expanded values become a slice.

[k1LoW]

vars.json and vars_array.json

[k1LoW]

@k2tzumi If you don't mind, I'd like to hear your opinion.

[k2tzumi]

If pattern matching with wildcards and . / (dot-dot-slash), there is a concern that directory traversal vulnerabilities may occur.

I have the impression that it would be difficult to use wild card matching because the order of appearance on the slice would be indefinite.

It seems to me that the goal of this PR should be more clearly defined.

• Solution to prevent vars from being fat
• Better Data Management Methods for Data Driven Testing

[k1LoW]

Thank you for your advice!

If pattern matching with wildcards and . / (dot-dot-slash), there is a concern that directory traversal vulnerabilities may occur.

Since we already allow dot-dot-slash, I thought it would be on the same level if wildcard was allowed?

because the order of appearance on the slice would be indefinite.

https://github.com/k1LoW/runn/pull/545/files#diff-29e5d1896212c61371d2eb62885b72355eb956d2b92da55ae85b11bcaa5212cfR66

It sorts the matched files. I think that this correspondence will at least fix the order.

It seems to me that the goal of this PR should be more clearly defined.

You are absolutely right.

Looking at #534,
I thought there was a request for one JSON file per application/json HTTP request, and one JSON file per application/json HTTP response.

I thought this PR might be a good idea since it is a feature enhancement and I can confirm that the modification will not affect existing implementations.

However, I have not thought deeply about this PR yet, so there may be other problems.

[k2tzumi]

Since we already allow dot-dot-slash, I thought it would be on the same level if wildcard was allowed?

Yes.
We believe that additional support for wildcards will increase the risk of vulnerability even more.

It sorts the matched files. I think that this correspondence will at least fix the order.

I think it's good.

I thought this PR might be a good idea since it is a feature enhancement and I can confirm that the modification will not affect existing implementations.

I was personally concerned about the potential security issues and the complexity that would be involved.

[github-actions]

Code Metrics Report

	main (249c950)	#545 (cf17537)	+/-
Coverage	70.1%	70.2%	+0.1%
Code to Test Ratio	1:0.7	1:0.7	-0.0
Test Execution Time	3m2s	3m54s	+52s

Details

  |                     | main (249c950) | #545 (cf17537) |  +/-  |
  |---------------------|----------------|----------------|-------|
+ | Coverage            |          70.1% |          70.2% | +0.1% |
  |   Files             |             54 |             54 |     0 |
  |   Lines             |           5867 |           5888 |   +21 |
+ |   Covered           |           4115 |           4133 |   +18 |
- | Code to Test Ratio  |          1:0.7 |          1:0.7 |  -0.0 |
  |   Code              |          11726 |          11759 |   +33 |
+ |   Test              |           8275 |           8282 |    +7 |
- | Test Execution Time |           3m2s |          3m54s |  +52s |

Code coverage of files in pull request scope (91.7% → 89.5%)

Files	Coverage	+/-
vars.go	89.5%	-2.2%

---

Reported by octocov

[k1LoW]

Some of the security concerns can now be suppressed by the scope.

Therefore, we are merging this feature.