Wanted to know if the following characters are included in first name, last name and address fields in Plaid APIs:
A-Z
a-z
Space
Dot
Accent Characters
Hyphen
Apostrophe-D, L, and O like O'Brien
Can someone please help?
I tried the sandbox APIs and it was working fine. Have I done everything correct and is the production behaviour same?
Plaid returns all name and address strings as they are returned by the financial institution. The Plaid API does not clean up these fields to remove any special characters. Given the large number and diversity of financial institutions supported by the Plaid API, all sorts of special characters could potentially be returned. Consequently, your app should support any and all valid characters in the string field, to the degree that it makes sense for your use case.
Related
Just finishing up my signup/login/logout etc... type functionality of my site and I was curious. Should a user be forced to have a password that meets a certain strength or character set?
Example one, forcing them to use a alphanumeric password of length > 8
Example two, only allowing them to use alphanumeric characters and some special characters (ie: !##$%).
The first example is obviously a good thing to enforce on a sensitive site such as Banking but I can't think of a good reason to limit a user's password characters. As long as the string is cleaned for sql injection, it shouldn't matter what they use character wise right?
EDIT
And of course the password is being HASHED
Please, don't tell me what characters I can't use in my passwords.
You should support the full range of Unicode code points in passwords, with the possible exception of ASCII control characters (\0 – \0x20).
It is your responsibility to make sure that any normal character will work in a password, including spaces, quotes, and backslashes.
Passwords cannot be vulnerable to SQL injection, since the database must never see the actual password. You should hash and salt your passwords before they get anywhere near the database. (use bcrypt)
Minimum complexity requirements are a double-edged sword. If you require a password that is too complicated for your users to remember, they will end up writing it down somewhere, and probably somewhere close at hand.
At the very least, you should require 6 characters and at least two of A-Z, a-z, 0-9, or any other character.
SQL injection should not really matter: you should be hashing it before it ever reaches the DB. There really is no reason to limit the character set.
Lately I have been doing a security pass on a PHP application and I've already found and fixed one XSS vulnerability (both in validating input and encoding the output).
How can I query the database to make sure there isn't any malicious data still residing in it? The fields in question should be text with allowable symbols (-, #, spaces) but shouldn't have any special html characters (<, ", ', >, etc).
I assume I should use regular expressions in the query; does anyone have prebuilt regexes especially for this purpose?
If you only care about non-alphanumerics and it's SQL Server you can use:
SELECT *
FROM MyTable
WHERE MyField LIKE '%[^a-z0-9]%'
This will show you any row where MyField has anything except a-z and 0-9.
EDIT:
Updated pattern would be: LIKE '%[^a-z0-9!-# ]%' ESCAPE '!'
I had to add the ESCAPE char since you want to allow dashes -.
For the same reason that you shouldn't be validating input against a black-list (i.e. list of illegal characters), I'd try to avoid doing the same in your search. I'm commenting without knowing the intent of the fields holding the data (i.e. name, address, "about me", etc.), but my suggestion would be to construct your query to identify what you do want in your database then identify the exceptions.
Reason being there are just simply so many different character patterns used in XSS. Take a look at the XSS Cheat Sheet and you'll start to get an idea. Particularly when you get into character encoding, just looking for things like angle brackets and quotes is not going to get you too far.
I have to create sql function that converts special Characters, International Characters(French, Chinese...) to english.
Is there any special function in sql, can i get??
Thanks for your help.
If you are after English names for the characters, that is an achievable goal, as they all have published names as part of the Unicode standard.
See for example:
http://www.unicode.org/ucd/
http://www.unicode.org/Public/UNIDATA/
Your task then is to simply turn the list of unicode characters into a table with 100,000 or so rows. Unfortunately the names you get will be things like ARABIC LIGATURE LAM WITH MEEM MEDIAL FORM.
On the other hand, if you want to actually translate the meaning, you need to be looking at machine translation software. Both Microsoft and Google have well-known cloud translation offerings and there are several other well-thought of products too.
I think the short answer is you can't unless you narrow your requirements a lot. It seems you want to take a text sample, A, and convert it into romanized text B.
There are a few problems to tackle:
Languages are typically not romanized on a single character basis. The correct pronunciation of a character is often dependent on the characters and words around it, and can even have special rules for just one word (learning English can be tough because it is filled with these, having borrowed words from many languages without normalizing the spelling).
Even if you code rules for every language you want to support you still have homographs, words that are spelled using exactly the same characters, but that have different pronunciations (and thus romanization) depending on what was meant - for example "sow" meaning a pig, or "sow" (where the w is silent) meaning to plant seeds.
And then you get into the problem of what language you are romanizing: Characters and even words are not unique to one language, but the actual meaning and romanization can vary. The fact that many languages include loan words from those language they share characters with complicates any attempt to automatically determine which language you are trying to romanize.
Given all these difficulties, what it is you actually want to achieve (what problem are you solving)?
You mention French among the languages you want to "convert" into English - yet French (with its accented characters) is already written in the roman alphabet. Even everyday words used in English occasionally make use of accented characters, though these are rare enough that the meaning and pronunciation is understood even if they are omitted (ex. résumé).
Is your problem really that you can't store unicode/extended ASCII? There are numerous ways to correct or work around that.
I am able to store values in couchdb-lucene with whatever key I like, but it seems that if the key includes any chars outside of [0-9a-zA-Z_] any search fails.
Does anyone know what chars are valid and/or how to properly escape special chars in searches such that special chars can be used?
This shows how to escape special characters and also gives a list of such characters.
All UTF-8 characters should work. I've just verified that I can search for items with é, for example.
A little more information on how you're querying would help, though given the age of this ticket perhaps you've moved on.
We're working on revising the url structure for some of our movie content, but we aren't quite sure on the best way to handle odd characters. For example,
'303/302'
'8 1/2 Women'
'Dude, Where's My Car?'
'9-1/2 Weeks'
So far, we're thinking:
/movies/303-302
/movies/8-1-2-women
/movies/dude-wheres-my-car
/movies/9-1-2-weeks
Is this the best solution? Is there anything we're forgetting?
Use this format: /movies/123456/8-1-2-women
Set up your web server so that movies are identified by the numeric id (123456), and the rest of the path is ignored (only serves for SEO).
(Stackoverflow uses this approach)
We always use dashes.
I don't have a source off hand, but I have heard that the dash character is good for SEO purposes, better so than something like camel caps (i.e. dudeWheresMyCar) but not sure how it compares to underscores, ampersands, or percentage signs. Apparently with dashes (and maybe other separation characters too) search bots can "read" the links and add it as just one more factor on determining content relevance.
From Seomoz: "When creating URLs with multiple words in the format of a phrase, hyphens are best to separate the terms (e.g. /brands/dolce-and-gabbana/), followed (in order) by, underscores (_), pluses (+) and nothing."
This has been confirmed by Matt Cutts, Google too.