This may have been answered, I looked but honestly don't know what I should search on. because everything I search on isn't what i want.
Anyway, I am building a ASP.NET SAAS project.
This is my delima, multiple companies will be using the software. I am building it so they themselves can manage their user base.
This is all in one SQL Server DB.
Right now the way it is designed I have a user table that has userid (identity), username, password, companyfk, first name, last name, email. the primary key is userid. The secondary Primary key I say is username.
When someone enters in a user with a particular username it will search to see if that username is taken in the entire table (not based off company).
This could be a problem, I see of people trying to find usernames that work and are professional sounding for the organization.
Couple of options
Do I, have the system make the username itself and give it to them?
Do I partially make the user name and allow them to do the rest. Here I could assign each company a 3 letter abbrev and append it to the user name.
Do I make the username search also be specific only for that company. here the problem I see is when they attempt to login how will I know what company will be logging in. I don't think it is wise to advertise a drop down list of all the companies using the system on the log in page.
Do I make a helper tool like yahoo does that as they are typing it tells them if it is
taken and does a suggestion? This is the more difficult of the 5 choices.
Do I just keep it the way it is and let them deal with the headache (easiest choice of all)
I am leaning towards option (2).
And I am wondering if anyone has thoughts on this.
When in doubt, the easiest way to solve the issue is for them to supply their email address and make that their username.
Considering no two email addresses are the same, I'd say you'd have it made.
Agree with Justin on using email address as it’s the most obvious unique field.
If you really want to go with the username I’d consider requiring company ID as additional field when logging in. This was you can have two identical user names in the table but not in the company.
Related
I have a collection called Vouchers. A user can, if they know the unique number ID of a Voucher, "claim" that voucher, which will give it a user_id attribute, tying it to them.
I'm at a point where I need to check a user's ID query against the existing database, but I'm wondering if I can do so on the client instead of the server (the client would be much more convenient because I'm using utility functions to tie the query form to the database operation.... it's a long story). If I do so on the client, I'll have to publish the entire Vouchers collection with correct user_id fields, and although I won't be showing those ids through any templates, they would be available through the console.
Is there an inherent risk in publishing all of the IDs like this? Can they be used maliciously even if I don't leave any specific holes for them to be used in?
First, in general it sounds like a bad idea to publish all user_ids to the client. What would happen if you have 1 million users? That would be a lot of data.
Second, in specific, we cannot know if there is inherent risk in publishing your user_ids, because we do not know what could be done with it in your system. If you use a typical design of user_ids chosen by the user themselves (for instance email), then you MUST design your system to be safe even if an attacker has guessed the user_id.
Short Version: not so good idea.
I have a similar setup up: user can sign-up, if she knows the voucher code. You can only publish those vouchers where the user_id is identical to the logged in user. All other checks like "does the user input correspond to a valid voucher?" must be handled on the server.
Remember: client code is not trusted.
So this is a bit of a continuation of my previous question.... Reluctantly, I have elected to use the built in ASP.NET/VB authentication. But my main issue now is how to customize it?
For example
1) I need for the username to be an email address, and the build-in version asks for/stores both.
2) What is the best way to store other profile data. {IE address, phone number, etc}.
My ideas...
1) Hide(somehow) the username file on the login control, and pass the email address to both (username & email address) columns.
2) I was going to create a separate table to store the additional data (phone, address, etc) and just keep it by the UserID generated in the ASP Authentication process. But, since I am pretty new at this, I am not sure if there are unseen consequences for doing it this way. In theory it seems that it would work.
The info out there on authentication/membership system is VERY cluttered for someone very new at this. I basically have my site build, but this part. I can't help but to wonder how in the world isn't this easier...
Can anyone offer any input? - Thanks!
There are several services which allow change of usernames frequently like Twitter, LinkedIn etc. Some other have very limited options (example: Facebook for two times). And rest does not allow changing usernames.
The major reasons I can understand is, records are kept against usernames and the URL are cached by search engines against the username. But to solve the first problem, which is much vital, applications can use userid instead of username.
Is there any other important issues/reasons for which I should consider disallow changing usernames?
the main issue is social engineering. people associate a reputation with a name (both the user with the name, and the people who interact with them). if you allow names to change then there is less social pressure to preserve a good reputation and more "bad behaviour".
it's all about coercing users to invest social status in a persistent identity. technically they could implement a system that supports name changes (for example, you could use an arbitrary, unique, auto-generated ID to represent the user in the database/cache/file system and display some (user modifiable) string from the database when showing the name in a web page).
There are technical reasons behind some sites disallowing namechanges, such as if the users have the ability to store files, changing the username may break it if the file paths are based on the usernames. However, a good implementation uses user IDs instead, and avoids such things. For the most part, its a social matter of keeping a permanent link between a user's name and an account. Giving the user the ability to switch names gives other users the ability to impersonate them, or steal their name, and makes it difficult to find people sometimes.
I'd also like to note that there is a difference between login usernames, and nicknames. What you are calling 'username' is moreso a nickname if it can be changed, and usually sites that let you 'change your username' are only letting you change your display name - your login remains the same. Steam is a good example of this, it allows you to change a nickname, but your login name can never change.
I have recently came across this dilemma whether to allow user to change username.
I have entered it on my blog: http://www.dizkover.com/post/423/programming-why-not-to-allow-users-to-change-username-in-social-web-application-design
Can anybody detail some approach on how to save private data in social websites like facebook, etc. They cant save all the updates and friends list in clear text format because of privacy issues. So how do they actually save it?
Hashing all the data with user password so that only a valid session view it is one possibility. But I think there are some problem with this approach and there must be some better solution.
They can and probably do save it in plain text - it goes into a database on a server somewhere. There aren't really privacy issues there... and even if there were, Facebook has publicly admitted they don't care about privacy.
Most applications do not encrypt data like this in the database. The password will usally be stored in a salted hash, and the application artchitecture is responsible for limiting visibility based on appropriate rights/roles.
Most websites do in fact save updates and friends list in clear text format---that is, they save them in an SQL database. If you are a facebook developer you can access the database using FQL, the Facebook Query Language. Queries are restricted so that you can only look at the data of "friends" or of people running your application, or their friends, or what have you. (The key difference between SQL and FQL is that you must always include a WHERE X=id where the X is a keyed column.)
There are other approaches, however. You can store information in a Bloom filter or in some kind of hash. You might want to read Peter Wayner's book Translucent Databases---he goes into clever approaches for storing data so that you can detect if it is present or missing, but you can't do brute force searches.
This is my first MVC/Linq to SQL Application. I'm using the out of the box SQL Membership with ASP.NET to track users through my system.
As most of you know, the UserId is a guid, great. However, to link other user-created tables in the system, I decided to go with username instead of userid. The reason I did this was because:
Username is unique anyway
It prevents me from having to make an extra call when handling db functions.
So for example: I don't have to do a look up on the userid based on username to create a new story; I simply insert User.Identity.Name into the story table.
Now I did run into some nasty complication, which seems to be related to this. It worked fine on my local machine, but not on the host. I continually got an error that went something like this:
"System.InvalidCastException: Specified cast is not valid. at System.Data.Linq.IdentityManager.StandardIdentityManager.SingleKeyManager"...
This happened whenever an insert on the db occurred on the host. If I understand correctly, this is a bug currently that happens when you link a non integer field (in my case username) to another table of a non integer field (username in aspnet_user). Although the bug reported seems a little bit different, maybe they are similar?
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=351358
In any case, MS bug or not - is storing the username instead of the userid in my tables a bad idea? If it is, why?
Update
I just wanted to add some more context here. A good point people are bringing up is that this is dangerous if I want to allow users to change their username in the future. Perfectly valid!
However, this application relies heavily on the username. Each user creates one and only one story. They then link to their story by using: mysite/username. Therefore, the application will never allow them to change their username. It would cause a potential nightmare for people who follow the link only to see it no longer exists.
Be careful regarding your comment regarding usernames are unique. The minute Anita Takeabath gets married to Seymour Butts suddenly atakebath wants to be abutts.
Just a thought!
I've used the same approach as you and it works. Do you have a relationship between your application table and the table from the membership db? If so, you may want to remove that relationship.
My only thought would be in order to future proof your application, the userid would offer flexibility in users changing their username, as the userid would remain constant (like SO for instance).
But that is something that has to fit your application requirements. Then again requirements often tend to change wihtout a developers control.
It's bad for the following reasons:
You mentioned avoiding extra database calls. However, by joining tables, there is no "extra" call to database. You can argue that joining is expensive than no joining at all. However, most likely, a store needs more user information than a user login name (note: user names are not unique, user login names are unique). So you need joining anyway for most database operations.
User login names have different length, it doesn't perform well when they are used in joining.
Edit: modified format. I am still learning how to make my post look better:-)
If the reason you're implementing this is for easier access to the User's GUID, I suggest having your FormsAuthentication.SetAuthCookie use the users's GUID as the name property and use User.Identity.Name throughout your application.
Using username as the unique identifier could have bad consequences in the future. Should you want to allow the user change their username in the future, you will have a hard time implementing that.