It would be useful if the user could edit/add these as part of their profile settings. maybe as a bit of an advanced setting or something..
What do you think, user specified YAML file or CLI provided pattern(or input name) and value pairs (like the redundancy filters)?
I would say CLI provided pattern and value pairs, but this could get messy when adding more than a few. so maybe the YAML file would be the cleanest. Would you add the existing default values into a YAML file also so the user could just copy/modify/add to that as required?
What are the pros / cons from your point of view?
Ideally, I'd like to support both, the CLI pairs as a quick and easy access and the YAML file for more elaborate data. Sort of like the cookie options.
The existing values would become the hardcoded defaults for that option and get merged with whatever the user provides. I could also add an option to ignore the defaults and just use the user-provided ones.
The provided YAML file would be consumed immediately and when dumping the profile the AFP file would contain the effective values for that option. And since the profile would be a simple YAML file you would be able to modify those values at that point too.
I think that ought to cover most use-cases.
Are you saying you would like to do both but will only do one? If you implemented both that would be awesome, and cover all use cases i can think of, but if choosing only one I think i would go with YAML. although the ignore defaults options is a must for both options.
Cheers for taking your time to add this also, its greatly appreciated.
No I'm saying I'd like to do only one (because it's kind of a boring feature to work on, heh) but I better (and will) do both since it's the right thing to do.
I appreciate your appreciation.
That would be awesome, thanks.
PATTERN to match against input names and VALUE to use for them.
(Can be used multiple times.)
YAML file containing a Hash object with regular expressions, to match against input names, as keys and input values as values.
Do not use the system default input values.
--input-force Fill-in even non-empty inputs.
Looks alright, right?
Yep, that looks awesome. I assume --input-force will use the arachni default of "1" or whatever it is?Also, with the YAML file and the regex matching, will it be hierarchical in that if there are multiple regex matches it will use the first one defined? That way we can finish off with a wildcard default value to be used.
You're right on the priority of the matches, as for the default, that's what's going to happen but I realize I don't like that. I'll change behavior so force will only apply when there's a match.
I'll also append a // (empty pattern) catch-all at the end to be the default, unless the user has provided one.