My current app needs to store address information for a user. I'm currently debating whether to use the customary street address / city / state / zip textboxes and dropdowns or to go with Google's method of simply having everything on one line. Any thoughts on the pros/cons of storing address information in either of these manners?
You should split it up. It will make it far easier to do reporting down the road. What happens if you want to pull up all the residents of a state or zip code, or city? If you use all one field, you will be stuck and wish you had split it up.
Also, users will forget to put in all the information you need if you don't prompt them for it.
Judging by the user-input tag on your post, I assume you are referring to how the user enters the data, and now how you are storing the data in your back-end database.
Presumably your database will still need to store this information as separate fields, if you want to be able to sort and analyse the information (e.g. for reporting and statistics purposes).
In this case, I think it would depend on how confident you are that you could parse the addressing information properly into its individual fields.
One hybrid option would be to allow the user to enter the address as a single line, and then do a best-effort parsing of the information into the separate fields. This is similar to how Outlook manages addresses for contacts - you enter all of the information into a single memo field, and then it splits it up for you. You can then correct if it interpreted any of the fields wrong.
I would be very much against just having a single text field where users enter their address. You'd be surprised how many people will leave out their zip code or some other important info if you don't have a specific field for it. Also, as others have mentioned, it make reporting much easier to report on this information later if all the data is pre-parsed. As other users mentioned, programs like outlook will parse this information, but only because the source of the data is often the signatures of emails, which is something that is never in a consistent format.
I tend to split it up, allows searching to be done for a specific section of the address and you can limit the addresses you want to handle by knowing the formatting i.e. Only ship to east coast addresses.
1) You should split it.
2) May I recommend you read this before you attempt to do international address input?
I concur with Kibbee. I was even surprised to see people don't even read the field's labels, inverting first and last name, postal code and city, etc.
No, you can't determinate if a postal code is valid, in a Web application targeting international customers...
Some countries have alpha characters in postal code, various lengths, no state info, etc.
Definitely split the input. If you can help it--and depending upon your business requirements--it may be wise to perform address verification at the point of entry. This will allow you to know that your addresses are going into your database clean and allow you to do a number of other things such as fraud prevention. Having a verified address can help reduce shipping costs if you're shipping physical goods to your customers and can help reduce credit card merchant fees by ensuring the correct ZIP Code is submitted during AVS verification.
In the interest of full disclosure, I'm the founder of SmartyStreets. We offer CASS-certified address verification services. Users can upload a list for scrubbing (CSV/Excel/etc) to our website or use our address verification web service API called LiveAddress.
Related
Over the past few months random email addresses, some of which are on known spam lists, have been added at the rate of 2 or 3 a day to my website.
I know they aren't real humans - for a start the website is in a very narrow geographical area, and many of these emails are clearly from a different country, others are info# addresses that appear to have been harvested from a website, rather than something a human would use to sign up to a site.
What I can't work out is, what are reasons for somebody doing this? I can't see any benefit to an external party beyond being vaguely destructive. (I don't want to link to the site here, it's just a textbox where you enter email and press join).
These emails are never verified - my question isn't about how to prevent this, but what are some valid reasons why somebody might do this. I think it's important to understand why malicious users do what they do.
This is probably a list bombing attack, which is definitely not valid. The only valid use I can think of is for security research, and that's a corner case.
List bomb
I suspect this is part of a list bombing attack, which is when somebody uses a tool or service to maliciously sign up a victim for as much junk email as possible. I work in anti-spam and have seen victims' perspectives on this: it's nearly all opt-in verifications, meaning the damage is only one per service. It sounds like you're in the Confirmed Opt-In (COI) camp, so congratulations, it could be worse.
We don't have good solutions for list bombing. There are too many problems to entertain a global database of hashed emails that have recently opted into lists (so list maintainers could look up an address, conclude it's being bombed, and refuse to invite). A global database of hashed emails opting out of bulk mail (like the US Do Not Call list or the now-defunct Blue Frog's Do Not Intrude registry but without the controversial DDoS-the-spammers portion) could theoretically work in this capacity, though there'd still be a lot of hurdles to clear.
At the moment, the best thing you can do is to rate-limit (which this attacker is savvy enough to avoid) and use captchas. You can measure your success based on the click rate of the links in your COI emails; if it's still low, you still have a problem.
In your particular case, asking the user to identify a region via drop-down, with no default, may give you an easy way to reject subscriptions or trigger more complex captchas.
If you're interested in a more research-driven approach, you could try to fingerprint the subscription requests and see if you can identify the tool (if it's client-run, and I believe most are) or the service (if it's cloud-run, in which case you can hopefully just blacklist a few CIDR ranges instead). Pay attention to requesters' HTTP headers, especially the referer. Browser fingerprinting it its own arms race; take a gander at the EFF's Panopticlick or Brian Kreb's piece on AntiDetect.
Security research
The only valid case I can consider, whose validity is debatable, is that of security research (which is my field). When I'm given a possible phishing link, I'm going to anonymize it. This means I'll enter fake data rather than reveal my source. I'd never intentionally go after a subscription mechanism (at least with an email I don't control), but I suppose automation could accidentally stumble into such a thing.
You can avoid that by requiring POST requests to subscribe. No (well-designed) subscription mechanism should accept GET requests or action links without parameters (though there are plenty that do). No (well-designed) web crawler, for search or archiving or security, should generate POST requests, at least without several controls to ensure it's acceptable (such as already concluding that it's a bad actor's site). I'm going to be generous and not call out any security vendors that I know do this.
I'm trying to develop an easy way for users to enter addresses.
I've got a database of postal codes and cities already, so if a user enters his street address and postal code, I can (usually) retrieve the city, province, and country automatically. However, if this information is missing from my database, they'll be required to fill it in.
I'm trying to decide what this should look like. Should I just display the 2 fields (street and postal code) by default, and then after they've filled it out, use AJAX to validate the postal code, and if it's not found, make the rest of the fields appear? This has the drawback that they may be part way through the rest of the form before it appears.
I could take the opposite approach and hide the extra fields only if the postal code is found. But then they might fill out information they didn't need to by the time its validated. Or is there some middle ground?
Just trying to figure out the quickest and easiest/user-friendly way for people to enter addresses. Suggestions?
I've done this before. I had the user enter street and zip code, then they had to choose what city they were from in case there was more than one to choose from. I didn't hide any fields, but there wasn't anything to choose from until the postal code was validated via AJAX. It seemed to work quite well not hiding anything.
However, between the two options that you mentioned, I would go with the first one. That one is closest to what has worked for me.
i'd say try to implement something like predictive search which takes both, city an zip field, as search params.
for example you've typed your zip code, click (or tab) to the city field, you get a list of cities where this postal code applies.
but don't force the user to take one of the entries in the list.
with that you can auto-populate your database if the user's city isn't already in it.
that's something i'd like to have :)
Addresses are usually "value objects" meaning they are read only to an entity (such as a customer), which means you should probably let them pick out an existing address or create a new address.
That said, this also depends on your target audience. Are they good at entering addresses? For example, I always throw up a pop-up control for dates so there isn't a chance they would pick an invalid date.
You could look at how Navigation systems work. They always ask for a destination. Mine does an auto complete on the street first, then house number, then city / zip. Just look at the more popular units.
just disable the extra fields while they fill in their lookup information. You AJAX calls shouldn't be that slow. If they are then you have some serious problems to address other than this.
But you are on the right path.
I would start by having them enter just the Postal Code, and I'd probably submit the form and return two different forms depending on whether or not you have the available data in your database.
One word of warning: people can get extremely sensitive about vanity addresses. Your database probably says that 94027 is Redwood Shores, CA, but if you tell someone who thinks that he live in Atherton that he lives in Redwood City, he's going to get pissed. Sometimes, it is better not to do extra work when people are entering address information.
I'm writing a POS application for the iPhone/iPod combination, using the same exact hardware used in Apple Stores:: EasyPay.
Ok, my hurdle is this: how do I identify which credit card type is being used as text is entered in the uitextfield?
I assume I've to use textField:shouldChangeCharactersInRange:replacementString:? However, I've got ideas floating around, but I simple cannot put them together to form code :/
Any help is appreciated!
Maybe I didn't uderstand your problem, but I think you can have a BIN's list (Bank Identification Number). For example, most credit card numbers beginning with '4' are Visa. If they begin with '5', they are probably Mastercard. This is only an example, you should have a complete list to identify each possible card. Unfortunately, a complete and updated list is paid, but you can have a good list searching for free information on the Web, like here.
You can make a reasonable stab at guessing the card type from the first six digits of the card number, which is known as the Issuer Identification Number (IIN)
The trouble is, you'll struggle to get a complete list of IINs. Even the major acquirers struggle to keep an up to date list, as issuers frequently add or remove ranges.
Luckily, the card type shouldnt generally matter. You should be able to perform basic validation of the length, and luhn check digit, then submit the card to the processor for validation and authorization.
You can contact Visa/MC and sign up for the BIN list updates. Visa is free but I believe MC has a fee. Once you sign up, you will get a cd mailed to you with the current BIN ranges monthly.
You can also go through a processor or ISO (independent sales org) if you are working with one. I assume since you have a payment app you have some sort of relationship with an ISO that sets ups merchant accounts for your customers. The ISO should be able to get the BIN list for you from the processor and probably for free.
I think you are on the right track with textField:shouldChangeCharactersInRange:replacementString:, as this gets called each time the user changes the content in the text field. It sounds like you do not actually want to change the textField, but instead want to change another, related control that identifies the card type. You can use the algorithm described in Determine Credit Card Type By Number as a helper function to adjust credit card type accordingly when the user begins typing.
You may want to skip the full verification until the input string has the correct number of characters.
Update: an interesting response in the same thread mentions that actually letting the user pick credit card type is a good idea because it at least shows the user the list of credit cards you accept.
We're programming a Testing Web Application for a University in ColdFusion with a MS SQL Backend.
Right now we have to manually take faxes sent to our fax machine and then find the account they are related to and input the info (the actual fax has to be found in a filing cabinet if we ever need to reference it again). What I would like to do is create a way for someone to fax to a certain number and then the fax be sent to an email account we specify.
If that worked properly we would need a way to get the email, store it somewhere on our servers and then link it to an account. The linking process would probably have to be manual and we are ok with that, but an easy way to view all the faxes sent to that email in our ColdFusion application in PDF form (searchable by the name we assign it) is what we are mainly looking for, so that we don't have to get the faxes on paper and file them by hand.
Is there a way to accomplish this? Preferably not through a paid service as we can program almost anything we need ourselves.
Hmm... have you tried services like eFax?
Why reinvent the wheel? Services like eFax and jConnect (there are several others, just Google "electronic fax service") are affordable and do half of what you are trying to do. Save yourself the effort and just spend a few bucks. You'll probably find out, too, that it will cost you less to just pay for the service than it would cost you to pay the developer to write the software.
So after you bite the bullet and sign up for an electronic faxing service, you just need an email account for it to send to, and to use CFPOP to check the inbox and download the attachments. The rest is a piece of cake.
From the sounds of it, I have built something identical to this faxing setup with Coldfusion.
After a few trials and errors I found best way to go is:
1) DIGITIZE INCOMING FAXES: Have all faxes either sent to an email address you can check via CF, or a network folder you save them on, which you can check with CF. You can absolutely keep your fax number and simply call forward incoming calls to your digital fax number.
2) PROCESS INCOMING FAXES When you find a new fax, it is best to process it and make a record of it. I store things like the file name, dig up the fax number it came from, check it against a list of known numbers, and have a routing table (in case it needs to go to someone).
3) PRINT AND ROUTE FAX Auto printing a document once in CF is possible via CF as well.
As for tables, I keep one to store each fax. I store the fax itself in a blob as well. Easy to replicate and move around, no big performance hit. I keep another table to store a list of incoming number profiles (like a caller ID table) to relate the number to a customer. I keep a table for routing rules, if an email comes from here, send it here. Last, but not least, if you have to manage multiple phone numbers, you can create multiple incoming profiles and file them.
Once you have each fax stored in the DB, you can do a lot with it and file/index/ store it digitally how you like. CFDOCUMENT will display disk based PDFs.
I ended up having to program something like this for custom routing options. It is possible to auto link items to certain files/folders/projects if you like as well with CF.
If you need to know anything else, ask, or we can discuss it off line if you need to keep some details private.
Agree with Adam. Don't create a bunch of problems for yourself - you'll save a lot of money and nerves by just using the existing service.
On the topic: I use Popfax and I kind of like it. It's comfy, gives you opportunities, discounts, contests and a lot of stuff you'd like if you'd be interested in. It's cheap (at least, 100% cheaper than your own software) and you can use it not only on PC, but also via mobile phone
I'm involved in building a donation form for non-profits. We recently got hit by a fast round of low dollar submissions. Many were invalid cards, but a few went through. Obviously someone wrote a script to check a bunch of card numbers for validity, possibly so they can sell them later.
Any ideas on how to prevent or limit the impact of this in the future?
We have control over all aspects of the system (code, webserver, etc). Yes the form runs over https.
When a flood of invalid transactions from a single IP address or small range of addresses is detected, block that address / network.
If a botnet is in use, this will not help. You can still detect floods of low dollar amount submissions and so deduce when you are under attack; during these times, stall low dollar amount submissions to make them take longer; introduce CAPTCHAs for low dollar amount donations; consult your bank's fraud prevention department in case they can make use of your server logs to catch the perpetrators.
Force donors to create accounts in order to make donations; protect account creation with a CAPTCHA, and rate limit donations from any one account.
Raise the minimum permissible donation to a point where it no longer makes financial sense for the scammers to use you in this way.
Instead of CAPTCHAs, which will annoy users, you might want to take advantage of the fact that most people have javascript enabled while bots don't. Simply create a small piece of javascript that when run inserts a particular value in a hidden field.
For those that have Javascript disabled you can show the CAPTCHA (use the <noscript> tag), and you can then accept a submission only if either of these measures check out.
For maximum annoyance to evildoers you could make the difference between the succeed message and the failure message computationally hard to distinguish (say everything is the same, except for one picture that displays the message) but easy to understand for humans.
limit submissions from the same IP address to one per minute, or whatever reasonable period of time it would take for a real person to fill out the form
Raising the minimum donation to a point where it no longer makes financial sense for the scammers to use you in this way will help in general.
This. How many legitimate donations do you get for under 5 bucks, anyway?