I'm looking for the simplest solution to this situation:
I have a pre existing web store with a shopping cart using .NET (vbscript)
I customize what products my customer's see based on the subdomain they use to come to my site (customer.mysite.com)
What my customer's are requesting is, instead of typing in their billing/shipping addresses each time, that they have a selection to choose from from previous addresses they have used.
How can I accomplish this, keeping in mind that they don't log in, they simply use the subdomain to come in to my site and place orders without a user/pass.
The simpler (easier to implement) solution, the better.
Why not just show all the addresses for that subdomain, but, due to some privacy concerns, I would wait until they type in a street address, then show them the addresses for that.
Otherwise, everyone on that subdomain will see the address of everyone else on that subdomain.
If they don't care, then just show all the addresses for that subdomain.
Or, give them an option to login and order, and then when they do that, then you can show them all their addresses they shipped do when they are logged in.
The last one is the preferred one, IMO.
If they don't login then I assume you don't have them create an account either. Thus the server won't be able to identify them. In this case I think you are left with using client cookies. Just make sure you don't store sensitive data in them (like credit card).
I would place a cookie on the users computer with the address information in it attached to the subdomain. The down side to this is that you should not put sensitive information inside cookies but depending on the nature of your business this may not be a problem for you.
Related
First of all, I'd like to preface this post by stating that I know this is a terrible user experience...
I have a client who would like to prevent site visitors from sharing login credentials.
Because this is a corporate marketing site, social login is not an option.
The client claims that there is a site where upon registration, a cookie is dropped onto the user's device and the user is also given a unique password that will only work on that specific device.
Does anyone know how to make this work using Wordpress? (I'd like to avoid using third party plugins)
This sounds like the use of Single Sign On (SSO) or 2 factor Authenticaton (2FA) will be needed. The SSO Wikipidea page references a cookie based solution for TCP/IP networks https://en.wikipedia.org/wiki/Single_sign-on so perhaps that's how this came up from your client.
Once you identify what your options are with that, based on what your client is using for authentication, then set up may be a bit easier. I think a plugin would save you a lot of time, since this is a pretty elaborate task. This one may do the trick https://wordpress.org/plugins/miniorange-saml-20-single-sign-on/
Regardless it's pretty challenging to prevent the sharing of credentials. SSO may be a deterrent if that gives access to something else that user doesn't want to share. 2FA doesn't prevent a user from sharing the pin thats generated too. Perhaps the only real way is to require an IP match on a device with bio-metric authenticaton.
I'm building a Membership site using wordpress and Membership Plugin .
The site is still on my localhost. I did some trial sign ups and it worked perfectly well. But I noticed that, I can use even a fake email address such as xyz#gmail.com or something to sign up and create an account. So that's the problem. I don't know how this will work when I moved the site to my server.
But do you guys think this is a security hole ?
And what can I do for this as a solution ?
Here's what I suggest:
On the registration page, add a field where users need to enter a special code to complete registration and make the code as an image (or at least as something robots cannot process easy). This will prevent robots from constantly signing up to new accounts with bogus information.
Next, perform basic email validation to make sure the format is correct.
Next, strip the email address the user entered and verify the domain part is correct and if it is, have your server automatically send an email to the new account holder asking him/her to return to a special section of the site where he/she enters a special registration code assigned to him/her to complete registration.
Also, to save database space (I'm assuming registration info will be stored in one), ask users to complete registration within a limited time period or they will have to start over. If the time is up then relevant data from the database can be removed. I suggest setting the time period to at least one day.
If you are unable to do this, then you may need to find a better plugin that has the functionality I described.
And whatever you do, play with the website on localhost and make as few modifications on the live server as possible. This means make all changes at once on localhost if you can then upload everything at once to the live server.
I have a like/dislike buttons and I put them in an update panel to be able to update the counter without refresh the page, the problem that the user can click like/dislike button several times and the counter will be changes
I want to allow user to click the button once I think I may use cookie but I didn't used it before so if anyone can help me doing that I will be thankful
also if there is any other solution that may be better please let me know
Thanks in Advance
If you want to use cookies, you can look at this page (older version) or this page (newer version).
You haven't described what kind of website you are creating, but if you have a user registration/login mechanism, you could just save information that a specific user clicked the like button in your database.
If logging in is not acceptable, you can try to identify your users by their IP addresses, as Adam suggested. You can do this by using:
String remoteAddress = HttpContext.Current.Request.UserHostAddress;
or
String remoteAddress = HttpContext.Current.Request.ServerVariables["REMOTE_ADDR"];
Either way I think it would be best to use cookies combined with another method, because you can then check the cookie first. If it exists on a user's computer, you know she/he has already voted. If the cookie is not there, you can query a database for the saved information about the user (identified by IP or login mechanism). This way you can make less queries to the database, which should be good for your application's performance :).
Instead of using cookies you can track via IP address.
I know IP addresses can change over time so you could use this with cookies but cookies can also be cleared so nothing will be 100%.
When a user clicks like or dislike, store their IP address with the record of the like.
Place code to stop another like or dislike counting if they already have done so.
Then on your update remove the like or dislike button and just show the count.
This is what I use for my application. I also have a Facebook app, in which I use their Facebook user Id which is much harder to fake.
Either way I think IP address is the best way to detect and stop someone from doing it twice.
I am wondering what are the technical hurdles involved with offering a voting system (or say ratings) without requiring the user to sign in. I know there are issues with robots, voting a bunch - but what if you keep the users IP address? Do proxies become an issue?
I'd like to build a public voting system that is still reliable.. is that possible right now?
EDIT
The stakes are moderately high for correctness, that is human-verification, and one-vote-per-user. A full-fledged login will ask too much of the user given his role (voter)
Also, if this is "impossible" to accomplish, how can you detect vote fraud after the fact? Could wikipedia's model work here?
Thanks,
Matt Mueller
As you said, you'll need to handle robot behavior.
If you log an IP address, you'll have problems with corporate users which usually stay behind a proxy, so everyone seems to have same IP.
Maybe you should to display some CAPTCHA image to validate human votes. Can't be that hard for users, since it's suppose to vote only once.
EDIT: How to enforce one vote per user?
You can:
Ask for a valid email and send a link to vote
To log your user in and let it vote
Let user vote and save a cookie
Let user vote and ban user IP
All this options have a weakness, so you'll never be sure.
To handle this problem "definitely", you'll probably need to bind their virtual identity with their real identity. This can be done by asking for personal information and keeping it. But that brings a whole new problem set.
First of all, be sure the voting uses POST to prevent robots and pre-caching clients to cause a vote.
Restricting IP addresses will cause problems with dynamic IP ranges, proxies and people sharing a connection, so I wouldn't go this way.
Most of those systems remember that a user a voted using a cookie, but this can of course easily be tricked by deleting the cookie or just using a different browser.
I'm rewriting a website and going from a home-grown authentication model where users logged in with their account id (numbers) and password, to .NET FormsAuthentication where users will login with a username that they choose (or is available) and a stronger password. There are over 38K existing accounts and I'm trying to decide if the existing users should re-register or if I should write some code to do this on their behalf. I've already ruled out creating the usernames for the users because they won't be able to change their username. Luckily we don't have any users named Brenda Utthead.
If the user re-registers, some may gripe about having to do this step again and it may raise some support calls, but I stay with the standard process that everyone has to do. Or I can allow the user to login with their existing userid and password and then optionally give them a grace period to convert their account. I'm hesitant about the latter because it's special code and a possible threat vector because it bypasses the standard authentication mechanism and allows users to log in using less secure credentials.
This application currently accounts for about 40% of our website traffic and I'm not worried about users not coming back to the website because of the possibility of them having to re-register.
What does everyone think?
If you want your users to come back your best bet is to convert their accounts and send an email explaining the transition.
Do not make them re-register whatever you do.
You'll lose half of your users if you do that.
Give them a service so that they can enter their previous user id and have them provide their email address. Email them at the address provided and have them login with their email address as their new user name.
I am about to do the same thing. I am writing a migration page where the user logs in with his/her existing credentials and behind the scenes, I write out to the asp.net membership tables. Do a check first to make sure they haven't already migrated for all subsequent visits.
Don't make them re-register. A little work on your side is all it takes and you need to keep your customers happy.
After listening to everyone's suggestion, I've decided to modify the login. I look at the username they provide and try to guess that they're an existing user. Then I look them up in the old table and if I find a match take them to a conversion screen. There they can quickly convert their account or skip the whole process and login temporarily. The conversion form has fewer fields to fill out b/c I was able to authenticate them against the old user table so I don't need them to provide as much info.
I'm not thrilled with skipping the conversion but that option is only offered for the first 45 days from go-live.
Either convert them or find a way for both membership models to exist together, and somehow convert each user across at login or something.
Think about how long it took to get the 38k members and ask yourself if those were all wiped out, would those same people go through the hassle of signing up again. If you've got a really strong community you should be ok, the hit would just be a matter of time till you're built up.
The other thing you could do to mitigate the risk would be to send out a email, although spam blockers may filter them you could get to a high percentage of your users and tell them about the new membership stuff. Might get some older people back to the site as well in the process.
The biggest challenge is converting all the data that is associated with the user's accounts. People are going to be really upset if they've built up some sort of reputation that you're going to destroy with a new membership system.
This website is a check your balance type of website. It's not a banking site per se, but it exists as a convenience tool to users. I don't believe it would be realistic for users to cancel their accounts because they are forced to re-register.
I do like some of the ideas I'm reading in the responses though.
I would migrate their information and then on their first login ask them to confirm that their membership info is correct (just to be anal).