In my every application i want to create a unique url for users profile as http://app.com/username .
I have the name of user is : 'Vijay Kumbhar' i can create http://app.com/vijay_kumbhar, but if there is another user registers with the same name then what will be better way of creating url for that user.
one way is to add vijay_kumbhar_1, but i dont think this is the proper way of creating a unique url
Can you please suggest me the better way of doing this.
Keeping in the User experience in consideration, firstly provide the user with unique id, through which you can identify the User easily. After that you can allow the User to opt for any new User Name (screen name), but there should be a check again that the user name has to be unique again. Depends upon your requirement. Do keep us posted what way you opted at last.
You can use the same approach as stackoverflow using
stackoverflow.com/users/unique-number/user-name
Usually user names must be unique. If you're using login in the URL, then they urls will be unique. It is common thing to prevent registering two users with the same login.
EDIT:
If you'd like to keep usernames not showing (e.g. for some security reasons), you can use in URL hashes from users logins, not the logins e.g.
app.com/mylogin > app.com/123123123
You keep your registered users most likely in some kind of a database. In SQL it is natural that every row has a unique ID. You could use such an ID as a part of the url, instead of an own running number for every name combination.
You definitely need to make sure you do NOT show the actual "username" in the URL if you have a publicly accessible URL.
If you use an ID number, just remember to avoid the error that Wordpress made - creating the user IDs sequentially, starting with the default admin user as "1".
That made it easy for hackers to query with something like
example.com/profile?author=1
That would return
example.com/admimuser
And show him the actual username of the admin... and then cracker starts pounding away trying to brute force the admin username's password.
And never show the login name to anyone or in any URL other than to the user or admins!
Related
I am working on a little package using PHP and MySQL to handle entries for events. After completing an entry form the user will see all his details on a page called something like website.com/entrycomplete.php?entry_id=15 where the entry_id is a sequential number. Obviously it will be laughably easy for a nosey person to change the entry_id number and look at other people's entries.
Is there a simple way of camouflaging the entry_id? Obviously I'm not looking to secure the Bank of England so something simple and easy will do the job. I thought of using MD5 but that produces quite a long string so perhaps there is something better.
Security through obscurity is no security at all.
Even if the id's are random, that doesn't prevent a user from requesting a few thousand random id's until they find one that matches an entry that exists in your database.
Instead, you need to secure the access privileges of users, and disallow them from viewing data they shouldn't be allowed to view.
Then it won't matter if the id's are sequential.
If the users do have some form of authentication/login, use that to determine if they are allowed to see a particular entry id.
If not, instead of using a url parameter for the id, store it in and read it from a cookie. And be aware that this is still not secure. An additional step you could take (short of requiring user authentication) is to cryptographically sign the cookie.
A better way to implement this is to show only the records that belong to that user. Say the id is the unique identifier for each user. Now store both entry_id and id in your table (say table name is entries).
Now when the user requests for record, add another condition in the mysql query like this
select * from entries where entry_id=5 and id=30;
So if entry_id 5 does not belong to this user, it will not have any result at all.
Coming towards restricting the user to not change his own id, you can implement jwt tokens. You can give a token on login and add it to every call. You can then decrypt the token in the back end and get the user's actual id out of it.
I am developing an app with PhoneGap and have been storing the user id and user level in local storage, for example:
window.localStorage["userid"] = "20";
This populates once the user has logged in to the app. This is then used in ajax requests to pull in their information and things related to their account (some of it quite private). The app is also been used in web browser as I am using the exact same code for the web. Is there a way this can be manipulated? For example user changes the value of it in order to get info back that isnt theirs?
If, for example another app in their browser stores the same key "userid" it will overwrite and then they will get someone elses data back in my app.
How can this be prevented?
Before go further attack vectors, storing these kind of sensitive data on client side is not good idea. Use token instead of that because every single data that stored in client side can be spoofed by attackers.
Your considers are right. Possible attack vector could be related to Insecure Direct Object Reference. Let me show one example.
You are storing userID client side which means you can not trust that data anymore.
window.localStorage["userid"] = "20";
Hackers can change that value to anything they want. Probably they will changed it to less value than 20. Because most common use cases shows that 20 is coming from column that configured as auto increment. Which means there should be valid user who have userid is 19, or 18 or less.
Let me assume that your application has a module for getting products by userid. Therefore backend query should be similar like following one.
SELECT * FROM products FROM owner_id = 20
When hackers changed that values to something else. They will managed to get data that belongs to someone else. Also they could have chance to remove/update data that belongs to someone else agains.
Possible malicious attack vectors are really depends on your application and features. As I said before you need to figure this out and do not expose sensitive data like userID.
Using token instead of userID is going solved that possible break attemps. Only things you need to do is create one more columns and named as "token" and use it instead of userid. ( Don't forget to generate long and unpredictable token values )
SELECT * FROM products FROM owner_id = iZB87RVLeWhNYNv7RV213LeWxuwiX7RVLeW12
I've a problem deciding where to place a certain table field within my database.
The database is for a classified ads website.
I want registered and non-registered users to be able to post ads. If an unregistered user posts an ad, the site should ask him for the contact phone, if the user is already registered, then the contact phone stored in the users' table should be used.
Now my question is, would it be possible to store the contact phone for both registered and unregistered users in the same table field?
If so, where should that field be put, in the Classified ads table, or in the users' table (noting that each user within the table has a unique Id, thus, filling the users' table with unregistered users just to get their contact phone will just fill the table with useless data)
Thanks in advance !
well you can put the phone field in the ads table, with a is_registered field inside. Then via php you check is_registered and then you know where to search for phone number.
Regards
You can store unregistered users' phone numbers in the same column of the same table, and you probably should. It makes the transition from unregistered user to registered user dead simple--you don't have to move or re-enter phone numbers. And if any user changes phone numbers, it only has to be updated in one place. (Do you know how many people accidentally drop their cell phones in a toilet every day? It's staggering.)
If you're now relying on the presence of a phone number to identify registered users, you'll need to fix that first. (I don't think you're doing that, but if you are, fix that first.)
You said
filling the users' table with
unregistered users just to get their
contact phone will just fill the table
with useless data
If it's useless, don't store it. If you need to store it, it's not useless.
You can always delete unregistered users when their classified ad terminates. But . . .
Does it make sense to require a contact phone number instead letting the user choose to leave either a phone number or an email address? Personally, I prefer to use a throw-away email address for things like this.
I would look for flexibility in your design, but if your logic treats users mostly independently of whether they are registered or not, I would use the same table and just complete the rest of the user's data for the registered ones. I wouldn't store user data on the ads table, even if only for clarity of data organization.
I guess your registered users will all have a username and password, so you can just check the presence of these to know if they are registered or not. If you don't want to change your logic in the future you should choose this distinction carefully of course.
A different approach: Why not making registration so easy that it makes no sense to have unregistered users? I you are already asking for a phone number in all cases, just add a password field or generate one automatically and you have all your users registered.
I would ask for an email so you can send the password and perhaps ask for account verification (now or in the future).
I was wondering if it would be better to have things like perishable_token (used for account validation and resetting of passwords), banned (boolean to check if the user is banned), email_verified (boolean to check if user's email has been verified) in a separate table in the database, as it will rarely ever be used.
Also, I have my applications set so that a user logs in with a password and email address. The email address will only ever be displayed on the User Edit page, and the password will never be displayed anywhere. As these two things will pretty much only be used when the user logs into their account, is it necessary to have them in the main User table in the database? Or would it be better (faster?) to have them in another table?
The user table will have -many- other things that will be displayed on all pages and will need to be checked often (things such as a user's "money" "credits/points" "logged_in?" "badges" etc).
Since your user table has many other things, it seems unlikely that you would get any performance improvement by moving those five columns (which seem not to contain much data) into a separate table.
I write the code for my own website as an educational/fun exercise. Right now part of the website is a blog (like every other site out there :-/) which supports the usual basic blog features, including commenting on posts. But I only have comments enabled for logged-in users; I want to alter the code to allow anonymous comments - that is, I want to allow people to post comments without first creating a user account on my site, although there will still be some sort of authentication involved to prevent spam.
Question: what information should I save for anonymous comments? I'm thinking at least display name and email address (for displaying a Gravatar), and probably website URL because I eventually want to accept OpenID as well, but would anything else make sense?
Other question: how should I modify the database to store this information? The schema I have for the comment table is currently
comment_id smallint(5) // The unique comment ID
post_id smallint(5) // The ID of the post the comment was made on
user_id smallint(5) // The ID of the user account who made the comment
comment_subject varchar(128)
comment_date timestamp
comment_text text
Should I add additional fields for name, email address, etc. to the comment table? (seems like a bad idea) Create a new "anonymous users" table? (and if so, how to keep anonymous user ids from conflicting with regular user ids) Or create fake user accounts for anonymous users in my existing users table?
Part of what's making this tricky is that if someone tries to post an anonymous comment using an email address (or OpenID) that's already associated with an account on my site, I'd like to catch that and prompt them to log in.
The whole point of anonymous comments is that users don't have to login, right?
My personal taste is to not force the user to enter anything, not even their name! The only requried field is the comment text itself. If they don't want to give out their name or email, fine, who cares?
If they provide an email that already exists, there's a chance that they registered a looong time ago and don't even remember their password.
Again, don't force the user to login in that case. Just give them a choice to either login or leave email field blank (or change its content). Or, just show a warning box telling them that the comment will be sent without the email address, with "ok" and "cancel" options.
So, what to store with the anonymous comment?
I'd say store their name and email (of course, don't display their email to the public), but make them optional fields, not mandatory.
You can also store their website, although I personally don't know what's the point of that, other than maybe self-advertising for the anonymous poster!
No question, you enter the "username" on the comment table. And you copy the value in your user table to that field for logged in users. This way if a user is deleted, their comments still have a name attached to them. Comments are usually hierarchical making it difficult to just delete one in the middle of a comment tree.
If they leave it blank, you enter your "anonymous_user" text in the table.