Anyone have any ideas on how I could get a unique username (but not the email address) for each user. Ideally, I'd show them a page asking them to specify a username for the site, but the only way I can think of doing that is to show it to them after they've authenticated via G Accounts or OpenId. But, that requires another page, and what if they navigate away without entering anything?
As you suggest, you need to ask them after they log in for the first time. Simply redirect them to that page until they fill it out.
Consider seriously, though, if you really need a username. A lot of sites demand one, but then use it for very little - and it's inconvenient for users to have to try and choose a unique one.
Related
I have my own login form for my website. In addition I have also added google and facebook login.
My question is should I add those user data that's login from (fb or google) into my own userdata table or create a different one each for google and facebook.
1) If I add to my existing one, the password column would be left blank(as fb do not provide one) and anyone who knows the email will be able to access it easily.
2) And if I make different table then I think it will become little complicated or slower when trying to access a user data from across the different table.
What's the best choice of doing it or any other method that's better than this?
Make sure users have to enter a password when they login with Facebook/Google, or make sure regular users do not use a blank password - users without a password can only login with the Facebook/Google API.
Don´t create a separate table, it will only get more complicated. Extend the existing one with IDs (from Facebook and Google).
I need to put a link into email. When user clicks on it, angularjs app should open specific page and entity. I suppose that the link should contain id of the entity. This allows to find the record on backend side and then open page.
Is it safe to publish such a link in email(I mean id of the record in DB)? Do we need to hash id?
I don't really see much trouble.
There are a lot of web pages (angular or not) which provides direct links to pages using the entity id as parameter.
In the case of angular, when another - non-authorized - user tries to enter, it will ask the backend, the backend with reject its petition and you can redirect the user to the home page. So if some user tries to access that route, he well just see the home page.
It is also true that in general (I mean, not angular specifically) some people likes to hash the id, but I don't see that as really needed.
So it comes down to the use case / personal preference. From the point of security, your backend won't give any entity even if you know every piece of it. You need to be logged in AND able to retrieve it.
I have in my web application a role called "Administrator". Users who have this role should be able to modify the information about the registered users.
I am thinking about displaying a table with the user details such as e-mail, username, and be able to change them but I don't know what should I do if a users comes to the office physically, goes to an admin and asks for a password change (yes they can do that). Should the admin just press a reset button over the row and tell the user to check his e-mail when he arrives home and proceed with the recovery? (reset link for example) Or should the administrator reset the user's password and give him his new password in that very moment? The second approach is preferable as I was asked to do that...
I know that the admin shouldn't be able to see the original password as it should be hashed and unknown.
What are your thoughts about this? How would you implement this functionality? Thanks for your help.
There is no one perfect answer for this question. The question of workflow will always be dependent on the specific use-cases of an application and will depend on the context it is built in.
That being said, you are right about one thing - it is horrible, and I do mean horrible, security breach to let an Admin or any other user view a clear text password for someone else. So that's definitely off the table.
In your case, it seems giving the admin the right to change someone's password is the way to go. If you're worried about how it looks, don't be. Google Apps allows domain administrators to change the password for any email account under that domain.
Finally, I would suggest a small additional safety measure. When an Admin changes another user's password, store the old encrypted password in a column, don't delete it. When the admin set's the new password, shoot out an email to the user saying "Your password was changed by the Administrator, if you did not request for this, please click here". When they click on the link in the email, simply overwrite the new password with their old one.
That way in case an Admin is changing passwords without the user requesting it, you have a recourse for the user and the logs will keep you informed of how many time an admin has had a password reset revoked by the user.
So I'm writing a mobile app and have reached a point where I need to allow users to register a username. I'm doing this by asking for an email address, username and password.
Typically, it's been normal to set this sort of thing up on the web by having the user confirm his email address by clicking on a link sent to his inbox.
Needless to say, on a mobile app this is a bit clunky as the user will be redirected out of your app and into his browser.
So I had a look at how other mobile apps are doing it (WP7) and was surprised to see that DropBox and Evernote both allow you to sign up without confirming your email address. The end result of this is that I was able to sign up with completely bogus email addresses and/or valid email addresses that don't belong to me.
I assume this is done on purpose.
Your thoughts?
I came across the same issue when writing a social networking style app. I chose to have the user create a username and then provide and email and password. I do not verify the email address and I've never attempted to send any email to them (yet).
What I would suggest would be alternate ways to validate a users email address. My app allows users to do Facebook Connect. All they have to do is log into Facebook, and the app talks to Facebook to confirm that they are using a valid email address. No need to verify it with a URL in an email.
I believe Twitter has a similar service and there may even be a few others that provide an API.
I've also discovered that a lot of people just want to tinker around in the app and not create an account at all. It's definitely a balancing act
I'd say it depends on your app and how important it is to ensure users have valid email addresses. In an app I'm creating now, we want to discourage users from signing up with multiple bogus accounts (because our system could be gamed that way) so we're not allowing users to log in until their email address if verified. On other sites however, it might not be such a big deal so why bother users with that extra step?
As for a mobile device, I don't see why you can't still send a verification email that sends them to your website to verify their email address. There are plenty of mobile apps that also have a website users can log into to manage their account.
Another option is have multiple "states" for users. Before they validate their email, they are in a "pending" state. Once they click it, they're in an "active" state. If you store the createDate for the user, you can periodically remove pending users older than 1 week (or however long).
The bonus is that you can easily add more states, such as suspended or deleted.
Personally, I wasn't too happy for users to create accounts with any old email address.
I think a few decent options are:
send a confirmation email with a link that uses a Custom Url Schema to redirect back to the app (although this is only good if they use the link on the same device)
send a short PIN in the email for them to enter back in the app.
send a confirmation email with a web link, have your server confirm the valid email/token, and have your app check the account status either periodically or with some sort of realtime tech like SignalR or Firebase.
I prefer the last one, although hardest to implement. A user might well have their phone in their hand and their laptop next to them, register in the app and try to click the link in the email that just showed up on their laptop. I like the idea of the app then just "knowing" that they've validated.
Do you have a web server? Write a web service that does the validation for you on the server side, and sends back the result.
Either you can use some platform, such as Facebook connect as #Brian replied above, or you may give users a reasonable timeframe to verify, for example, a few days or even a week. After that, the account gets removed.
You can even have your app issue notifications to remind the user to verify his account (such as every day, or on the last date of the verification.
Don't ask for email confirmation on mobile and allow the user to use the service. When the user is using a PC, then ask the user to confirm his email.
I won't defend my recommendation because most of the solutions here are valid. There isn't one correct way. You asked for ideas and here's one.
A good strategy is to allow people to use as much of your app as possible given the amount of data they've provided.
For example, in the case of a newsreader you might let someone browse your app without registering, then require an account for offline syncing, and a verified email for alerts. Always give people a good reason to take the next step, and build engagement first, then people will forgive you pestering them later.
Im using DotNetOpenAuth to integrate Google,Yahoo,Twitter and Facebook Logins into my application.
Now everything works as expected.
Twitter returns -> User-name and Claim-identifier(Just Id)
Google returns -> Email-Address, First and last Name and ID(URL+ID)
Yahoo returns -> Email-Address, Alias and ID (Url + ID)
Also im also allowing my users to register internally so my database User table is like this:
ID,UserName,Name,OpenID,LoginType,DisplayName
im wondering what i should be storing as User-Name, i was thinking of the ID, but i have this questions:
Shall i store the whole ID as User-Name ?!
Would it affect performance to store the whole ID(URL) as username?
If i extracted the ID from the Claim-Identifier would it still be unique between all 3 providers?
For OpenID, you must use the ClaimedIdentifier as the ID. Not anything else, and certainly not only a substring from the claimed identifier. Anything else seriously compromises the security of your application.
As far as where you store it, I would recommend you keep a dedicated column for storing your claimed identifier rather than just storing it in your UserName column. Consider this scenario:
A user creates an account with your web site using an OpenID http://SomeOpenIDUrl
An attacker logs in via the username/password form. He leaves the password blank but enters http://SomeOpenIDUrl as the username
The attacker successfully logs in as his victim.
A situation like the above can be mitigated in various ways of course, but the best way IMO is to keep the OpenID out of the username column so that it's completely impossible.