I'm currently playing some stuffs with Near (testnet) following an example on github/Learn-NEAR/starter--near-sdk-as.
I accidentally deleted my account - quantransedev. After that I re-created with the same account name with new passphrase of course. I noticed the newly created account had everything the old one had. It seemed like a restore account.
Is this an expected behavior? it doesn't make sense to me at all in terms of security. Please advise.
https://explorer.testnet.near.org/accounts/quantransedev.testnet
https://explorer.testnet.near.org/transactions/3GTFEzvTfDiAxm8fdpZeWP7NjRFTjFJaDYQNX6ANAUns
This is expected behavior - when you delete an account it does not delete all the things this account owns or controls. That needs to be done manually before account is deleted.
Account deletion just deletes the information about this specific account state on-chain.
When you recreate the account - it will actually be back to controlling whatever was linking to it by account id.
Generally, if you delete account - that name and things it owns are up for grubs for anyone else, so account deletion should be done very careful.
Filed two issues to improve experience here:
https://github.com/near/nearcore/issues/5816
https://github.com/near/near-cli/issues/900
The account had been deleted and the remaining funds were burnt since the beneficiary account did not exist (the account got removed before the transfer was initiated). You can also confirm that the account had actually been removed by reviewing the next transactions (deletion of other accounts with beneficiary account id set to quantransedev.testnet) did not succeed to transfer the remaining tokens from the removed accounts (the tokens got burnt).
You had had to re-create the account explicitly from scratch: https://explorer.testnet.near.org/transactions/CroKF7ipwM3fDgH5ogVrnWS6JSmnhvjkaJNDqiWzjsm2 to gain control over the account id. Before that moment, the account did not exist on the chain. Explorer, however, keeps track of all the ever-existing accounts on the network, which might have confused you.
Related
A toy example:
The application NFTApp created a new account throwaway.near for a new user and minted some NFTs into it. NFTApp has the only full access key to throwaway.near. The user doesn't even know what a seed phrase is.
At a later time, the user decides they want to take possession of this account and its contents but name it keeper.near. Maybe they have created keeper.near previously or maybe they create it fresh as part of this process. Either way, the user controls the only full access key to keeper.near.
NFTApp then deletes throwaway.near and recovers the storage tokens from it.
How can we effect this handoff without needing to manually send contents from throwaway.near to keeper.near?
My Heroku account was flagged automatically and locked due to suspicious activity, which is good security. I raised a ticket with Heroku at the time to unlock the account, they required some information from me, including identity verification, which I provided. Since this they have not responded to my ticket and it appears a bot has automatically closed the issue, with no resolution.
Now it asks me to log a new ticket but I can't actually log in with my account to create a ticket. So I made a new account, logged a ticket with reference to the initial ticket and have had no response. About a week later, it appears my second account must be locked as I am unable to log in with this account. Probably valid since I had to create a temporary email account to sign up so I could raise a ticket.
The Heroku help docs are pretty useless. It's essentially an endless loop of Create Ticket > Help Center > Search > Read Article > Create Ticket...repeat. Even if I get to a sign in page I can't get by it anymore due to yet another account disabled.
That account is linked to my official email address and is why I'd like either the account unlocked or the email address released. It seems as though creating a new account isn't a viable solution either, given that I have tried and that account is now locked too.
I have tried the actions described at What should I do if I can't log into my Heroku account?
There doesn't appear to be any way of getting in touch with a human short of calling an office or a sales rep for enterprise which I feel is the wrong approach. Perhaps this is where my journey ends with Heroku although that seems unfair.
So instead of creating a spamming cycle of new accounts and tickets all referencing each other, how do I go about restoring access to my main account and initial ticket?
I have two questions on the Glympse API:
I am sharing my location by (initially creating a ticket,) uploading location data (/v2/tickets/ticketID/append_location) and appending data (/v2/tickets/ticketID/append_data). If there is already a ticket existing, I am just uploading more recent data (append_location + append_data) and update the ticket (/v2/tickets/ticketID/update?duration=ticketDuration). Now, once the ticket has expired how can I make it active again? Currently I am creating a new ticket which makes the "same user" (but with different ticket) appear again in the Glympse mobile app.
In a group, I can see expired users for a very long time. Once they do not share their location anymore, it takes one or two days until they are removed from the group. How can I remove them instantly once their ticket has become expired?
Thank you
Once a ticket is expired it cannot be reactivated. Small snippet from the Glympse programming guide: https://developer.glympse.com/docs/core/client-sdk/guides/common/programming-guide
Tickets can only transition into GC::TICKET_EXPIRED state once. A ticket is considered immutable after it transitions into the expired state. It leaves the expired state only if being deleted explicitly. This is the only operation that is allowed for expired tickets.
A group member can remove themselves immediately from a group by sending a POST groups/[group_id]/leave
Otherwise, as you noticed the member's ticket information will remain in the group for 48 hours following their ticket's expiration. Group members cannot remove another member from a group.
For others who are interested: The answer to my question is very simple. If a ticket for a user has expired, this very user needs to delete his ticket "/v2/tickets/ticketID/delete?oauth_token=oauth". With the deletion of the ticket, the expired position will vanish immediately.
I've got a bit of an issue. The last owner of a couple of API projects left my company and subsequently his google email account was deleted more than a month ago. This has left us in a precarious state as we are unable to gain administrative access to the API project.
The API projects themselves still seem to be somewhat active as I am able to use some of their functionality, however they are disassociated from any administrative account (as far as I can tell).
I need to either regain control of these API projects or delete them so the old API credentials for them are no longer valid.
This is the reason that for any project within a company should have more than one owner (and any employee's online accounts related to work should be looked at before the person leaves). Normally the project will get deleted after some time if the owner's account is deleted and there are no other owners.
Can you send me the client_id in those projects and the deleted owner's information, so we can have a look at the state?
You can contact me through my G+ profile.
I have an application which uses Dirsync to monitor the changes in AD. When I add/remove users to a group, AD creates an event for it. But when I delete a user from AD, it only create a changelog for user deletion. I don't get a changelog for "user removed from a group"
Is there some settings I can enable to view these kind of changes too?
When you delete an user, they are not automatically deleted from the group. Their SID is left lingering in the group membership unless you manually remove it. This happens to access controls as well, if you gave permission for a share to that user, you'll see a SID with no user information left on the share after you delete the user.
My organization adopted the policy of disabling users and moving them to a "Terminated Users" OU with a GPO attached that makes their session unusable if someone managed to re-enable the account. This allows us to avoid dangling SIDs and not have to worry about doing a full audit of group membership every time an employee leaves.
If you wish, you could do an audit once a year where you remove all permissions for a user, then delete the user, but I don't really feel it's necessary.