Password Validation on Azure B2C SignUp - azure-ad-b2c

We are using Custom SignUp/SignIn policy and have not changed any of the microsoft provided attributes and their rules.
For the password, validation is not working as per given in the policy
<ClaimType Id="newPassword">
<DisplayName>New Password</DisplayName>
<DataType>string</DataType>
<UserHelpText>Enter new password</UserHelpText>
<UserInputType>Password</UserInputType>
<Restriction>
<Pattern RegularExpression="^((?=.*[a-z])(?=.*[A-Z])(?=.*\d)|(?=.*[a-z])(?=.*[A-Z])(?=.*[^A-Za-z0-9])|(?=.*[a-z])(?=.*\d)(?=.*[^A-Za-z0-9])|(?=.*[A-Z])(?=.*\d)(?=.*[^A-Za-z0-9]))([A-Za-z\d##$%^&*\-_+=[\]{}|\\:',?/`~"();!]|\.(?!#)){8,16}$" HelpText="8-16 characters, containing 3 out of 4 of the following: Lowercase characters, uppercase characters, digits (0-9), and one or more of the following symbols: # # $ % ^ & * - _ + = [ ] { } | \ : ' , ? / ` ~ " ( ) ; ." />
</Restriction>
</ClaimType>
If I start to enter password in the textbox, it will display this Helptext as mentioned above but when I enter the password as "testT1234" and proceed, it is not enforcing the validation.
Please let me know if I have to add/update the custom policy to enforce what being said is implemented.
Thanks,

As per Regex and helptext, your given password "tesT1234" is matching fine.
I guess you understood differently and also kept thinking it should allow special character(s) to complete the password match.
As per regex & helptext: if your password satisfies 3 out of 4 conditions, B2C allows you to use that password. Your given password already met 3 conditions.
8-16 characters, containing 3 out of 4 of the following: Lowercase characters, uppercase characters, digits (0-9), and one or more of the following symbols:
You can happily tweak the regex and add your own match criteria.

Related

How to use StringField to validate phone number in Flask form ? Defining min/max length can't restrict user from entering text

I am coding a python flask app and I defined a Contact field using the string field type.
I would like to validate the field to accept numbers only mobile numbers. Please guide!
contact = StringField('Contact',validators=[DataRequired(),Length(min=10, max=10)])
You can use Regular Expressions validator Regexp() like this:
contact = StringField('Contact',validators=[DataRequired(),Length(min=10, max=10),Regexp(regex='^[+-]?[0-9]$')])
^ means start of string.
$ end of string.
[-+]?means an optional + or - ( ? means optional) and [ ] is for a set of characters.
[0-9]+ the + means one or more digits.
You can find more about wtforms' Regexp() class from documentation.

How can I check that my username is string

I created loggin panel and now i wanna check that username is only string. In other case i want to return "Bad username". So How can I check that textfield is only string ?
I am not sure what exactly you mean by if the username is a string?
If by string, you mean that your username consists of only characters i.e. A-Z (or a-z). You can check if each character in your username have the ascii value between 65 to 90 (for A-Z) or 97 to 122 (for a-z). If you want to allow any other characters such as underscore (ascii 242), add that also to the test.

How to match strings with "like" keyword?

I'm prompting the user to enter a SaleLotNumber (string) and I'm having trouble with the formula. I have multiple entries with "20" in the SaleLotNumber but when I enter that in, I don't get anything on the report. When I enter the full SaleLotNumber in the parameter, I get the specific value from the database but I would like to enter only two numbers into the parameter and get all entries with those numbers in that order. Here's what I have:
{viewDealers_Drivetime.SaleLot} like {?SaleLotNumber}
What can I do do fix this?
I'm going to assume that {?SaleLotNumber} is a single-value parameter. To match all strings with a "20" in them, you need to use wildcards. For example, you can match a string like "012056" or "98720" by doing:
{viewDealers_Drivetime.SaleLot} like '*' + {?SaleLotNumber} + '*'
where '*' is Crystal's wildcard and {?SaleLotNumber}="20"

Dust.js tags for keys containing spaces

I wish to know how to write dust tags for keys containing spaces in linkedIn's Dustjs, or if it is even possible to do so.
According to this Dust Tutorial the format of a dust tag should be {xxxxxx}, but I haven't found any information on what defines a valid x.
Example JSON:
{
"street address": "North pole 1"
}
Failed attempts:
template = '{street address}';
template = '{street\\ address}';
template = '{"street address"}';
template = '{[street address]};
template = '{["street address"]};
Of course I know that I can just call it streetAddress and be done with it. But what I need to know is if I need to add certain restrictions on user-defined key names.
Follow-up question
If it is not possible to have space, what characters are allowed?
Spaces are not allowed for keys in Dust. A Dust key1 must start with a letter from a - z (upper or lower case), an underscore, or a $, followed 0 or more characters in the set a - z (upper or lower case), 0 - 9, underscore, $, -.
It may be more clear as a regular expression:
/[a-zA-Z_$]{1}[0-9a-zA-Z_$\-]*/

what does pam_unix : bad username mean?

Can anybody please tell me what does this error mean.And when will this appear. I tried googling, but with no result. Please point me to the correct document to understand this error.
This error is triggered by the following code in the pam_unix module (source: Linux-PAM-0.99.5):
if (name == NULL || !isalnum(*name))
the name == NULL would be triggered by a programmatic error in the use of the PAM protocol where the username variable is not being set as part of the pam conversation.
The second reason, and probably the most interesting is that the first character of the username is required to be an alpha-num i.e the character must be one of A-Z, a-z or 0-9. Accented characters are not accepted.
A newer version of Linux-PAM (as seen from the fedorahosted source of pam_unix.c) says:
if (name == NULL || name[0] == '-' || name[0] == '+')
Which means that it only rejects the - and + characters - i.e. it is less strict than the older source.

Resources