We need to make an Account inactive when we finish a process and search for active and inactive accounts for history.
Is there an attribute to make the Account inactive?
Currently that is not possible because AccountInfo has only one command (i.e. Create).
Btw, there would be many complications of deactivating an account:
What happens to the states where that account is a participant? It should be replaced with a different account before deactivation; otherwise after deactivating it, you won't be able to acquire its signature if needed, so those states become "unusable".
Also, the related private/public keys would have to be retired. Currently the node stores a mapping between the UUID of AccountInfo and all related keys. There should be some mechanism to remove those keys from the node. It shouldn't be able to use them for signing after deactivating the account, because they represent that account.
Related
I am experimenting with Hash Time-Lock Contracts in Corda, using the Corda account-based model. It seems to me that, to transact with an account, you must always obtain an Anonymous Party to serve as its public key, via subflow RequestKeyForAccount. And it seems that you will always obtain a different key each time you RequestKeyForAccount, even for the same account.
Assuming the above statements are correct, I am finding it impossible to implement the contract, as the contract must be able to identify whether the public key invoking it belongs to the "locker" or the "lockee" party. The Anonymous Party will always be different, and will never match either the "locker" or the "lockee," because it will be different every time I invoke RequestKeyForAccount.
I have also tried tackling the problem in a different way, by storing "locker" account and "lockee" account in my persisted state - but, the contract does not have access to the account that is invoking it. It has access to the signers - which are AbstractParties. The account invoking the transaction does not seem obtainable.
Bottom line, I cannot implement a contract that tries to ascertain whether the account invoking it matches a particular account stored within the associated state, due to the random anonymized values returned by RequestKeyForAccount; and due to the inaccessibility of account when all I can access are the signers of the transaction, i.e. AbstractParties. I'd appreciate if somebody can tell me if I am off-base in any of my statements.
Always remember that Accounts in Corda are only logical entities. They do not sign transactions and they do not invoke flows in the cordapp. It's their hosting node that does it on behalf of the accounts they own.
So, as also stated in training.corda.net, if you want to restrict access to certain states to a particular account, you have to manage it outside of Corda (for example, create a RPC user that is linked to an account at application level, with the needed restrictions):
Data access restrictions, i.e. restricting users (i.e. Corda accounts) to interact only with states that they own, is the CorDapp developer's responsibility as implementing them is outside of Corda’s scope.
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?
What is the best way to manage domain specific services? For eg: In a Financial domain, Should I have a global service "AccountCreation" or "CheckingAccountCreation", "CreditcardAccountreation" etc.
I am struggling whether to keep them at global level or keep them at the product level. what is the best approach?
You should probably focus in the data first: what data is there, and what data needs to stay consistent. Then focus on what the behaviours around that data are.
In a Financial domain, Should I have a global service "AccountCreation" or "CheckingAccountCreation", "CreditcardAccountreation" etc.
In this example, I would say that you have an "account" service, because you clearly have some accounts - and you probably have to ensure that, eg, you don't duplicate account numbers, apply anti-fraud rules, manage the workflow of creation, etc.
Your examples identify some behaviours: create a checking account, create a credit card account. Those would appropriately be commands that you send to the service, because they result in mutation of the data that the service owns.
If you add a "customer" service, though, that would be distinct from the accounts service: it doesn't have to be consistent with the account service, just to have a reference from accounts to customers by ID.
You also generally don't have shared behaviour that touches both parts - updating data about a customer shouldn't touch the details of their accounts (directly), and updating an account doesn't change the details of a customer.
You might have business rules in one service that change another, such as the account service listening for "a customer became a student" announced by the customer service, and then doing some internal processing.
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.