spec params

[tarekziade]

@jvehent

we have some parameters like rfc3339date and also some regexp.

It makes it hard to distinguish constants from regexps or other things

I'd like to clarify the syntax, and add a prefix to provide the type when it's not a constant, and also simple matches to avoid writhing regexps

• RFC3339 => must be a matching date value
• regexp:[a-zA-Z0-9]{1,64} => regexp (^ and $ are implicit)
• digits:1,20 => must be a positive number with 1 to 20 digits
• digits:4 => must be a positive number, must be 4 digits
• values: action|command|agent|12 => a discrete list of values

[tarekziade]

also note that lua's regexp implementation is not the posix implementation - so we might get some surprises there

[tarekziade]

Forget about this last comment - lrexlib has a posix implementation - https://github.com/rrthomas/lrexlib

[tarekziade]

Another remark: should we have a way to mark mandatory options from non-mandatory ones in GETs ?

[jvehent]

Yes, we should. We can either nest it under the parameter name, or create a parameter array. Which one do you prefer?

Nested under the parameter name:

            "/action": {
                "GET": {
                    "parameters": {
                        "actionid": {
                            "validation": "digits:1,20",
                            "required": true
                        },
                        "caribouName": {
                            "validation": "regex:[a-zA-Z0-9]{1,64}",
                            "required": false
                        },
                   }
                }
            }

In a parameters array

            "/action": {
                "GET": {
                    "parameters": [
                        {
                            "name": "actionid",
                            "validation": "digits:1,20",
                            "required": true
                        },
                        {
                            "name": "caribouName",
                            "validation": "regex:[a-zA-Z0-9]{1,64}",
                            "required": false
                        },
                   ]
                }
            }

[jvehent]

A few more types that would be useful, may be defined as default regexes under the hood:

• fqdn => a fully qualified domain name
• email => an email address

ipv4 and ipv6 would be useful as well, especially if properly defined (not as regexes) so we can do IP/network operations on them. Example: is 172.21.13.34 in network 172.20.0.0/23?

[tarekziade]

ok great, will add all of this

[tarekziade]

btw I like your first one better, it's simpler to parse :)

[jvehent]

For GET requests, the name would be a query parameter. That's fairly easy. What about POST requests? Should it be a form parameter? Or should we not attempt to match parameters in POST requests?

[tarekziade]

What about POST requests? Should it be a form parameter? Or should we not attempt to match parameters in POST requests?

I don't know. In my use cases, we have to parse and validate the POST data in any case, so I am not sure if an extra (de)serialization has a benefit

But maybe you have some infrasec use cases on your side ?

[tarekziade]

okay I have implemented everything in here