lua-resty-validation is an extendable chaining validation and filtering library for Lua and OpenResty.
local validation = require "resty.validation"
local valid, e = validation.number:between(0, 9)(5) -- valid = true, e = 5
local valid, e = validation.number:between(0, 9)(50) -- valid = false, e = "between"
-- Validators can be reused
local smallnumber = validation.number:between(0, 9)
local valid, e = smallnumber(5) -- valid = true, e = 5
local valid, e = smallnumber(50) -- valid = false, e = "between"
-- Validators can do filtering (i.e. modify the value being validated)
-- valid = true, s = "HELLO WORLD!"
local valid, s = validation.string.upper "hello world!"
-- You may extend the validation library with your own validators and filters...
validation.validators.capitalize = function(value)
return true, value:gsub("^%l", string.upper)
end
-- ... and then use it
local valid, e = validation.capitalize "abc" -- valid = true, e = "Abc"
-- You can also group validate many values
local group = validation.new{
artist = validation.string:minlen(5),
number = validation.tonumber:equal(10)
}
local valid, fields, errors = group{ artist = "Eddie Vedder", number = "10" }
if valid then
print("all the group fields are valid")
else
print(fields.artist.name, fields.artist.error,
fields.artist.valid, fields.artist.invalid,
fields.artist.input, fields.artist.value, ,
fields.artist.validated, fields.artist.unvalidated)
end
-- You can even call fields to get simple name, value table
-- (in that case all the `nil`s are removed as well)
-- By default this returns only the valid fields' names and values:
local data = fields()
local data = fields "valid"
-- To get only the invalid fields' names and values call:
local data = fields "invalid"
-- To get only the validated fields' names and values call (whether or not they are valid):
local data = fields "validated"
-- To get only the unvalidated fields' names and values call (whether or not they are valid):
local data = fields "unvalidated"
-- To get all, call:
local data = fields "all"
-- Or combine:
local data = fields("valid", "invalid")
-- This doesn't stop here. You may also want to get only some fields by their name.
-- You can do that by calling (returns a table):
local data = data{ "artist" }Just place validation.lua and validation directory somewhere in your package.path, under resty directory. If you are using OpenResty, the default location would be /usr/local/openresty/lualib/resty.
$ opm get bungle/lua-resty-validation$ luarocks install lua-resty-validationLuaRocks repository for lua-resty-validation is located at https://luarocks.org/modules/bungle/lua-resty-validation.
lua-resty-validation comes with several built-in validators, and the project is open for contributions of more validators.
Type validators can be used to validate the type of the validated value. These validators are argument-less
validators (call them with dot .):
nullor["nil"](as the nil is a reserved keyword in Lua)booleannumberstringtableuserdatafuncor["function"](as the function is a reserved keyword in Lua)callable(either a function or a table with metamethod__call)threadintegerfloatfile(io.type(value) == 'file')
Type conversion filters:
tostringtonumbertointegertoboolean
Other filters:
tonilortonullabsinfnanfinitepositivenegativeloweruppertrimltrimrtrimreverseemailoptional
local validation = require "resty.validation"
local ok, e = validation.null(nil)
local ok, e = validation.boolean(true)
local ok, e = validation.number(5.2)
local ok, e = validation.string('Hello, World!')
local ok, e = validation.integer(10)
local ok, e = validation.float(math.pi)
local f = assert(io.open('filename.txt', "r"))
local ok, e = validation.file(f)Validation factory consist of different validators and filters used to validate or filter the value
(call them with colon :):
type(t), validates that the value is of typet(see Type Validators)nil()or["null"](), check that value type isnilboolean(), check that value type isbooleannumber(), check that value type isnumberstring(), check that value type isstringtable(), check that value type istableuserdata(), check that value type isuserdatafunc()or["function"](), check that value type isfunctioncallable(), check that value is callable (aka a function or a table with metamethod__call)thread(), check that value type isthreadinteger(), check that value type isintegerfloat(), check that value type isfloatfile(), check that value type isfile(io.type(value) == 'file')abs(), filters value and returns absolute value (math.abs)inf(), checks that the value isinfor-infnan(), checks that the value isnanfinite(), checks that the value is notnan,infor-infpositive(), validates that the value is positive (> 0)negative(), validates that the value is negative (< 0)min(min), validates that the value is at leastmin(>=)max(max), validates that the value is at mostmax(<=)between(min[, max = min]), validates that the value is betweenminandmaxoutside(min[, max = min]), validates that the value is not betweenminandmaxdivisible(number), validates that the value is divisible withnumberindivisible(number), validates that the value is not divisible withnumberlen(min[, max = min]), validates that the length of the value is exactlyminor betweenminandmax(UTF-8)minlen(min), validates that the length of the value is at leastmin(UTF-8)maxlen(max), validates that the length of the value is at mostmax(UTF-8)equals(equal)orequal(equal), validates that the value is exactly somethingunequals(equal)orunequal(equal), validates that the value is not exactly somethingoneof(...), validates that the value is equal to one of the supplied argumentsnoneof(...), validates that the value is not equal to any of the supplied argumentsmatch(pattern[, init]), validates that the value matches (string.match) the patternunmatch(pattern[, init]), validates that the value does not match (string.match) the patterntostring(), converts value to stringtonumber([base]), converts value to numbertointeger(), converts value to integertoboolean(), converts value to boolean (usingnot not value)tonil()ortonull(), converts value to nillower(), converts value to lower case (UTF-8 support is not yet implemented)upper(), converts value to upper case (UTF-8 support is not yet implemented)trim([pattern]), trims whitespace (you may use pattern as well) from the left and the rightltrim([pattern]), trims whitespace (you may use pattern as well) from the leftrtrim([pattern]), trims whitespace (you may use pattern as well) from the rightstarts(starts), checks if string starts withstartsends(ends), checks if string ends withendsreverse, reverses the value (string or number) (UTF-8)coalesce(...), if the value is nil, returns first non-nil value passed as argumentsemail(), validates that the value is email addresscall(function), validates / filters the value against custom inline validator / filteroptional([default]), stops validation if the value is empty string""orniland returnstrue, and either,defaultorvalue
For all the Validation Factory Validators there is a conditional version that always validates to true, but where you can replace the actual value depending whether the original validator validated. Hey, this is easier to show than say:
local validation = require "resty.validation"
-- ok == true, value == "Yes, the value is nil"
local ok, value = validation:ifnil(
"Yes, the value is nil",
"No, you did not supply a nil value")(nil)
-- ok == true, value == "No, you did not supply a nil value"
local ok, value = validation:ifnil(
"Yes, the value is nil",
"No, you did not supply a nil value")("non nil")
-- ok == true, value == "Yes, the number is betweeb 1 and 10"
local ok, value = validation:ifbetween(1, 10,
"Yes, the number is between 1 and 10",
"No, the number is not between 1 and 10")(5)
-- ok == true, value == "No, the number is not between 1 and 10"
local ok, value = validation:ifbetween(1, 10,
"Yes, the number is between 1 and 10",
"No, the number is not between 1 and 10")(100)The last 2 arguments to conditional validation factory validators are the truthy and falsy values.
Every other argument is passed to the actual validation factory validator.
lua-resty-validation currently supports a few predefined validators:
compare(comparison), compares two fields and sets fields invalid or valid according to comparisonrequisite{ fields }, at least of of the requisite fields is required, even if they by themselves are optionalrequisites({ fields }, number), at leastnumberof requisites fields are required (by default all of them)call(function), calls a custom (or inline) group validation function
local ispassword = validation.trim:minlen(8)
local group = validation.new{
password1 = ispassword,
password2 = ispassword
}
group:compare "password1 == password2"
local valid, fields, errors = group{ password1 = "qwerty123", password2 = "qwerty123" }
local optional = validation:optional"".trim
local group = validation.new{
text = optional,
html = optional
}
group:requisite{ "text", "html" }
local valid, fields, errors = group{ text = "", html = "" }
local optional = validation:optional ""
local group = validation.new{
text = optional,
html = optional
}
group:requisites({ "text", "html" }, 2)
-- or group:requisites{ "text", "html" }
local valid, fields, errors = group{ text = "", html = "" }
group:call(function(fields)
if fields.text.value == "hello" then
fields.text:reject "text cannot be 'hello'"
fields.html:reject "because text was 'hello', this field is also invalidated"
end
end)You can use normal Lua relational operators in compare group validator:
<><=>===~=
requisite and requisites check if the field value is nil or ""(empty string).
With requisite, if all the specified fields are nil or "" then all the fields are
invalid (provided they were not by themselves invalid), and if at least one of the fields
is valid then all the fields are valid. requisites works the same, but there you can
define the number of how many fields you want to have a value that is not nil and not
an empty string "". These provide conditional validation in sense of:
- I have (two or more) fields
- All of them are optional
- At least one / defined number of fields should be filled but I don't care which one as long as there is at least one / defined number of fields filled
Stop validators, like optional, are just like a normal validators, but instead of returning
true or false as a validation result OR as a filtered value, you can return validation.stop.
This value can also be used inside conditional validators and in validators that support default values. Here is how
the optional validator is implemented:
function factory.optional(default)
return function(value)
if value == nil or value == "" then
return validation.stop, default ~= nil and default or value
end
return true, value
end
endThese are roughly equivalent:
-- Both return: true, "default" (they stop prosessing :minlen(10) on nil and "" inputs
local input = ""
local ok, val = validation.optional:minlen(10)(input)
local ok, val = validation:optional(input):minlen(10)(input)
local ok, val = validation:ifoneof("", nil, validation.stop(input), input):minlen(10)(input)Most of the validators, that are not filtering the value, only return true or false as a result.
That means that there is now no way to signal resty.validation to actually set the value to nil.
So there is a work-around, you can return validation.nothing as a value, and that will change the
value to nil, e.g. the built-in tonil validator is actually implemented like this (pseudo):
function()
return true, validation.nothing
endSometimes you may just have one-off validators / filters that you are not using elsewhere, or that you just
want to supply quickly an additional validator / filter for a specific case. To make that easy and straight
forward, we introduced call factory method with lua-resty-validation 2.4. Here is an example:
validation:call(function(value)
-- now validate / filter the value, and return the results
-- here we just return false (aka making validation to fail)
return false
end)("Check this value"))(of course it doesn't need to be inline function as in Lua all functions are first class citizens and they can be passed around as parameters)
Currently lua-resty-validation has support for two extensions or plugins that you can enable:
resty.validation.ngxresty.validation.tzresty.validation.utf8
These are something you can look at if you want to build your own validator extension. If you do so, and think that it would be usable for others as well, mind you to send your extension as a pull-request for inclusion in this project, thank you very much, ;-).
As the name tells, this set of validator extensions requires OpenResty (or Lua Nginx module at least). To use this extension all you need to do is:
require "resty.validation.ngx"It will monkey patch the adapters that it will provide in resty.validation, and those are currently:
escapeuriunescapeuribase64encbase64deccrc32shortcrc32longcrc32md5
(there is both factory and argument-less version of these)
There is also regex matcher in ngx extension that uses ngx.re.match, and parameterized md5:
regex(regex[, options])md5([bin])
require "resty.validation.ngx"
local validation = require "resty.validation"
local valid, value = validation.unescapeuri.crc32("https://github.com/")
local valid, value = validation:unescapeuri():crc32()("https://github.com/")This set of validators and filters is based on the great luatz
library by @daurnimator, that is a library for time and date manipulation. To use this extension, all you need
to do is:
require "resty.validation.tz"It will monkey patch the adapters that it will provide in resty.validation, and those are currently:
totimetabletotimestamp
(there is both factory and argument-less version of these)
totimestamp and totimetable filters work great with HTML5 date and datetime input fields. As the name
tells, totimetable returns luatz timetable and totimestamp returns seconds since unix epoch (1970-01-01)
as a Lua number.
require "resty.validation.tz"
local validation = require "resty.validation"
local valid, ts = validation.totimestamp("1990-12-31T23:59:60Z")
local valid, ts = validation.totimestamp("1996-12-19")This set of validators and filters is based on the great utf8rewind
library by Quinten Lansu - a system library written in C designed to extend the default string handling functions
with support for UTF-8 encoded text. It needs my LuaJIT FFI wrapper lua-resty-utf8rewind
to work. When the mentioned requirements are installed, the rest is easy. To use this extension, all you need
to do is:
require "resty.validation.utf8"It will monkey patch the adapters that it will provide in resty.validation, and those are currently:
utf8upperutf8lowerutf8title
(there is both factory and argument-less version of these)
There is also a few factory validators / filters:
utf8normalize(form)utf8category(category)
The utf8normalize normalizes the UTF-8 input to one of these normalization formats:
C(orNFC)D(orNFD)KC(orNFKC)KD(orNFKD)
The utf8category checks that the input string is in one of the following categories (so, you may think it has
multiple validators built-in to work with UTF-8 string validation):
LETTER_UPPERCASELETTER_LOWERCASELETTER_TITLECASELETTER_MODIFIERCASE_MAPPEDLETTER_OTHERLETTERMARK_NON_SPACINGMARK_SPACINGMARK_ENCLOSINGMARKNUMBER_DECIMALNUMBER_LETTERNUMBER_OTHERNUMBERPUNCTUATION_CONNECTORPUNCTUATION_DASHPUNCTUATION_OPENPUNCTUATION_CLOSEPUNCTUATION_INITIALPUNCTUATION_FINALPUNCTUATION_OTHERPUNCTUATIONSYMBOL_MATHSYMBOL_CURRENCYSYMBOL_MODIFIERSYMBOL_OTHERSYMBOLSEPARATOR_SPACESEPARATOR_LINESEPARATOR_PARAGRAPHSEPARATORCONTROLFORMATSURROGATEPRIVATE_USEUNASSIGNEDCOMPATIBILITYISUPPERISLOWERISALPHAISDIGITISALNUMISPUNCTISGRAPHISSPACEISPRINTISCNTRLISXDIGITISBLANKIGNORE_GRAPHEME_CLUSTER
require "resty.validation.utf8"
local validation = require "resty.validation"
local valid, ts = validation:utf8category("LETTER_UPPERCASE")("TEST")This set of validators and filters is based on the great libinjection
library by Nick Galbreath - a SQL / SQLI / XSS tokenizer parser analyzer. It needs my LuaJIT FFI wrapper
lua-resty-injection to work. When the mentioned requirements
are installed, the rest is easy. To use this extension, all you need to do is:
require "resty.validation.injection"It will monkey patch the adapters that it will provide in resty.validation, and those are currently:
sqli, returnsfalseif SQL injection was detected, otherwise returnstruexss, returnsfalseif Cross-Site Scripting injection was detected, otherwise returnstrue
require "resty.validation.injection"
local validation = require "resty.validation"
local valid, ts = validation.sqli("test'; DELETE FROM users;")
local valid, ts = validation.xss("test <script>alert('XSS');</script>")I'm not going here for details for all the different validators and filters there is because they all follow the same logic, but I will show some general ways how this works.
This field contains a version of the validation library, e.g. it's value can be "2.5" for
the version 2.5 of this library.
That ... means the validation chain. This is used to define a single validator chain. There is no limit to
chain length. It will always return boolean (if the validation is valid or not). The second return value will
be either the name of the filter that didn't return true as a validation result, or the filtered value.
local v = require "resty.validation"
-- The below means, create validator that checks that the input is:
-- 1. string
-- If, it is, then trim whitespaces from begin and end of the string:
-- 2. trim
-- Then check that the trimmed string's length is at least 5 characters (UTF-8):
-- 3. minlen(5)
-- And if everything is still okay, convert that string to upper case
-- (UTF-8 is not yet supported in upper):
-- 4. upper
local myvalidator = v.string.trim:minlen(5).upper
-- This example will return false and "minlen"
local valid, value = myvalidator(" \n\t a \t\n ")
-- This example will return true and "ABCDE"
local valid, value = myvalidator(" \n\t abcde \t\n ")Whenever the validator fails and returns false, you should not use the returned value for other purposes than
error reporting. So, the chain works like that. The lua-resty-validation will not try to do anything if you
specify chains that will never get used, such as:
local v = require "resty.validation"
-- The input value can never be both string and number at the same time:
local myvalidator = v.string.number:max(3)
-- But you could write this like this
-- (take input as a string, try to convert it to number, and check it is at most 3):
local myvalidator = v.string.tonumber:max(3)As you see, this is a way to define single reusable validators. You can for example predefine your set of basic single validator chains and store it in your own module from which you can reuse the same validation logic in different parts of your application. It is good idea to start defining single reusable validators, and then reuse them in group validators.
E.g. say you have module called validators:
local v = require "resty.validation"
return {
nick = v.string.trim:minlen(2),
email = v.string.trim.email,
password = v.string.trim:minlen(8)
}And now you have register function somewhere in your application:
local validate = require "validators"
local function register(nick, email, password)
local vn, nick = validate.nick(nick)
local ve, email = validate.email(email)
local vp, password = validate.password(password)
if vn and ve and vp then
-- input is valid, do something with nick, email, and password
else
-- input is invalid, nick, email, and password contain the error reasons
end
endThis quickly gets a little bit dirty, and that's why we have Group validators.
This function is where the group validation kicks in. Say that you have a registration form that asks you nick, email (same twice), and password (same twice).
We will reuse the single validators, defined in validators module:
local v = require "resty.validation"
return {
nick = v.string.trim:minlen(2),
email = v.string.trim.email,
password = v.string.trim:minlen(8)
}Now, lets create the reusable group validator in forms module:
local v = require "resty.validation"
local validate = require "validators"
-- First we create single validators for each form field
local register = v.new{
nick = validate.nick,
email = validate.email,
email2 = validate.email,
password = validate.password,
password2 = validate.password
}
-- Next we create group validators for email and password:
register:compare "email == email2"
register:compare "password == password2"
-- And finally we return from this forms module
return {
register = register
}
Now, somewhere in your application you have this register function:
local forms = require "forms"
local function register(data)
local valid, fields, errors = forms.register(data)
if valid then
-- input is valid, do something with fields
else
-- input is invalid, do something with fields and errors
end
end
-- And you might call it like:
register{
nick = "test",
email = "test@test.org",
email2 = "test@test.org",
password = "qwerty123",
password2 = "qwerty123"
}
The great thing about group validators is that you can JSON encode the fields and errors
table and return it to client. This might come handy when building a single page application
and you need to report server side errors on client. In the above example, the fields
variable will look like this (valid would be true:, and errors would be nil):
{
nick = {
unvalidated = false,
value = "test",
input = "test",
name = "nick",
valid = true,
invalid = false,
validated = true
},
email = {
unvalidated = false,
value = "test@test.org",
input = "test@test.org",
name = "email",
valid = true,
invalid = false,
validated = true
},
email2 = {
unvalidated = false,
value = "test@test.org",
input = "test@test.org",
name = "email2",
valid = true,
invalid = false,
validated = true
},
password = {
unvalidated = false,
value = "qwerty123",
input = "qwerty123",
name = "password",
valid = true,
invalid = false,
validated = true
},
password2 = {
unvalidated = false,
value = "qwerty123",
input = "qwerty123",
name = "password2",
valid = true,
invalid = false,
validated = true
}
}This is great for further processing and sending the fields as JSON encoded back to the client-side Javascript application, but usually this is too heavy construct to be send to the backend layer. To get a simple key value table, we can call this fields table:
local data = fields()The data variable will now contain:
{
nick = "test",
email = "test@test.org",
email2 = "test@test.org",
password = "qwerty123",
password2 = "qwerty123"
}Now this is something you can send for example in Redis or whatever database (abstraction) layer
you have. But, well, this doesn't stop here, if say your database layer is only interested in
nick, email and password (e.g. strip those duplicates), you can even call the data table:
local realdata = data("nick", "email", "password")The realdata will now contain:
{
nick = "test",
email = "test@test.org",
password = "qwerty123"
}For field you can call accept that does this:
self.error = nil
self.value = value
self.valid = true
self.invalid = false
self.validated = true
self.unvalidated = falseFor field you can call reject that does this:
self.error = error
self.valid = false
self.invalid = true
self.validated = true
self.unvalidated = falseCalling state on field is great when embedding validation results inside say HTML template, such as lua-resty-template. Here is an example using lua-resty-template:
<form method="post">
<input class="{{ form.email:state('invalid', 'valid') }}"
name="email"
type="text"
placeholder="Email"
value="{{ form.email.input }}">
<button type="submit">Join</button>
</form>So depending on email field's state this will add a class to input element (e.g. making input's border red or green for example). We don't care about unvalidated (e.g. when the user first loaded the page and form) state here.
The changes of every release of this module is recorded in Changes.md file.
- lua-resty-route — Routing library
- lua-resty-reqargs — Request arguments parser
- lua-resty-session — Session library
- lua-resty-template — Templating Engine
lua-resty-validation uses two clause BSD license.
Copyright (c) 2014 - 2017, Aapo Talvensaari
All rights reserved.
Redistribution and use in source and binary forms, with or without modification,
are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright notice, this
list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright notice, this
list of conditions and the following disclaimer in the documentation and/or
other materials provided with the distribution.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR
ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES`