I want to be able to create the admin user during the site installation with only 6 normal characters instead :
Passwords must be at least 8 characters long.
Passwords must have at least 1 digit(s).
Passwords must have at least 1 upper case letter(s).
Passwords must have at least 1 non-alphanumeric character(s).
Any ideas ?
You should be able to change the Password policy at:
Settings > Site administration > Security > Site policies
Check this documentation for details and instructions. Hope it helps.
Related
I am using Exchange Server 2013 and have many transport rules set up to filter out emails from most countries outside of the US.
We recently received an email from a military email, ending in .mil
The email was blocked by my transport rules but does not match any of the extensions I have listed. Except for possibly one! I have an extension to block '.il$'. So this should block ALL emails that end with ".il". However, if the transport rules use true regular expression rules, the "." would be a wildchar and match any and every character including a "." itself. Is this the cause of my issue? I do not have a .mil email account to test with or I could check myself. I have added a character escape to my transport rule, making it '\.il$' hoping that it will fix this.
I read everything I can find about the regex rules for Exchange's Transport Rules, and I cannot find anything that mentions you must escape the dot. Maybe this is just a rare issue and they didn't foresee it occurring?
One of the documents I have read: https://technet.microsoft.com/en-us/library/aa997187(v=exchg.141).aspx
Long story short: YES, the dot(.) must be escaped with a \. Otherwise it is a single wildchar that matches any character [A-Z a-z 0-9 . , /] etc. just like in regular expression. I assume that Microsoft is using every rule from regular expression for the transport rules but do not quote me on that.
This cannot be found in any documentation that I have researched, it also seems that every example that I have looked at on the web has been doing it wrong as well. Examples that I see are always ".com$" will block all emails from a sender ending in .com. This is true because the dot can also be a dot. But this will also block any emails that end in "ecom" for example, which may be an issue if they ever decide to release such extension.
Sorry for answering my own question, but I want this to be here for future reference since it can't seem to be found anywhere else.
I have a domain name which DNS is edited via Google Cloud DNS. And I have a Google Apps for Work Account with that domain name.
I wanted to set up DKIM-authentication but when I try to save the corresponding TXT-Record I get the error that the Tag is invalid.
I did the same before and it worked perfectly. I checked the old setup and I saw that the old DKIM-record was about half the length. The new one seems to be too long for a TXT-record in the Google Cloud Platform.
Does anyone have a solution?
yeah, you have to split the record as described in this article:
https://support.google.com/a/answer/173535
If your domain provider limits the size of the TXT record value to 255 characters, you can't enter the DKIM key as a single entry in the DNS records. In this case, split the key into multiple quoted text strings and enter them together in the TXT record value field. For example, split the DKIM key into two parts as follows:
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAraC3pqvqTkAfXhUn7Kn3JUNMwDkZ65ftwXH58anno/bElnTDAd/idk8kWpslrQIMsvVKAe+mvmBEnpXzJL+0LgTNVTQctUujyilWvcONRd/z37I34y6WUIbFn4ytkzkdoVmeTt32f5LxegfYP4P/w7QGN1mOcnE2Qd5SKIZv3Ia1p9d6uCaVGI8brE/7zM5c/" "zMthVPE2WZKA28+QomQDH7ludLGhXGxpc7kZZCoB5lQiP0o07Ful33fcED73BS9Bt1SNhnrs5v7oq1pIab0LEtHsFHAZmGJDjybPA7OWWaV3L814r/JfU2NK1eNu9xYJwA8YW7WosL45CSkyp4QeQIDAQAB"
The two quoted strings have to stay on the same line - in the same box in the Cloud DNS interface rather than in two separate boxes.
I just ran into the same issue.
The google DKIM keys text strings are longer than most other DKIM keys (probably higher bit count) and won't fit into the 255 length limitation per TXT field.
The way to get around this is to do two TXT entries and end the first with a \ or use ( in the first and ) in the second.
The google cloud DNS parser seems to not allow a trialing \ and ) or preceding (.
There may be some way to escape it on the Google Cloud DNS tool - but it is not obvious.
Ok I have a solution.
Make sure to only do 1 TXT record entry and not add multiple TXT records - this is the key step.
If you click "Add Item" when setting up the TXT record this actually creates another TXT record and both records may resolve in any order and the DKIM won't validate.
The trick is to make sure to place the broken up strings into the first text input only and break them into small enough pieces that they all get parsed in the correct sequential order.
Select bit length "1024" while generating DKIM records at Gsuite Admin console. This worked for me.
How to easily add DKIM as TXT in GCP Cloud DNS:
copy/paste the entire DKIM string into the TXT field
ignore the ...this domain has whitespace but is not a quoted string... related GCP warning you may see
before you save it, insert a single space in the middle of the DKIM p= value string.
That's it.
This approach was tested with Mailgun and a domain name configured in Google Cloud DNS.
Additional notes:
GCP will automatically add double quotes around each space separated string after you save
you need to separate the p= string in such a way so that no resulting double quoted string created after you save is longer than 255 characters
example (before):
k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlTtO1qRFaK955gz16Y8c1EMCqtaT4exCrwfor2yT438ZVjrUcqo2tPUNR4eqkD+xcKRQnWSw931uVUY6YJWtOrgrXTIrHnTkf5Xtg+jaXr0OhjdeVDIG/Le7oOVWncMf+9J4ZSRybOpb+XZPp/JLjis6pmCLrt5j82yBC9DCbsEPSOVVOC1mr5lq8irQs+qAv6M/DnjNcUrdiRBJyNrs2lfuvfs8BFceZAk1AwcVBcYCmZl5OkxZBn8liTC34FPJLLHm6jMp9+c0OaEtxo8zr3QX0ZYEWC3XqZ/p9fo4Pcg+fpyjee79wBVqUzhVAWdzE5+qAIn4e1Dmslyb6IX4mwIDAQAB
example (after):
k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlTtO1qRFaK955gz16Y8c1EMCqtaT4exCrwfor2yT438ZVjrUcqo2tPUNR4eqkD+xcKRQnWSw931uVUY6YJWtOrgrXTIrHnTkf5Xtg+jaXr0OhjdeVDIG/Le7oOVWncMf+9J4ZSRybOpb+XZPp/JLjis6pmCLrt5j82y BC9DCbsEPSOVVOC1mr5lq8irQs+qAv6M/DnjNcUrdiRBJyNrs2lfuvfs8BFceZAk1AwcVBcYCmZl5OkxZBn8liTC34FPJLLHm6jMp9+c0OaEtxo8zr3QX0ZYEWC3XqZ/p9fo4Pcg+fpyjee79wBVqUzhVAWdzE5+qAIn4e1Dmslyb6IX4mwIDAQAB
Scroll to the right and you'll see the newly added space - this produces three space separated strings, each less than 255 characters:
k=rsa;
p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlTtO1qRFaK955gz16Y8c1EMCqtaT4exCrwfor2yT438ZVjrUcqo2tPUNR4eqkD+xcKRQnWSw931uVUY6YJWtOrgrXTIrHnTkf5Xtg+jaXr0OhjdeVDIG/Le7oOVWncMf+9J4ZSRybOpb+XZPp/JLjis6pmCLrt5j82y
BC9DCbsEPSOVVOC1mr5lq8irQs+qAv6M/DnjNcUrdiRBJyNrs2lfuvfs8BFceZAk1AwcVBcYCmZl5OkxZBn8liTC34FPJLLHm6jMp9+c0OaEtxo8zr3QX0ZYEWC3XqZ/p9fo4Pcg+fpyjee79wBVqUzhVAWdzE5+qAIn4e1Dmslyb6IX4mwIDAQAB
example (after, viewed via DIG):
;; ANSWER SECTION:
dkim.example.com. 300 IN TXT "k=rsa;" "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlTtO1qRFaK955gz16Y8c1EMCqtaT4exCrwfor2yT438ZVjrUcqo2tPUNR4eqkD+xcKRQnWSw931uVUY6YJWtOrgrXTIrHnTkf5Xtg+jaXr0OhjdeVDIG/Le7oOVWncMf+9J4ZSRybOpb+XZPp/JLjis6pmCLrt5j82y" "BC9DCbsEPSOVVOC1mr5lq8irQs+qAv6M/DnjNcUrdiRBJyNrs2lfuvfs8BFceZAk1AwcVBcYCmZl5OkxZBn8liTC34FPJLLHm6jMp9+c0OaEtxo8zr3QX0ZYEWC3XqZ/p9fo4Pcg+fpyjee79wBVqUzhVAWdzE5+qAIn4e1Dmslyb6IX4mwIDAQAB"
Ref:
DKIM TXT record value invalid, cloud-dns-discuss group message
The solution that worked for me with Google Cloud DNS was to use the tool on this web page to "fix" the Mailgun provided DKIM string:
https://www.mailhardener.com/tools/dns-record-splitter
More detail: How to enter TXT values in Google Cloud DNS
https://www.mailhardener.com/blog/how-to-enter-txt-values-in-google-cloud-dns
Just add first txt k=rsa; p=abc in DNS record and ignore warnings. then add the rest. This works for me. Tested on mailgun+Gcloud
If a node contains newlines, jsTree prints them as whitespaces. For instance, this block of text:
suggestion: Passwords of at least 10 characters are strongly recommended, especially considering that construction rules requiring both numbers and letters cannot be enforced by default.
The following may need to be customized for your environment. Add:
min=10
to the following line in /etc/pam.d/common-password by hand:
password ... pam_unix.so ... min=10 ...
IMPORTANT: the password length is only checked at the time of account creation or password update. Existing users' password length should be double-checked to ensure that password minimum length is enforced.
is displayed like this:
suggestion: Passwords of at least 10 characters are strongly recommended, especially considering that construction rules requiring both numbers and letters cannot be enforced by default. The following may need to be customized for your environment. Add: min=10 to the following line in /etc/pam.d/common-password by hand: password ... pam_unix.so ... min=10 ... IMPORTANT: the password length is only checked at the time of account creation or password update. Existing users' password length should be double-checked to ensure that password minimum length is enforced.
Is there a way to get jsTree to render newlines correctly?
I was able to figure it out. I got around it by substituting all newline characters ('\n') with <br> tags in the HTML. i.e., gsub(/\n/,"<br>").
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
What restrictions should I impose on usernames? why?
What restrictions should I not impose on usernames? why?
P.S. db is via best-practice PDO so no risk of sql injection
Thanks
OK, so let's assume you're doing all your string-encoding tasks right. You've not got any SQL injections, HTML injections, or places where you're not URL-encoding something you should. So we don't need to worry about characters like "<&%\ being magic in some contexts. And you're using UTF-8 for everything so all of Unicode is in play. What other reasons are there to limit usernames?
To start with, all control characters, for sanity. There is no reason to have characters U+0000 to U+001F or U+007F to U+009F in a username.
Next, deny or normalise unexpected whitespace. You may want to allow a space in a username, but you almost certainly don't want to allow leading spaces, trailing spaces, or more than one space in a row. They may render the same in HTML, but are probably a user error that will confuse.
If you intend to allow that username to be used to login through HTTP Basic Authentication, you must disallow the : character, because the Basic Auth scheme encodes a ‘username:password’ pair with no escaping if there's a colon in the username or password. So at least one of the username and password must have the colon excluded, and it's better that that's the username because restricting people's choice of passwords is a much worse thing than usernames.
For Basic Authentication you may also want to disable all non-ASCII characters, as they are handled differently by different browsers. IE encodes them using the system codepage; Firefox encodes them using ISO-8859-1; Opera encodes them using UTF-8. Users should at least be warned before choosing non-ASCII names if HTTP Auth is going to be available, as actually using them will be very unreliable.
Next consider other Unicode control sequences, things like the bidi overrides and other characters listed there are unsuitable for use in markup. Probably you are going to end up putting them in markup and you don't want someone with an RLO in their name to turn a load of the text in your page backwards.
Also, if you allow Unicode do normalisation on the strings you get. Otherwise someone may have a username with a composed o-umlaut character ö, and wonder why they can't log in on a Mac, which by default would use a separate o character followed by combining umlaut. It's usual to normalise to the composed form NFC on the web. You may also want to do compatibility decompositions by using the form NFKC; this would allow a user Chris to log in from a Japanese keyboard in fullwidth romaji mode typing Ｃｈｒｉｓ. These are general issues it is good to solve for all your webapp's input, but for identifiers like usernames it can be more critical to get right.
Finally, make sure the length is OK to fit in the database without a silent truncation changing the name, especially if you are storing as UTF-8 bytes which you don't want to get snipped halfway through a byte sequence. Username truncations can also be a security issue in general.
If you are using usernames as a unique means of identification, you have much more to worry about: the already-mentioned problem of lookalikes such as Сhris (with a Cyrillic Es С). There are too many of these for you to handle reasonably; either restrict to ASCII or have an additional means of identifying users. (Or don't care, like SO doesn't; when I can easily call myself Chris anyway I have no need to call myself С-hris.)
Depends on many things, for instance, if the users are going to have their own URL, you want to be careful that someone who creates the username "%41llan" doesn't clash with the user called "Allan", while allowing forward-slash may cause problems. Look out for those sorts of constraints.
I've never seen the point in adding restrictions to usernames. If your code is resistant to sql injection attacks then let them put in anything they want.
The only restriction I'd add is a max length one so that it can be stored in a DB table
Let them use any Unicode character in their username.
Adding restrictions on the allowed characters will probably just annoy people using a non-ascii language.
SQL injection protection is a must, but that should probably be in your code, not in username restrictions. Certain characters should definitely be escaped, like \, %, etc.
It will on what kind of site you're running, but I think some obscene word restrictions would make your site look more professional no matter what. If someone sees that people are allowed to go around with "EXPLETIVE" as they're username, your site will look childish. Its like allowing teenagers to run rampid in your book store IMHO. You probably don't need to get much more picky than that, although its completely up to you.
This is slightly off topic, but as another piece of username advice, a great feature of any website is allowing users to change they're username over time. You can just have a number as a primary key, and allowing them to do this can save a lot of whining and people creating new accounts because they wanted to change their username. :D
If it's possible, should I accept such emails from users and what problems to expect when I will be sending mails to such addresses?
Officially, per RFC 6532 - Yes.
For a quick explanation, check out wikipedia on the subject.
Update 2015: Use RFC 6532
The experimental 5335 has been Obsoleted by: 6532 and
this later has been set to "Category: Standards Track",
making it the standard.
The Section 3.2 (Syntax Extensions to RFC 5322) has updated most text fields to
include (proper) UTF-8.
The following rules extend the ABNF syntax defined in [RFC5322] and
[RFC5234] in order to allow UTF-8 content.
VCHAR =/ UTF8-non-ascii
ctext =/ UTF8-non-ascii
atext =/ UTF8-non-ascii
qtext =/ UTF8-non-ascii
text =/ UTF8-non-ascii
; note that this upgrades the body to UTF-8
dtext =/ UTF8-non-ascii
The preceding changes mean that the following constructs now
allow UTF-8:
1. Unstructured text, used in header fields like
"Subject:" or "Content-description:".
2. Any construct that uses atoms, including but not limited
to the local parts of addresses and Message-IDs. This
includes addresses in the "for" clauses of "Received:"
header fields.
3. Quoted strings.
4. Domains.
Note that header field names are not on this list; these are still
restricted to ASCII.
Please note the explicit inclusion of Domains.
And the explicit exclusion of header names.
Also Note about NFKC:
The UTF-8 NFKC normalization form SHOULD NOT be used because
it may lose information that is needed to correctly spell
some names in some unusual circumstances.
And Section 3 start:
Also note that messages in this format require the use of the
SMTPUTF8 extension [RFC6531] to be transferred via SMTP.
The problem is that some mail clients (server-tools and / or desktop tools) don't support it and throw an 'invalid email' exception when you try to send a mail to an address which contains umlauts for example.
If you want full support, you could do the trick with converting the email-address parts to "punycode". This allows users to type in their addresses the usual way but you save it the supported-level way.
Example: müller.com » xn--mller-kva.com
Both points to the same thing.
I would assume yes since a number of top level domains already allow non ascii
characters for domains and since the domain is part of an email address, it's
perfectly possible. An example for such a domain would be www.öko.de
short answer: yes
not only in the username but also in the domain name are allowed.
The answer is yes, but they need to be encoded specially.
Look at this. Read the part that refers to email-headers and RFC 2047.
Not yet. The IEEE plans to do this:
H-Online article: IEFT planning internationalised email addresses, here is the RfC: SMTP Extension for Internationalized Email Addresses
Quote from H-Online (as it went down):
The Internet Engineering Task Force (IETF) has published three crucial documents for the standardisation of email address headers
that include symbols outside the ASCII character set. This means that
soon you'll be able to use Chinese characters, French accents, and
German umlauts in email addresses as well as just in the body of the
message. So if your name is Zoë and you work for a company that makes
façades, you might be interested in a new email address. But
representatives of providers are already moaning. They say there would
need to be an "upgrade mania" if the Unicode standard UTF-8 is to
replace the American Standard Code for Information Interchange (ASCII)
currently used as the general email language.
RFC 5335 specifies the use of UTF-8 in practically all email headers.
Changes would have to be made to SMTP clients, SMTP servers, mail user
agents (MUAs), software for mailing lists, gateways to other media,
and everywhere else where email is processed or passed along. RFC 5336
expands the SMTP email transport protocol. At the level of the
protocol, the expansion is labelled UTF8SMTP.
A new header field will be added as a sort of "emergency parachute" to
ensure that UTF-8 emails have a soft landing if they are thrown out
before reaching the recipient by systems that have not been upgraded.
The "OldAddress" is a purely ASCII address. But OldAddress is not to
be used as a channel for a second transfer attempt, but rather to make
sure that feedback is sent home.
Finally, RFC5337 ensures that correct messages are sent pertaining to
the delivery status of non-ASCII emails. The correct address of an
unreachable addressee must be sent back, even if further transport has
been refused. The email Address Internationalization (EAI) working
group is also working on a number of "downgrade mechanisms" for
various header fields and the envelope. If possible, original header
information is to be "packaged" and preserved.
Germany's DeNIC, the registrar for the ".de" domain, is nonetheless
taking this in its stride. "There is really not much we can do",
explained DeNIC spokesperson Klaus Herzig. DeNIC is instead paying
more attention to the update that the IETF is working on for the
standard of international domains – RFC3490, or IDNA2003 as it's
sometimes known. "We are not that happy about it because there is no
backwards compatibility," Herzig explained. When the update comes,
DeNIC says it will be throwing its weight behind the symbol "ß" - also
known as estzett - which has been overlooked up to now. The German
registrar also says that it may wait a bit before switching in light
of the lack of backward compatibility. Once the new standard is
running stably and registrars and providers have adopted it, the ß
will be added.
In contrast, experts believe that Chinese registrars in China and
Taiwan will quickly implement the change for internationalised email.
Representatives of CNIC and TWNIC are authors of the standards.
Chinese users currently have to write emails in ASCII to the left of
the # and in Chinese characters to the right of it for Chinese
domains, which have already been internationalized.
(Monika Ermert)