I've guessed the Users Address from their GPS, looking up their location using Google's Places, but the output of that is pretty variable (no locality oftentimes, outside cities a consistent locality field would be helpful to my app). The thing is I do NEED the users home address for my app to work, but they may not be at home when they download the app.
I'd prefer to get their address from contacts. I've looked at a couple of Flutter plugins for accessing the address book, flutter_contacts, etc., but I can't see how you simply get the users details. So how do I request the Users HOME address, HOME email, MOBILE phone, whatever I can get from the device? Age might actually be beneficial too, so I could pivot the app to the needs of those who are using it.
I feel this is such a commonly useful thing it should have its own special permission, rather than the blunt one of exposing their entire contacts address book. So is there a better way of doing it? Less invasive so the user can more easily consent?
There's a special contact called "Profile" that contains the user's details if they bothered to add them on their phones, but in most cases it'll be empty, and anyway, accessing the user's profile requires the "Read Contacts" permission.
It'll be strange to ask the user for the "Read contacts" permission without they understanding why on earth would your app require such a permission "to guess your address" is not a very good reason.
And I suppose might cause some users to uninstall and/or flag your app as potential spyware.
If you app relies on having the user's address, you should instead simply pop a dialog with a question to the user to fill out their address manually.
I'm developing my first iPhone app to make what is effectively an app version of a fantasy league I created for work colleagues.
I am using Parse for the backend of the app. I only want people to be able to register with their work email address ie only if their e-mail address is _#mycompany.com
I'm sure this would be quite easy to someone who knew what htey were doing but I'm kind of new to this so any advice would be much appreciated.
Thanks
You could do this in a number of ways. The easiest way would be to have the validation happen on-device - just check the e-mail address the user has put into the app, and only allow the registration to happen if it matches the domain you want to limit it to.
However, although this is very easy it's also open to abuse and it's not very flexible (if you want to add additional domains, you have to update the app).
Fortunately, Parse offers cloud code, which lets you validate data server-side. Cloud code is written in JavaScript, and you then upload it to Parse. There is full documentation on Parse's website, including examples for validating data.
I have built a Custom B2B app for one of our clients. My question is how to automate the distribution of the redemption codes.
I have already looked at some of the MDM providers. Their solutions are too expensive and all we really need is a way to distribute the app from a webserver, not manage a bunch of mobile devices.
As you probably already know, when a client buys a Custom B2B app through the Apple VPP program, they get a spreadsheet with valid redemption codes for the number of licenses they have built. This spreadsheet has 2 columns: 1) redemption code 2) URL to redeem the code
I want to provide my client with a URL where they can send their users to download the app. They just don't have the expertise/infrastructure to distribute the app themselves. And emailing clients is not going to work.
I'm not a web guy, but it seems to me that we could write a webpage that would look at the spreadsheet for the next available activation code and then redirect the user to the associated URL. I'm not concerned with the number of licenses they distribute since I have another way of auditing the real number of users (Flurry). So I want this to be as painless as possible.
In fact, I have multiple clients and want to provide them each with their own URL for their clients. It seems like this shouldn't be too difficult to code.
The problem is, I'm not the guy to write that code. Any ideas on how best to do this?
Assuming that you don't want to show the user a website you should be able to do this with an online service like parse.com and the features it offers.
From a user POV you would supply them with a link which directed them to parse.com with a path and parameters indicating the action to be taken (get app) and what account is associated. This would redirect the users browser to the appropriate destination.
The main issue (and this applies to any solution) is knowing if the user actually followed through and used the code. i.e. should it be removed from the DB so it isn't offered to another user in future. Then you would update the DB each time you get a new spreadsheet.
Anyway, this could be achieved with a little javascript in parse.com, specifically, by using cloud code which can interrogate and modify the DB and then redirect the user.
Obviously if you need user authentication of some kind or other restrictions then you would need to start adding some web interface on top of this in order to collect the details.
I need to know if an installation has been paid for in the past so I can provide some premium features.
Storing a payment flag in indexeddb or the file system sounds easy to defeat. Periodically asking a server and caching the response could do the trick, but I guess the user would have to be logged-in at all times (through google or otherwise) and I'd rather not impose that restriction.
Maybe if there's a way to uniquely identify a user's machine (uuid, mac address, etc) that could allow me to determine if they've made that payment?
Ultimately, this is client side JavaScript. The only means by which you can prevent use of certain features, is to put them on your server and charge for the service.
Some weak methods for preventing access include license validation, and asking the server for non-essential information (if it was essential, then see the above).
For license validation, you could create an algorithm that takes data from the user and transforms it into something else. For example, say they create an account on your website, which your server knows is a 'pro' account. You could then take their first name and email address and do some magic on it.
Here's a simple example that takes those inputs and gives us a key. In this example if our first name is "John" and our email is "john#domain.org", then our key will be fcumnflqjpBfqockp0qtifcufLqjp. However, Tony, with the email "tony#doman.org" would recieve fcumnfvqp{Bfqockp0qtifcufVqp{
You can send this key to the user, and have your code decide whether it can extract the name and email by applying the reverse algorithm.
You can reverse the strings, do various bit math, etc. It's security by obscurity. Other than an account, this is the most common method. It's used by nearly all offline software. Its kryptonite is key generators, which reverse engineer your code, and generate keys by the algorithm you use to verify them.
All the methods such as uuid, mac address etc can be easily forged imo. I think you cannot escape keeping track of user's logged-in status. Implementing something like a cookie based mechanism would be the right way to go.
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 3 months ago.
The community reviewed whether to reopen this question 3 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I'm creating a web app that requires registration/authentication, and I'm considering using an email address as the sole user id. Here are what I see as the pros and cons (updated with responses):
PROS
One less field to fill out during registration (it would just be email address, password, and verify password). I'm a big fan of minimalistic registration.
An email address is easier to remember. (thanks Mitch, Jeremy)
You don't have to worry about your favorite username being taken already - you're the only one who uses your email address. (thanks TStamper)
CONS
User has more to type every time they log in.
What if a user wants multiple accounts? They'll need another email address. (Do I even want a user to be able to create multiple accounts?)
Easy for a potential attacker to guess (if they know the target's email address, they know the login id). (thanks Vasil)
Users may be tempted to use the same password they use for their email account, which is bad security. (thanks Thomas)
If you change email addresses frequently, it may be difficult to remember which address you used to sign up for a site after a long hiatus. (thanks Software Monkey)
A hacker could spam the registration form and use "email already taken" responses to generate a list of valid emails. (thanks David)
Not everyone has an email address. (thanks Nicholas)
If I went with email as id, I would provide a mechanism to allow it to be changed in the event a user changes address. In this case users would not be posting content to a public site, so a separate username won't be necessary to protect the email addresses (but it is something to consider for other sites).
Another option is to implement OpenID (which is a whole other debate).
This seems to work for Google, but their services are tightly integrated. What have I missed in my analysis? Do you have any recommendations? Does anyone have experiences to share?
FINAL EDIT
Thank you all for your responses. I have decided to use email as an id, but then allow the creation of a username for login purposes after registration. This allows a little flexibility while keeping registration as short as possible. It also prevents problems when a user changes email addresses (they can just log in with their username and update it). I will also be implementing methods to prevent brute-forcing of email addresses out of the registration and login systems (mainly a cool-down period after repeated attempts).
Personally, I prefer just using my email address as a username. It's one less thing to remember, and I never have to worry about my preferred name being already taken.
Just my 2 cents!
I think you missed a PRO:
Users are likely to remember their email address; and as email addresses are unique, they never have to worry about their preferred username being taken already.
As a user of websites, I can tell you that I hate memorizing unnecessary usernames. I don't use a unique handle or anything so I can never remember which variation of my name I used that wasn't already taken. I'd much rather type my email address.
Also, I like OpenID.
CONS
When the same password is used for the e-mail account, compromising the one automatically means compromising the other.
CON: Not everyone has an e-mail address. Consider if your database is ever accessed by an internal application. If you are running a store, people will call up and place an order by phone and refuse to provide an e-mail address. So while having an e-mail address as the default user ID is cool, be sure to allow alternates to get into the system. (Of course, this depends on the context.)
Learned this one the hard way.
I tend to not prefer pro/con lists, and instead try to think of benefits and challenges.
Challenge:
Some users will be tempted to use their email address from their ISP. Linking to an email alone, may be difficult for the users who forget to update their email in all the web sites they have signed up for before they change ISPs.
Instead:
You should consider allowing a user to provide multiple addresses, as well user-selected id and then let the user decide what they want they wish to do. Perhaps also consider allowing the user to provide an OpenID account.
CON: If I change my email address, suddenly all my account names are invalid. My name doesn't change, but my email often does. I have occasionally revisited a site after a number of years, and been stuck... what was my email address two years ago???
One setup you may want to consider: Have both a username and an email. The email is used to login and is always kept private, the username is used to identify the user in any public interaction, such as posting a comment. It winds up being slightly more secure as both halves of the user login credentials are kept private, whereas if you use a username for both login and public identification, half of the login is already known.
I definitely agree with you about having minimal registration for most cases, but depending on what you're doing you may want to balance that against added security for your users. Four fields isn't outrageous for registration, (username, email, password, confirm password), and if you're feeling particularly adventurous, you could cut it down to three by dropping the confirm password field, or two by emailing them a password that they can change later.
PRO
People hate having to create a unique name that fits their id and that has not already been taken to register for a site..So this is why the user id as EMAIL ADDRESS is so embraced.
ex:TStamper1930, who actually wants to remember 1930 at the end of my name that I really wanted
CON: If a hacker can try registering random email addresses en masse, he or she will be able to figure out which of those addresses are valid based on which registrations fail. This is a tactic that can be used to put together lists of known valid email addresses, which are a hot commodity on the spam black market.
Although now that I think about it, that's a problem that affects any website which asks for an email address as part of the registration process, regardless of whether or not there's a separate username. But it's still something to think about.
Stick to email addresses they are used everywhere, actually most of the major websites use them, they are unique so they save the user from struggling to find a name that's not used by others, also users won't forget their email addresses (in most cases at least :)), which is unlike usernames that they will keep on forgetting if they don't visit your site very often.
You shouldn't be worried about them being too long as all the major browsers (IE, FF .. etc) offer autocomplete to forms which is enabled by default, so you type the first letters in your email and you get a drop down list (ie. autocomplete list) where you just click to enter the whole email, personally I almost never type the email address in full, I always type the first letters then select the email from the autocomplete drop down list. Besides, if you allow users to be remembered (using a Remember Me checkbox and persistent cookies), it will be another reason to not worry about it.
I don't know about your app but usually users having multiple accounts is not desirable in most apps.
One con might be that if it's an email address the login can be guessed by people and brute force attacks attempted. Which is not really a big issue, since on most sites today the logins are publicly displayed.
The biggest pro is that logins are easier to remember this way.
A good setup is to require username and email. Allowing the user to login with either email address or username is very user friendly. An added benefit is the user can change their email address. It would also allow multiple accounts for one email.
To solve your con item of the email being too long to type in every time. I have implemented the StringScan Ruby library.
require 'strscan'
def signup!(user, &block)
self.email = user[:email] unless user[:email].blank?
str = StringScanner.new(self.email)
str.scan_until(/#/)
str.pre_match
self.login = str.pre_match
etc..
Then just change login method to allow either email or login to match password.
This works just like google or mobileme. A user can choose to just type in their email username (ie. username instead of username#gmail.com.)
I'm fighting with removing this right now. Here's a newer CON from the current era.
An email address is considered Personal Identifiable Information (PII) by many governments. Hence extra care needs to be taken any time you display it on a page, or even return it from an end-point.
Consider that many sites allow interactions between different users. This often means the site will provide a list of users to choose from (e.g. a drop-down list, or search results). This ca actually enable the leaking of PII by the site.
Usernames, on the other hand, can be completely anonymous. Given the prevalence today of password managers, users really don't need to actually remember their username and password.
If you don't care about forcing your users to login to your application with Facebook or some other social network (most people don't seem to care), then you can just use their social network email as their 'user id' when referencing other tables/documents (MySQL, Mongo, etc).
I've noticed the bonus to using social media logins is that all the security has been taken care of by said social network, including not allowing 2 users to have the same email or username in their database thus saving you the hassle of having to code for all of that. This is just my personal preference.