I am using Vuetify and use its default way of adding rules to input fields.
I know there is this rule:
v => !!v
This checks if the the form input isn't empty. But how can I make it in such a way that it only accepts alphabetical letters, numbers or even apply a regex to it? I can't find anything in the docs. Can someone with any experience help me out?
So I assume that you've probably sorted this now but for anyone finding this from google etc.
To add a new rule, you need to add it to your vue component, either through an import or just adding it straight to your data object. You name it as you would any other data property and it's an array of the tests like the v => !!v one you mentioned. You then add the OR operator followed by the text to show on a failed validation.
So to add a regex that only allows letters you would have this:
data () {
return {
alphaRule: [
v => /[a-zA-Z]+$/.test(v) || 'Field must only contain letters'
]
}
}
then on your form field you would have <v-text-field :rules="alphaRule"></v-text-field>
That said, I would highly recommend adding all of your rules to a Rules.js file and binding the rules globally so that you can access them anywhere, have a centralised repository for them, and it helps keeps your code DRY too.
I have just made a big ol list of rules inspired by Laravel's Validation rules and will edit my answer to include them oncce I have finished testing them.
EDIT
Here are all the rules I'm currently using in production. Hopefully they'll help someone else! You'll need to import them into your component to use them, or you can globally include them through a vue mixin.
I'm wondering if it's possible to describe a format, that an interface property should have. For example:
interface User {
age?: number,
name: string,
birthdate: string // should have format 'YYYY-MM-DD'
}
I read about decorators but it seems to only apply to classes, not interfaces.
I'm building an API with node/express and want to have input validation. So I'm considering Celebrate which can take joi type Schema to validate input. But I would like to use TypeScript instead to define my Schema / view model... As you see I try to use an Interface to define how the input of a given end point should look like:
age: number, optional
name: string
birthdate: string in format "YYYY-MM-DD"
Any hints and help much appreciated :)
Any hints and help much appreciated :)
First and foremost : you will have to write code for the validation. It will not happen magically.
Two approaches:
Out of band validation
You use validate(obj) => {errors?}. You create a validate function that takes and object and tells you any errors if any. You can write such a function yourself quite easily.
In band validation
Instead of {birthdate:string} you have something like {birthdate:FieldState<string>} where FieldState maintains validations and errors for a particular field. This is approach taken by https://formstate.github.io/#/ but you can easily create something similar yourself.
A note on validators
I like validators as simple (value) => error? (value to optional error) as they can be framework agnostic and used / reused to death. This is the validator used by formstate as well. Of course this is just my opinion and you can experiment with what suits your needs 🌹
I'm working with a component bitrix:catalog (which is standard one) and faced an issue. I want to add some extra GET parameters to switch view mode. I think there is no need to rewrite whole component to make such switcher, so I added extra keys in result_modifier in a way similar to:
$this->__component->arResultCacheKeys = array_merge($this->__component->arResultCacheKeys, array('key1', "key2"));
Earlier in the same result_modifier I perform adding those extra keys in $arResult['key1'] etc. They seem to be correctly saved, but only for current inquiry such as ?view=list or view=card, that means only one variable value is saved and it does not react on changing of GET parameter. Is there simple and correct way to make that component to cache and to output data based on GET variable? The only idea which came to my mind is to rewrite component by adding extra parameter and checking of GET, but I think there must more simple and correct solution to make in via template. Human Readable Links are turned on. And I want to have auto-cash being turned on as well. If I turn it off it starts working as planned.
One of possible solutions is to rewrite it cache by SetTemplateCachedData but it still seems to me rough and incorrect way for such simple task.
Bitrix masters please help me to find correct solution, google can't help at the moment.
If you use standard bitrix:catalog component, you may be use standart bitrix:catalog.section. In that component.php used standart component cache.
That means you can describe additional parametr in you custom .parameters.php, and set it in bitrix:catalog.section params.
Standart component cache set cacheId based on arParams.
So you include component should look like this:
$APPLICATION->IncludeComponent(
"bitrix:catalog.section",
"",
array(
"IBLOCK_TYPE" => $arParams["IBLOCK_TYPE"],
"IBLOCK_ID" => $arParams["IBLOCK_ID"],
"ELEMENT_SORT_FIELD" => $arParams["ELEMENT_SORT_FIELD"],
"ELEMENT_SORT_ORDER" => $arParams["ELEMENT_SORT_ORDER"],
....
....
"NEW_ADDITIONAL_GET_PARAMS"=> $_GET['view']
),
$component
);
Of course better way somethink like
"NEW_ADDITIONAL_GET_PARAMS"=> (in_array($_GET['view'],array('list','card'))?$_GET['view']:'list')
But may be you need just set right catalog params: SEF_MODE SEF_FOLDER SEF_URL_TEMPLATES
Enums come back from the server as myEnum.SomeValue but what I'd like to show on screen is a formatted value such as "some value" instead of SomeValue.
That could be part of an attribute on the server-side model but it won't be passed in the metadata.
What's the best place then to do that kind of thing with breeze ?
We've discussed the idea of "extensible" metadata for Breeze but have not yet implemented it. Please vote for this here.
But in the meantime, there is nothing stopping you from "enhancing" the metadata returned by Breeze yourself. The best way to do this would be to add your own properties to either the "MetadataStore", "EntityType" or "DataProperty" classes.
The advantage of adding your custom metadata to existing metadata objects is that this data will be available whenever you work with any of the basic Breeze metadata.
Perhaps something like this: ( I haven't actually confirmed that this code is correct)
var custType = myEntityManager.metadataStore.getEntityType("Customer");
// assume that the 'status' property is actually an enumerated value where you want to
// add some custom metadata.
var statusProp = custType.getProperty("status");
// enumDescriptions is your custom property
statusProp.enumDescriptions = {
"PaidUp": "Paid Up",
"Delinq": "Delinquent",
"InArr": "In Arrears"
};
Now anywhere that you get given the "status" dataProperty, ( such as in a Validation), you will also have access to your "enumDescriptions"
Hope this makes sense.
which is the preferred approach in sanitizing inputs coming from the user?
thank you!
I think whitelisting is the desired approach, however I never met a real whitelist HTML form validation. For example here is a symfony 1.x form with validation from the documentation:
class ContactForm extends sfForm
{
protected static $subjects = array('Subject A', 'Subject B', 'Subject C');
public function configure()
{
$this->setWidgets(array(
'name' => new sfWidgetFormInput(),
'email' => new sfWidgetFormInput(),
'subject' => new sfWidgetFormSelect(array('choices' => self::$subjects)),
'message' => new sfWidgetFormTextarea(),
));
$this->widgetSchema->setNameFormat('contact[%s]');
$this->setValidators(array(
'name' => new sfValidatorString(array('required' => false)),
'email' => new sfValidatorEmail(),
'subject' => new sfValidatorChoice(array('choices' => array_keys(self::$subjects))),
'message' => new sfValidatorString(array('min_length' => 4)),
));
}
}
What you cannot see, that it accepts new inputs without validation settings and it does not check the presence of inputs which are not registered in the form. So this is a blacklist input validation. By whitelist you would define an input validator first, and only after that bind an input field to that validator. By a blacklist approach like this, it is easy to forget to add a validator to an input, and it works perfectly without that, so you would not notice the vulnerability, only when it is too late...
A hypothetical whitelist approach would look like something like this:
class ContactController {
/**
* #input("name", type = "string", singleLine = true, required = false)
* #input("email", type = "email")
* #input("subject", type = "string", alternatives = ['Subject A', 'Subject B', 'Subject C'])
* #input("message", type = "string", range = [4,])
*/
public function post(Inputs $inputs){
//automatically validates inputs
//throws error when an input is not on the list
//throws error when an input has invalid value
}
}
/**
* #controller(ContactController)
* #method(post)
*/
class ContactForm extends sfFormX {
public function configure(InputsMeta $inputs)
{
//automatically binds the form to the input list of the #controller.#method
//throws error when the #controller.#method.#input is not defined for a widget
$this->addWidgets(
new sfWidgetFormInput($inputs->name),
new sfWidgetFormInput($inputs->email),
new sfWidgetFormSelect($inputs->subject),
new sfWidgetFormTextarea($inputs->message)
);
$this->widgetSchema->setNameFormat('contact[%s]');
}
}
The best approach is to either use stored procedures or parameterized queries. White listing is an additional technique that is ok to prevent any injections before they reach the server, but should not be used as your primary defense. Black listing is usually a bad idea because it's usually impossible to filter out all malicious inputs.
BTW, this answer is considering you mean sanitizing as in preventing sql injection.
WL is a best practice against BL whenever it is practicable.
The reason is simple: you can't be reasonably safe enumerating what it is not permitted, an attacker could always find a way you did not think about. If you can, say what is allowed for sure, it is simpler and much much safer !
Let me explain your question with few more question and answer.
Blacklist VS Whitelist restriction
i. A Blacklist XSS and SQL Injection handling verifies a desired input against a list of negative input's. Basically one would compile a list of all the negative or bad conditions, and verifies that the input received is not one among the bad or negative conditions.
ii. A Whitelist XSS and SQL Injection handling verifies a desired input against a list of possible correct input's. To do this one would compile a list of all the good/positive input values/conditions, and verifies that the input received is one among the correct conditions.
Which one is better to have?
i. An attacker will use any possible means to gain access to your application. This includes trying all sort of negative or bad conditions, various encoding methods, and appending malicious input data to valid data. Do you think you can think of every possible bad permutation that could occur?
ii. A Whitelist is the best way to validate input. You will know exacty what is desired and that there is not any bad types accepted. Typically the best way to create a whitelist is with the use of regular expression's. Using regular expressions is a great way to abstract the whitelisting, instead of manually listing every possible correct value.
Build a good regular expression. Just because you are using a regular expression does not mean bad input will not be accepted. Make sure you test your regular expression and that invalid input cannot be accepted by your regular expression.
Personally, I gauge the number of allowed or disallowed characters and go from there. If there are more allowed chars than disallowed, then blacklist. Else whitelist. I don't believe that there is any 'standard' that says you should do it one way or the other.
BTW, this answer is assuming you want to limit inputs into form fields such as phone numbers or names :) #posterBelow
As a general rule it's best to use whitelist validation since it's easier to accept only characters you know should go there, for example if you have a field where the user inputs his/her phone number you could just do a regex and check that the values received are only numbers, drop everything else and just store the numbers. Note that you should proceed to validate the resulting numbers as well. Blacklist validation is weaker because a skilled attacker could evade your validation functions or send values that your function did not expect, from OWASP "Sanitize with Blacklist":
Eliminate or translate characters (such as to HTML entities or to remove quotes) in an effort to make the input "safe". Like blacklists, this approach requires maintenance and is usually incomplete. As most fields have a particular grammar, it is simpler, faster, and more secure to simply validate a single correct positive test than to try to include complex and slow sanitization routines for all current and future attacks.
Realize that this validation is just a first front defense against attacks. For XSS you should always "Escape" your output so you can print any character's needed but they are escaped meaning that they are changed to their HTML entity and thus the browser knows it's data and not something that the parser should interpret thus effectively shutting down all XSS attacks. For SQL injections escape all data before storing it, try to never use dynamic queries as they are the easiest type of query to exploit. Try to use parameterized store procedures. Also remember to use connections relevant to what the connection has to do. If the connection only needs to read data, create a db account with only "Read" privileges this depends mostly on the roles of the users. For more information please check the links from where this information was extracted from:
Data Validation OWASP
Guide to SQL Injection OWASP
The answer generally is, it depends.
For inputs with clearly defined parameters (say the equivalent of a dropdown menu), I would whitelist the options and ignore anything that wasn't one of those.
For free-text inputs, it's significantly more difficult. I subscribe to the school of thought that you should just filter it as best you can so it's as safe as possible (escape HTML, etc). Some other suggestions would be to specifically disallow any invalid input - however, while this might protect against attacks, it might also affect usability for genuine users.
I think it's just a case of finding the blend that works for you. I can't think of any one solution that would work for all possibilities. Mostly it depends on your userbase.