I am using Aurelia-Validation in my project and trying to validate email address. When I add an email example#g, it passes the validation. Shouldn't email validation have .com, .net, etc extension at the end to pass the validation? See the plunker link as an example.
Here is the screenshot to show what I mean:
This is a bit nit-picky, but like emix already pointed out in comments, the validation regex used by aurelia-validation is currently the widely accepted standard as specified by WHATWG. This is the same regex as documented on MDN and w3.org.
Mozilla seems to follow this specification for validating input type="email" at least. I couldn't find any official sources on chrome or edge though.
The JavaScript version of that regex is:
/^[a-zA-Z0-9.!#$%&'*+\/=?^_`{|}~-]+#[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$/
In simple terms this translates to:
(required) before the # symbol, any number of alphanumeric characters and (certain) symbols
(required) after the # symbol, between 1 and 63 alphanumeric characters or hyphens (and cannot start or end with a hyphen)
(optional) same as 2 (but starting with a period), repeated for any number of times
If you want to restrict this validation to emails which are routable in the internet, simply change the asterisk * at the end of the regex to a plus +. That keeps the regex identical except there must now be at least one segment starting with a period.
/^[a-zA-Z0-9.!#$%&'*+\/=?^_`{|}~-]+#[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)+$/
Made change to my validation rule with below code:
Original code:
ValidationRules.ensure('setEmail')
.displayName('Email')
.required()
.email()
.on(this);
Modified code with matches pattern:
ValidationRules.ensure('setEmail')
.displayName('Email')
.required()
.email()
.matches(/^[a-zA-Z0-9._-]+#[a-zA-Z0-9.-]+\.[a-zA-Z]{2,4}$/)
.on(this);
See the screenshot:
Invalid:
Valid:
In the latest versions I think we can use Validators.pattern(REGEX_VALID_EMAIL) instead of Validators.email in the formControl validator.
and REGEX_VALID_EMAIL can be the following.
const REGEX_VALID_EMAIL = /^[a-zA-Z0-9.!#$%&'*+\/=?^_`{|}~-]+#[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)+$/
;
Related
So I have a set of strings, with some "custom markdown" that I have created. My intention is to render these strings as HTML in the frontend. Let's say, I have this string:
This is a string <color>that I need</color> to\nrender <caution>safely in the browser</caution>. This is some trailing text
I would be expecting to get something like:
This is a string <span class="primaryColor">that I need</span> to<br>render <div class="caution">safely in the browser</div>. This is some trailing text
And the way I do it right now is with some basic Regex:
toHtml = text
.replace(/<color>(.*)<\/color>/gim, "<span class='primaryColor'>$1</span>")
.replace(/\\n/g, "<br>")
.replace(/<caution>(.*)<\/caution>/gims, "<div class='caution'>$1</div>")
This works fine and returns the correct string. And then for printing, in the template I just:
<div id="container" v-html="result"></div>
My problem is that at some point I expect users to be able to enter this strings themselves, and that would be displayed to other users too. So for sure, I am gonna be vulnerable to XSS attacks.
Is there any alternative I can use to avoid this? I have been looking at https://github.com/Vannsl/vue-3-sanitize which looks like a good way of just allowing the div, span and br tags that I am using, and set the allowed attributes to be only class for all the tags. Would this be safe enough? Is there something else I should do?
In that case, I believe it will not be necessary to sanitize it in the backend too, right? Meaning, there will be no way for the web browser to execut malicious code, even if the string in the server contains <script>malicious code</script>, right?
My problem is that at some point I expect users to be able to enter this strings themselves
So, Do we have a form input for the users to enter the string which you mentioned in the post ? If Yes, My suggestion is that you can sanitize the user input at first place before passing to the backend. So that in backend itself no malicious code should be stored.
Hence, By using string.replace() method. You can first replace the malicious tags for ex. <script>, <a, etc. from the input string and then store that in a database.
Steps you can follow :
Create a blacklist variable which will contain the regex of non-allowed characters/strings.
By using string.replace(), replace all the occurrence of the characters available in the string as per the blacklist regex with the empty string.
Store the sanitized string in database.
So that, You will not get worried about the string coming from backend and you can bind that via v-html without any harm.
How can we validate a custom field while checkin in to Oracle WebCenter Content?It may be an email validation or custom validation say the file will allow user to input only 10 chars of which first four are alpha and the next sixth char are numeric.
Regards,
Ananda Roy
Try adding a rule to the profile (or using global rule). Then, in the rule side effect, set this: <$xCustomField:maxLength=10$>
You can get fancier validation by doing more customization such as this.
In application I'm testing the authenticity token is changed after user logs in - so I have to extract the token twice (once while login in, second after login). I use the Regular Expression Extractor.
At first time (during login) it works fine.
At second time (after login) it does not extract the new token - subsequent POST is sending given Reference Name (from Regular Expression Extractor) instead of extracted token.
I use different reference names in both extractors. Both pages have the same source and the tokens are defined in the same way:
<meta content="authenticity_token" name="csrf-param" />
<meta content="g/bsiegqqexUreoJdRbogKSpw6ZJ7O86fEUPESolrpc=" name="csrf token" />
So I use the same regular expression in both cases:
name="authenticity_token".*value="(.+)"
But, as I said, it works only for the first token.
Any help appreciated and thanks in advance
Simply don't use regular expressions to parse HTML. Any slight markup change in response, line break, whitespace, attributes order change, etc. and you get nothing.
You have two pretty PostProcessors designed for working with HTML response types:
CSS/JQuery Extractor
Relevant configuration will look like:
CSS/JQuery Expression: meta[name=csrf token]
Attribute Name: content
XPath Extractor
XPath Query will look something like://meta[#name='csrf token']/#content
If your response is not XHTML-compliant you may need to tick Use Tidy (tolerant parser) box
How do I make a text field accept only numeric values? If I press a letter or a symbol, the text field should not be filled, it should only allow numbers.
Is there a rails way to do this?
Use number_field_tag, this will generate a HTML5 number field
http://apidock.com/rails/ActionView/Helpers/FormTagHelper/number_field_tag
On the server side validate numericality:
class SomeModel
validates :some_column, :numericality => {:only_integer => true}
end
and on the client side, add an input mask via javascript https://github.com/ruoso/jquery-regex-mask-plugin
$('#some_input').regexMask(/^\d+$/);
#clyfe's answer is good, but that plugin doesn't work with HTML5 type=number elements. Here's some quick jQuery code that only allows integers:
$("input[type=number]").keypress(function(event) {
if (!event.charCode) return true;
ch = String.fromCharCode(event.charCode);
return (/[\d]/.test(ch));
});
to allow decimals or commas, make the regex look more like those in the plugin, e.g. https://github.com/ruoso/jquery-regex-mask-plugin/blob/master/regex-mask-plugin.js#L8 :
/^((\d{1,3}(\,\d{3})*(((\,\d{0,2}))|((\.\d*)?)))|(\d+(\.\d*)?))$/
(Note that different locales have different conventions for decimals and commas, so it's probably safer to just allow digits :-)
Note also that this is a workaround for the Chrome bugs mentioned here:
https://code.google.com/p/chromium/issues/detail?id=304455
https://github.com/angular/angular.js/issues/2144
I thought using colons in URIs was "illegal". Then I saw that vimeo.com is using URIs like http://www.vimeo.com/tag:sample.
What do you feel about the usage of colons in URIs?
How do I make my Apache server work with the "colon" syntax because now it's throwing the "Access forbidden!" error when there is a colon in the first segment of the URI?
Colons are allowed in the URI path. But you need to be careful when writing relative URI paths with a colon since it is not allowed when used like this:
<a href="tag:sample">
In this case tag would be interpreted as the URI’s scheme. Instead you need to write it like this:
<a href="./tag:sample">
Are colons allowed in URLs?
Yes, unless it's in the first path segment of a relative-path reference
So for example you can have a URL like this:
https://en.wikipedia.org/wiki/Template:Welcome
And you can use it normally as an absolute URL or some relative variants:
Welcome Template
Welcome Template
Welcome Template
But this would be invalid:
Welcome Template
because the "Template" here would be mistaken for the protocol scheme.
You would have to use:
Welcome Template
to use a relative link from a page on the same level in the hierarchy.
The spec
See the RFC 3986, Section 3.3:
https://www.rfc-editor.org/rfc/rfc3986#section-3.3
The path component contains data, usually organized in hierarchical
form, that, along with data in the non-hierarchical query component
(Section 3.4), serves to identify a resource within the scope of the
URI's scheme and naming authority (if any). The path is terminated
by the first question mark ("?") or number sign ("#") character, or
by the end of the URI.
If a URI contains an authority component, then the path component
must either be empty or begin with a slash ("/") character. If a URI
does not contain an authority component, then the path cannot begin
with two slash characters ("//"). In addition, a URI reference
(Section 4.1) may be a relative-path reference, in which case the
first path segment cannot contain a colon (":") character. The ABNF
requires five separate rules to disambiguate these cases, only one of
which will match the path substring within a given URI reference. We
use the generic term "path component" to describe the URI substring
matched by the parser to one of these rules. [emphasis added]
Example URL that uses a colon:
https://en.wikipedia.org/wiki/Template:Welcome
Also note the difference between Apache on Linux and Windows. Apache on Windows somehow doesn't allow colons to be used in the first part of the URL. Linux has no problem with this, however.