The idea is not to use email addresses for uniquely identifying users for a contest submission form I need to build. Since emails are not unique and google allows emails with periods in them which makes it difficult to say if email is unique or not.
My requirement is the user is able to submit 2 ballots against an entry which gives them two spots. When the user lands on the page, I ask them if they are a new user or a returning user. If they are new user I generate a unique guid on server side and give it to them. If they are returning user I ask them to enter the guid provided and then I check this on my db to make sure its there and then show them the thank you page if they have casted all 3 votes or take them back to the page where they vote on facebook or twitter.
any thoughts? I think using guids I can guarantee noone would cheat the contest unlike emails which are not truly unique.
Related
We are tracking a forgot password workflow action using adobe site catalyst. The flow happens something like below
User requests for forgot password
He provides the email address and clicks on create new password
New password generation like is send to his email address
User clicks on this link and generates a new password
First 3 actions occurs in the same browser. The 4th activity can occur in the same browser or a different browser. Because of this, site catalyst considers that user as a different one (different visitor ID) and considers that as a totally different visit. Ideally the number of users who completes activity 4 should be less than that completes 1,2,3.
But for us, we are seeing more users who completes activity 4 which could be because of this different visitor issue.
Can someone please suggest a better approach to solve this?
You might want to try overwriting the Visitor ID.
I do not know how your site works in the backend, but generally, and theoretically (as I have yet to be asked by clients on to implement this):
Extract the Visitor ID when the user provides the email address and clicks on create new password. You might want to check the appendVisitorIDsTo (Cross-Domain Tracking) function out and see how the Visitor ID query parameter is implemented.
Send the Visitor ID along with the email address to your backend controller that spits out the template forget password email.
In the template forget password email, append the extracted Visitor ID as a query parameter in the reset link.
In DTM (if you are using DTM), modify your Marketing Cloud Visitor Service tool enable this configuration: overwriteCrossDomainMCIDAndAID.
When the user clicks on this reset link, the Visitor ID should be the one that is initially created for the user.
You might want to read this answer as well.
I'm writing an ASP.NET MVC application, which uses the Membership database to store user registrations. I use email addresses as usernames. When a user registers in my app, I send out an email-confirmation to the address they have used during registration. i.e. I send out an email with a link, which the user is supposed to click, to verify that the address belongs to him.
Until that link is clicked, the account remains 'Unconfirmed' (i.e. EmailConfirmed column equals False). Which means, the account is created, just not active.
How do I deal with a hacker who brute-force creates accounts? I see two big problems here:
Ever-increasing size of the Membership database. A single user, from
a single computer is not a threat, but what if he has 'zombie'
computers?
If User1 creates account with User2#example.com email and
User2 ignores the activation email, the account will essentially
remain locked (unconfirmed), but existing. If User2 decides later to
actually create an account, they can't use their email to register
(account already exists) and they can't Reset Password either -
because even if they reset the password, that does not necessarily
Activate the account.
As for 2) I see a couple of options:
Set expiration date on unconfirmed accounts - i.e. allow the username/email to be claimed again, if the email is not confirmed with 24hrs
Modify my Reset Password method to also activate the account, if it has not been activated. Is that a good idea? I mean, the person would receive an email for that, which is essentially a confirmation, if they click the reset password link in it.
Anything else?
What about 1)? How do I protect myself against bulk create of accounts? Aside from limiting 1 account per IP, per day, using code.
One simple way to deal with this kind of problem is crude but effective.
I usually add an additional field to the form that doesn't form part of what I need - but has a legitmate sounding name like 'Company' - and then I hide it from screen view using CSS. Real user's will never see this on screen, but a bot crawling through the HTML will find it.
Then, when the form is submitted, first I check to see if that form field has a value. If it has - I stop the page from executing any further or just return an HTTP Error as in 99.9% of times only a bot would have filled out that field - not a real user.
//anti-bot measure
if (!String.IsNullOrEmpty(Company.Text))
{
HttpContext.Current.Response.StatusCode = 400;
HttpContext.Current.Response.Status = "400 Bad Request";
HttpContext.Current.Response.End();
}
//carry on processing the form...
I've been using this technique on forms for several years and it's been extremely effective!
I am busy with a Web Api 2 project in VS 2013. We have a number of established applications, and a couple hundred clients with in turn thousand's of users registered at each client.
I am assigned with creating a Mobile App (Cordova/Phonegap), but before I can do this I need to create an API that can handle http Requests from the app.
We have a large database with 173 tables including a user table. This database exists at each client (with their own users). I have imported the default AspNet... tables into our database, changed the connection string and have successfully managed to register users on our database.
My questions is this: Is it possible add additional registration requirements? e.g. in addition to Email, Password, (ConfirmPassword), I'd like to add:
1) Mobile Number
2) Identity number
so that they are also written to AspNetUsers, and then somehow create a foreign key link to my existing USERS table, let's say on ID number provided by the user?
The idea is to not let any user register with the mobile APP that is not already registered on the database.
So, how it should be able to work in my head is not necessarily correct, but here is a summary below:
1) User download app from app store.
2) App shows register/login screen, user register with Email, password, ConfirmPW, MobileNr, ID
3) App sends HTTPS Post request to API with above info.
4) API gets info, before binding to model and writing to db, first does a query to existing User table. If a user exists with ID and mobile Number, then AspNetUsers record is created (with FK reference to Users table). If not, user is not allowed to register, and message is returned, e.g. You need to be a Client of "CompanyName" to register.
5) After this, user logs in and uses Bearer token etc. (default log in way).
I know this is not necessarily how it will work in practice, but can something like this be done. I don't want to re-invent any wheel, only add what listed above. Thanks in advance.
Yes, you can customize the User information. You need to customize the IdentityUser class. Here is a great tutorial on how to do it. I even managed to change the normal Id in the AspNetUsers table (which is nvarchar by deault) to an int.
I need to increase speed of my application but I must also watch on security. First I will explain what app do:
When user register in application he choose school, in user profile in database I store ID of this school.
Every school has it's own page and if user is from that school he can do some things on that school page, write comment's add pictures etc.
User can also visit other school pages but he can't write comments and add pictures.
Currently I keep CurrentSchoolID in ViewBag's.
I wonder is it better to store CurrentSchoolID in cookie.
Is it possible that some evil user user this cookie to harm application?
For application user must have cookies enabled.
If users are not allowed to edit other schools but theirs, you can't count on the ID from the cookie to be true.
Theoretically, what you can do is to save the school ID in a cookie indeed, and upon every write/update/delete action, check (on the server of course) that the logged in user is eligible to alter data related to this school ID.
But in fact, the school ID is unnecessary. Better off - check on the server side which school this user is allowed to edit, and allow the edit operation only if the user edits one of this school's data.
I want to generate a unique url for each user that signs up for my app. The urls should all lead to the same sign up page but each one will be associated with the one user that received it when signing up. Then every time a new user signs up through the unique url, the number of signups associated with that url will increment by one. Therefore, I can track the number of signups generated by each user. How do I build such a system?
This is for a Ruby on Rails app.
i am not exactly sure what your requirement is. But if you thinking of a use case like: User A invites Not_yet_a_user_B. And B gets a unique signup url. B clicks that and register him self in the site and the site records in its db that B was invited by A.
You could implement something like this.
Have a model (and a underlying table) called Invitations with fields (invitation code:string, inviter_user_id:integer). A User can have one (one to one mapping.. oh you can just keep the invitation code in the User table) Invitations. And in the User model have a field called invited_by_user_id:integer).
When A send a sign up request to B, it will look like: www.site.com/signup?invitation_code=ABC. So in your sign up action you can check for the invitation_code parameter and then check it against the Invitations table to find out who invited B. Then record that User ID in B's invited_by_user_id.
Then you can tell who was invited by who. And how many people (and who they are) were invited by a given user.