What is the best way of implementing a checkout process that allows customers to place orders without first requiring registration on the site, and without requiring that users create an account during the checkout process.
I was thinking of perhaps creating a anonymous customer entry which all orders not associated with a registered customer get associated with. Will that work?
How would you then recommend accessing order status?
Well the easiest way to do this is to create an account for the user as they checkout. You can generate a password for them to comply with the existing model, and depending on how you want to handle these users you could also flag the record as a "temp" user. You can then remove these users as time expires. These approach gives you the flexibility of also asking the user to create an account after they have successfully checked out; you'd be surprised how many users are willing to just enter a password when thats all they have to do to create an account.
The key here is to make sure you use a unique id for these users as opposed to the email address; otherwise you will run into an issue when the same customer comes over to purchase again within the period where the user still exists.
There are multiple ways of doing "Guest Checkout"; it depends on how much work you want to do upfront and what your long term goals are.
Related
I want to know what will happen to the users of my app that I used anonymous sign in method for them.
The Firebase documentation is really BAD and didn't explain everything and expect developer to find out himself.
I found in its old version documentation that anonymous session will expires based on the expiration time has been set in Login & Auth tab, but even there didn't mention this means just the session ends or it means that user id will remove also from my app users list or what EXACTLY happened?
I found this answer but it really is not acceptable. The number of anonymous users will grow very very fast if you do a web app and make every thing hard.
I even cannot see the number of my app users in my dashboard!!!!!
So, what should i do? should i develop a dashboard for my data myself or Firebase team should do it? At least for managing users i should have more power than just searching user with their email and when you use custom login you cannot do this also.
Anonymous users don't expire, and there isn't currently any automated way to purge them.
Firebase doesn't automatically remove them because it doesn't really know if a user is still storing data linked to that login - only the app creator does. Imagine if you are playing a puzzle game on your phone, and get to level 100. Then when you go to play level 101 next year, all progress is lost. Firebase can't just assume a user being inactive for a year means that the account can be removed.
There is a couple tools that should help, though.
1) Admin SDK & Firebase CLI list users.
2) Linking multiple auth providers
3) Auth State Persistence
Once you list your users, you can check that each doesn't have any other providers, and hasn't been used recently, doesn't have data stored, and delete them.
Better, though, would be to ensure that only one account is created per user. If you create an anonymous account to help users store data before logging in, you may want to consider prompting them to link a auth provider (like Google or email). If you link the account, rather than creating a new one, you'll avoid abandoned accounts from active users.
In general, you will also want to make sure to use auth state persistence to ensure that there aren't more accounts than necessary being created. Creating 1 account per new visitor, rather than 1 per time someone repeatedly visits your page, will significantly help keep user growth in check.
In my case, I am using the anonymous sign-in method for authentication without the knowledge of the user.
Each time when the user leaves the app, delete the anonymous user by -
FirebaseAuth.getinstance().currentuser?.delete()
There will be no stacking up of anonymous user with this and limits the number of anonymous user in the app
2023 update
Firebase has automatic clean up now.
If you've upgraded your project to Firebase
Authentication with Identity Platform, you can enable automatic
clean-up in the Firebase console. When you enable this feature you
allow, Firebase to automatically delete anonymous accounts older than
30 days. In projects with automatic clean-up enabled, anonymous
authentication will not count toward usage limits or billing quotas.
Any anonymous accounts created after enabling automatic clean-up might
be automatically deleted any time after 30 days post-creation.
Anonymous accounts created before enabling automatic clean-up will be
eligible for automatic deletion starting 30 days after enabling
automatic clean-up. If you turn automatic clean-up off, any anonymous
accounts scheduled to be deleted will remain scheduled to be deleted.
These accounts do not count toward usage limits or billing quotas. If
you "upgrade" an anonymous account by linking it to any sign-in
method, the account will not get automatically deleted. If you want to
see how many users will be affected before you enable this feature,
and you've upgraded your project to Firebase Authentication with
Identity Platform, you can filter by is_anon in Cloud Logging.
Docs
There is a possible cloud function for that.
Check: delete-unused-accounts-cron
This function deletes unused accounts after a certain time. Which might be also helpfull for nonanonymous users.
If you only want to delete anonymous users or check only for them (for example delete after a different inactive time than normal users) you can identify them by checking:
const inactiveUsers = result.users.filter(
user => {
isAnonymous = user.providerData.length == 0;
//do something when anonymous
});
If you'd like anonymous users to be removed from your user list, you'll have to write a service to do that for you.
Since firebase doesn't provide a way to list registered users, you'll have to make sure you're storing some sort of user list in the database. You can then use the node.js admin sdk to get user data, check if the user is anonymous, and find when the user was created. For performance reasons, you may wish to store this information in a special area of your database and retrieve it all at once. Once you've identified a stale anonymous user they can be easily deleted.
I am a newbie to firebase and need some suggestions on structuring data.
I am designing a database for an application where multiple people may share a bank account and can update the status of this account. The group of people sharing this account may also keep changing. So, multiple people may perform actions which will influence the balance available in an account. I decided to list the linked accounts under each user so that one pull is enough to get a list of all user accounts once user logs in. If user is interested in details of a specific account (like balance) then I will go and fetch that child from accounts sub-tree. It all seems fine until I think about notifying users in a smartphone app if the balance associated with any of their linked account changes. Since the balance attribute is not under any specific "user" sub-tree, how to monitor for this change at the application level.
I don't want to bring balance attribute under "user" sub-tree or else I will have to find the duplicate copies and update all of them whenever balance of an account changes. Moreover this approach will not scale well.
Any suggestion?
This question is not related to ASP.NET specifically, but more web applications in general.
I am building a web application wherein I am registering a user. As of now I am taking in very basic credentials like First Name, Last Name, etc of the user. In this website I am giving some information for free for any user who has just registered so that the user finds my website authentic and that it is not a fake website. After that, to get more information, the user has to pay.
The information my site provides will get obsolete after sometime. So, when a new user registers, he/she will get the new information that gets updated; but the old users have to pay to get the same new information.
My problem here is once the information gets obsolete the same person can re-register with a different set of credentials and get the new information. I want to avoid this from happening.
So my question here is this: what information should I request from the user, or extract from the user, to check that the same user is not re-registering? Or any other way to make this possible.
I am thinking of getting the IP address of the machine from which the person is registering and use it to check. But the user can use a different machine to re-register.
I am completely lost here and not getting the solution. I even checked on the Internet but could not find an answer.
Please let me know if you need any further information from my side.
You will not find a technical way to prevent users from registering multiple times. They can simply use another device, IP, another email account and different credentials.
What you can do is asking them to send you hard to fake "offline" information, like a credit card number or a photo of the ID. Some users may still be able to register multiple times this way, but probably not indefinitly. You will however lose many possible clients this way who are unwilling to provide such information for a test account, so this is likely not the solution you want.
My advice would be one of the following two:
Limit the information/service you give out to free users, so that even if they register again they will gain something when they pay.
Try to bind them to their account in a way where they would lose something if they threw it away. This may for example be providing user rewards for activity (real or virtual) or increasing their experience based on their history. Take SO for example: If you registered again, you would lose all your reputation. The users will think twice if this is worth the new content.
After reading all of the above, i think a good solution could be to let the user identify himself through facebook or linkedin. Few people will have a second account.
I think you cannot put any users like that because every thing can be duplicate
There are some ways for which the user must have payment mode or identity details like passport or it is windows application you can have finger scanner it will be definitely Unique..
You can do this (with limitations) with the use of cookies. Setting a cookie on the users device will allow you to determine who the visitor is and that they have already registered.
The limitations are that cookies can be deleted or blocked and are only valid for that specific user agent - the user could use a different device or a different browser on the same device. A lot of people don't really know about cookies though and how to delete them.
By tying this technique with a requirement to provide a valid email address you can make it a hassle for somebody to register more than once as they will have to create a new email account and then delete their cookies.
Whether this will stop enough people depends on your site and your requirements - if you're giving money away then this technique is not nearly good enough. If you just want to discourage the practice of multiple accounts it may be enough.
Your only way out is to have SOMETHING the existing user gets as a "gift?" or added value to maintain just one account. If you can identify items of value to your subscribers and offer to "give" it to them provided their account "attains" one or more status, then you'll get some control. Take stackoverflow.com for example, I don't need a second account.
Identifying by facebook or linkedin is a good option, but if you are giving such services. which are very beneficial for the users, so they dont mind on creating multiple accounts on even facebook or linked in.
So what i think is to set some reward type stuff with each user, and increase the services as they get increment in rewards.once they are good in rewards and are capable to use multiple services, this increases the probability that they will not create another account.
Is there a way in the Drupal interface to exclude a specific user from workflow status without having to eliminate his account and make a new one?
Looking over his account, he does not have any of the roles to receive status but he does.
Alternatively, I'd rather be able to somehow search for his actual email in the entire system and make sure he is not listed anywhere. Is that even possible in Drupal?
Thanks
I had to just remove his extra account. He had an older account as a admin buried deep in the users.
We have a client that is using Cart66 on their site. They want the option to accept checks and ship COD but only want admin users to have the ability to perform manual checkout, but in order to track a customers order history they want to place all orders through the site as the customer.
I guess my question boils down to this: is there a way to log in as an admin user then switch to a non-admin user yet keep admin privileges? They are wanting to switch to a regular user but keep the admin ability to manually check out.
They could switch the user to an admin, perform the transaction, then switch the user back to subscriber. Is there another way to keep admin privileges without these steps?
I hope that makes sense. If there is anyone out there that can point me in the right direction I would greatly appreciate it.
Thanks
Honestly, no. I've gotten around this by opening two different browsers. I.e. I'll create two users: the admin account (my normal account), and then an alternate (test) account that's set as a subscriber. I'll use my regular browser and log in as an administrator (my usual account), and then open an alternate browser, and log in as the test account. So I'll have 2 windows open, but each window has a different account open in it. Works just fine. I get to see everything that happens as and admin and a subscriber at the same time.
It would be cool if you could do something like you're describing though - but I can see why you can't - you're getting into user roles and capabilities that would make no sense if you could do what you're describing.
I suppose one possibility would be to use the current logged-in-user's ID, and write a function that would strip front-end capabilities (visually make them appear to be a logged-in subscriber), but it's a lot easier to just open two different browser windows.