{
  "trx_id": "c343942433f118126c1aae6bdeb90d03df7d4da6",
  "block": 106150546,
  "trx_in_block": 0,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2026-05-18T06:11:39",
  "op": [
    "delegate_vesting_shares",
    {
      "delegator": "steem",
      "delegatee": "sateeshkodati",
      "vesting_shares": "7110.401786 VESTS"
    }
  ]
}

{
  "trx_id": "f2ba16f39bf85b707ee9ea6343e60f69d032e963",
  "block": 106004650,
  "trx_in_block": 0,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2026-05-13T04:00:45",
  "op": [
    "delegate_vesting_shares",
    {
      "delegator": "steem",
      "delegatee": "sateeshkodati",
      "vesting_shares": "4398.191381 VESTS"
    }
  ]
}

{
  "trx_id": "affe2ec81b71702f5dcb96dd7a98cdd50f1d6b3b",
  "block": 105518032,
  "trx_in_block": 0,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2026-04-26T05:23:30",
  "op": [
    "delegate_vesting_shares",
    {
      "delegator": "steem",
      "delegatee": "sateeshkodati",
      "vesting_shares": "7122.917542 VESTS"
    }
  ]
}

{
  "trx_id": "2d63ffbe0809085b0b5e80f223bfd946ce65e053",
  "block": 102870988,
  "trx_in_block": 4,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2026-01-23T23:48:36",
  "op": [
    "delegate_vesting_shares",
    {
      "delegator": "steem",
      "delegatee": "sateeshkodati",
      "vesting_shares": "4439.738200 VESTS"
    }
  ]
}

{
  "trx_id": "e9e750cd16f747cc264e1a1a41f9ecf41abbbd90",
  "block": 91317194,
  "trx_in_block": 2,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2024-12-17T18:58:15",
  "op": [
    "delegate_vesting_shares",
    {
      "delegator": "steem",
      "delegatee": "sateeshkodati",
      "vesting_shares": "4603.957397 VESTS"
    }
  ]
}

{
  "trx_id": "9144c6f685c5c608c9b1f5d3a7379b7b43526e83",
  "block": 79871355,
  "trx_in_block": 6,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2023-11-14T10:39:51",
  "op": [
    "delegate_vesting_shares",
    {
      "delegator": "steem",
      "delegatee": "sateeshkodati",
      "vesting_shares": "4773.090929 VESTS"
    }
  ]
}

{
  "trx_id": "0e8445117c11bb3fb4b62d3343e9823bd3572ac1",
  "block": 78362745,
  "trx_in_block": 0,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2023-09-22T10:17:30",
  "op": [
    "delegate_vesting_shares",
    {
      "delegator": "steem",
      "delegatee": "sateeshkodati",
      "vesting_shares": "7709.999715 VESTS"
    }
  ]
}

{
  "trx_id": "6729a81cbdb86772817018ada37adf2117a2123d",
  "block": 69120494,
  "trx_in_block": 0,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2022-11-03T17:45:33",
  "op": [
    "delegate_vesting_shares",
    {
      "delegator": "steem",
      "delegatee": "sateeshkodati",
      "vesting_shares": "7932.051153 VESTS"
    }
  ]
}

{
  "trx_id": "e48f629d05bd28133b33ca5c9a2ec7322b5cfadb",
  "block": 60823747,
  "trx_in_block": 12,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2022-01-17T22:57:42",
  "op": [
    "delegate_vesting_shares",
    {
      "delegator": "steem",
      "delegatee": "sateeshkodati",
      "vesting_shares": "8152.158754 VESTS"
    }
  ]
}

{
  "trx_id": "96f6de205a184ff8abc15e882e4409c9957ebd02",
  "block": 54614079,
  "trx_in_block": 0,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2021-06-14T06:08:57",
  "op": [
    "delegate_vesting_shares",
    {
      "delegator": "steem",
      "delegatee": "sateeshkodati",
      "vesting_shares": "8336.353042 VESTS"
    }
  ]
}

{
  "trx_id": "c4cf77841cf98af8466165a1302bb9a07d16f25c",
  "block": 49361346,
  "trx_in_block": 0,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2020-12-11T16:21:18",
  "op": [
    "delegate_vesting_shares",
    {
      "delegator": "steem",
      "delegatee": "sateeshkodati",
      "vesting_shares": "8523.775016 VESTS"
    }
  ]
}

{
  "trx_id": "c7286a2f0ac8b8df8581ff45d8f173932de41662",
  "block": 49212870,
  "trx_in_block": 4,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2020-12-06T09:57:03",
  "op": [
    "delegate_vesting_shares",
    {
      "delegator": "steem",
      "delegatee": "sateeshkodati",
      "vesting_shares": "1912.543513 VESTS"
    }
  ]
}

{
  "trx_id": "29c8cb2bcb542f57d40ef3599c51d6a0674eb6ea",
  "block": 49196428,
  "trx_in_block": 3,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2020-12-05T19:59:03",
  "op": [
    "delegate_vesting_shares",
    {
      "delegator": "steem",
      "delegatee": "sateeshkodati",
      "vesting_shares": "8529.982870 VESTS"
    }
  ]
}

{
  "trx_id": "0a2e81e078781a5035c4f5ef190c7511a1ecea89",
  "block": 48270580,
  "trx_in_block": 1,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2020-11-03T02:29:33",
  "op": [
    "delegate_vesting_shares",
    {
      "delegator": "steem",
      "delegatee": "sateeshkodati",
      "vesting_shares": "1920.017158 VESTS"
    }
  ]
}

{
  "trx_id": "9329969522cee5be5e7b4dba27d0c95f75917330",
  "block": 43223192,
  "trx_in_block": 0,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2020-05-09T10:59:57",
  "op": [
    "delegate_vesting_shares",
    {
      "delegator": "steem",
      "delegatee": "sateeshkodati",
      "vesting_shares": "8732.788229 VESTS"
    }
  ]
}

{
  "trx_id": "a10818fb838665f39a2fb54d22b066eccd880328",
  "block": 43200223,
  "trx_in_block": 1,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2020-05-08T15:23:27",
  "op": [
    "delegate_vesting_shares",
    {
      "delegator": "steem",
      "delegatee": "sateeshkodati",
      "vesting_shares": "1953.311140 VESTS"
    }
  ]
}

{
  "trx_id": "4fc36fa3ff7543c83c948682c168e06d5cd28840",
  "block": 42569065,
  "trx_in_block": 14,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2020-04-16T03:13:09",
  "op": [
    "delegate_vesting_shares",
    {
      "delegator": "steem",
      "delegatee": "sateeshkodati",
      "vesting_shares": "8745.675677 VESTS"
    }
  ]
}

{
  "trx_id": "aa423dd7e891d83ec8507579385319d49eec7148",
  "block": 34873754,
  "trx_in_block": 5,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-07-22T03:08:48",
  "op": [
    "comment",
    {
      "parent_author": "sateeshkodati",
      "parent_permlink": "how-artificial-intelligence-could-help-us-to-win-arguments-or-the-independent",
      "author": "steemitboard",
      "permlink": "steemitboard-notify-sateeshkodati-20190722t030848000z",
      "title": "",
      "body": "Congratulations @sateeshkodati! You received a personal award!\n\n<table><tr><td>https://steemitimages.com/70x70/http://steemitboard.com/@sateeshkodati/birthday2.png</td><td>Happy Birthday! - You are on the Steem blockchain for 2 years!</td></tr></table>\n\n<sub>_You can view [your badges on your Steem Board](https://steemitboard.com/@sateeshkodati) and compare to others on the [Steem Ranking](https://steemitboard.com/ranking/index.php?name=sateeshkodati)_</sub>\n\n\n###### [Vote for @Steemitboard as a witness](https://v2.steemconnect.com/sign/account-witness-vote?witness=steemitboard&approve=1) to get one more award and increased upvotes!",
      "json_metadata": "{\"image\":[\"https://steemitboard.com/img/notify.png\"]}"
    }
  ]
}

{
  "trx_id": "142982c7dcaa71c26b0760a5ebdb2b80989d5b07",
  "block": 32852006,
  "trx_in_block": 10,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2019-05-12T20:20:15",
  "op": [
    "delegate_vesting_shares",
    {
      "delegator": "steem",
      "delegatee": "sateeshkodati",
      "vesting_shares": "8941.292490 VESTS"
    }
  ]
}

{
  "trx_id": "a950912ac8cf705faba4e9c56e3e30d5a309875d",
  "block": 22497480,
  "trx_in_block": 38,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2018-05-17T02:39:00",
  "op": [
    "delegate_vesting_shares",
    {
      "delegator": "steem",
      "delegatee": "sateeshkodati",
      "vesting_shares": "9140.807582 VESTS"
    }
  ]
}

{
  "trx_id": "1d3d423cbb0b5a02ecdf6dd29a8e01072994d468",
  "block": 20092614,
  "trx_in_block": 23,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2018-02-22T12:29:18",
  "op": [
    "delegate_vesting_shares",
    {
      "delegator": "steem",
      "delegatee": "sateeshkodati",
      "vesting_shares": "29622.865889 VESTS"
    }
  ]
}

{
  "trx_id": "ba652bf0755dac5c331749b60e3707bbd88ea4c9",
  "block": 18474140,
  "trx_in_block": 34,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2017-12-28T06:26:39",
  "op": [
    "custom_json",
    {
      "required_auths": [],
      "required_posting_auths": [
        "sateeshkodati"
      ],
      "id": "follow",
      "json": "[\"follow\",{\"follower\":\"sateeshkodati\",\"following\":\"sportic\",\"what\":[\"blog\"]}]"
    }
  ]
}

{
  "trx_id": "523f193b110102a6a2c3293df7fe24a842829b9c",
  "block": 18474140,
  "trx_in_block": 8,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2017-12-28T06:26:39",
  "op": [
    "custom_json",
    {
      "required_auths": [],
      "required_posting_auths": [
        "sateeshkodati"
      ],
      "id": "follow",
      "json": "[\"follow\",{\"follower\":\"sateeshkodati\",\"following\":\"gamemusic\",\"what\":[\"blog\"]}]"
    }
  ]
}

{
  "trx_id": "61d484269ed277435d3a3087dfb14061f0e29365",
  "block": 18474139,
  "trx_in_block": 47,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2017-12-28T06:26:36",
  "op": [
    "custom_json",
    {
      "required_auths": [],
      "required_posting_auths": [
        "sateeshkodati"
      ],
      "id": "follow",
      "json": "[\"follow\",{\"follower\":\"sateeshkodati\",\"following\":\"askarif\",\"what\":[\"blog\"]}]"
    }
  ]
}

{
  "trx_id": "1e3a572772cfe01de3ab6ec37d0f1dd946913cc2",
  "block": 18474139,
  "trx_in_block": 39,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2017-12-28T06:26:36",
  "op": [
    "custom_json",
    {
      "required_auths": [],
      "required_posting_auths": [
        "sateeshkodati"
      ],
      "id": "follow",
      "json": "[\"follow\",{\"follower\":\"sateeshkodati\",\"following\":\"always1success\",\"what\":[\"blog\"]}]"
    }
  ]
}

{
  "trx_id": "d00fbf333ae42c524f116621f2a66b2169b29bdc",
  "block": 18471393,
  "trx_in_block": 32,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2017-12-28T04:09:12",
  "op": [
    "vote",
    {
      "voter": "sateeshkodati",
      "author": "sateeshkodati",
      "permlink": "how-artificial-intelligence-could-help-us-to-win-arguments-or-the-independent",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "d00fbf333ae42c524f116621f2a66b2169b29bdc",
  "block": 18471393,
  "trx_in_block": 32,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2017-12-28T04:09:12",
  "op": [
    "comment",
    {
      "parent_author": "",
      "parent_permlink": "ai",
      "author": "sateeshkodati",
      "permlink": "how-artificial-intelligence-could-help-us-to-win-arguments-or-the-independent",
      "title": "How artificial intelligence could help us to win arguments | The Independent",
      "body": "![](https://steemitimages.com/DQmTVVNRxww9su7dwHv9aBkjzeeJKo9BLsGR9vtpbNWUETf/image.png)\n\nhttp://www.independent.co.uk/life-style/gadgets-and-tech/artificial-intelligence-debate-argue-bbc-science-tech-research-a8118191.html",
      "json_metadata": "{\"tags\":[\"ai\"],\"image\":[\"https://steemitimages.com/DQmTVVNRxww9su7dwHv9aBkjzeeJKo9BLsGR9vtpbNWUETf/image.png\"],\"links\":[\"http://www.independent.co.uk/life-style/gadgets-and-tech/artificial-intelligence-debate-argue-bbc-science-tech-research-a8118191.html\"],\"app\":\"steemit/0.1\",\"format\":\"markdown\"}"
    }
  ]
}

{
  "trx_id": "183728094e05c21f4ae454e141e9b1c1e18d2a1d",
  "block": 18029594,
  "trx_in_block": 5,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2017-12-12T19:50:33",
  "op": [
    "custom_json",
    {
      "required_auths": [],
      "required_posting_auths": [
        "sateeshkodati"
      ],
      "id": "follow",
      "json": "[\"follow\",{\"follower\":\"sateeshkodati\",\"following\":\"hottopic\",\"what\":[\"blog\"]}]"
    }
  ]
}

{
  "trx_id": "1f003b5c7fbdfd9e99778728deaeaac1649e9297",
  "block": 18029564,
  "trx_in_block": 22,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2017-12-12T19:49:03",
  "op": [
    "vote",
    {
      "voter": "sateeshkodati",
      "author": "the-alien",
      "permlink": "when-will-cryptos-break-mainstream-resistance",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "8dec5634e32d626ea8452ac205af03567adf0c17",
  "block": 18029366,
  "trx_in_block": 6,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2017-12-12T19:39:09",
  "op": [
    "vote",
    {
      "voter": "sateeshkodati",
      "author": "sauravrungta",
      "permlink": "google-s-ai-masters-all-of-chess-in-just-4-hours",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "a18f23ffd753f4f809be34993258d6ac585a0c48",
  "block": 18029364,
  "trx_in_block": 22,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2017-12-12T19:39:03",
  "op": [
    "custom_json",
    {
      "required_auths": [],
      "required_posting_auths": [
        "sateeshkodati"
      ],
      "id": "follow",
      "json": "[\"follow\",{\"follower\":\"sateeshkodati\",\"following\":\"sauravrungta\",\"what\":[\"blog\"]}]"
    }
  ]
}

{
  "trx_id": "63e0c374b71bd58af0c53723ce9a0ca194af7471",
  "block": 18029361,
  "trx_in_block": 0,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2017-12-12T19:38:54",
  "op": [
    "custom_json",
    {
      "required_auths": [],
      "required_posting_auths": [
        "sateeshkodati"
      ],
      "id": "follow",
      "json": "[\"follow\",{\"follower\":\"sateeshkodati\",\"following\":\"louisthomas\",\"what\":[\"blog\"]}]"
    }
  ]
}

{
  "trx_id": "6691605e529d8ee336134afe72086cc22b673839",
  "block": 18029357,
  "trx_in_block": 8,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2017-12-12T19:38:42",
  "op": [
    "comment",
    {
      "parent_author": "sateeshkodati",
      "parent_permlink": "mongodb-basics-configuring-role-based-access-control-rbac",
      "author": "cheetah",
      "permlink": "cheetah-re-sateeshkodatimongodb-basics-configuring-role-based-access-control-rbac",
      "title": "",
      "body": "Hi! I am a robot. I just upvoted you! I found similar content that readers might be interested in:\nhttps://dzone.com/articles/mongodb-basics-configuring-role-based-access-contr",
      "json_metadata": ""
    }
  ]
}

{
  "trx_id": "b8aa7615b56117973f8e727b367f52d0793bcd19",
  "block": 18029357,
  "trx_in_block": 1,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2017-12-12T19:38:42",
  "op": [
    "custom_json",
    {
      "required_auths": [],
      "required_posting_auths": [
        "sateeshkodati"
      ],
      "id": "follow",
      "json": "[\"follow\",{\"follower\":\"sateeshkodati\",\"following\":\"danizaharie\",\"what\":[\"blog\"]}]"
    }
  ]
}

{
  "trx_id": "7d98d81a9cde4f8d2801815d4ca0fcc9c668e5f5",
  "block": 18029355,
  "trx_in_block": 36,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2017-12-12T19:38:36",
  "op": [
    "vote",
    {
      "voter": "cheetah",
      "author": "sateeshkodati",
      "permlink": "mongodb-basics-configuring-role-based-access-control-rbac",
      "weight": 8
    }
  ]
}

{
  "trx_id": "48c8f90c14b8da9afa70a251e3dfcd211cf1dc7a",
  "block": 18029350,
  "trx_in_block": 15,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2017-12-12T19:38:21",
  "op": [
    "vote",
    {
      "voter": "sateeshkodati",
      "author": "sateeshkodati",
      "permlink": "mongodb-basics-configuring-role-based-access-control-rbac",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "48c8f90c14b8da9afa70a251e3dfcd211cf1dc7a",
  "block": 18029350,
  "trx_in_block": 15,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2017-12-12T19:38:21",
  "op": [
    "comment",
    {
      "parent_author": "",
      "parent_permlink": "technology",
      "author": "sateeshkodati",
      "permlink": "mongodb-basics-configuring-role-based-access-control-rbac",
      "title": "MongoDB Basics: Configuring Role-Based Access Control (RBAC)",
      "body": "MongoDB, an open-source document store and most popular NoSQL database on the market today, offers a variety of advanced features to administer security over your MongoDB deployments. In this tutorial post, we’re going to show you how to set up role-based access control (RBAC) to manage user access across your MongoDB systems for reIndex, mongodump and mongorestore.\n\nIf you’re the administrator of your MongoDB databases, you’ve likely received requests to provide an individual user with the capabilities to perform a certain action(s). MongoDB’s security features are fairly mature now, and allow you to create and assign very granular role-based access control.\n\nWe’re going to walk through an example of granting a user the specific privilege of performing the reIndex action in a step-by-step approach through its resolution. Before we demonstrate how to perform this common security action, let’s go through an overview of MongoDB’s role-based action control.\n\nHow MongoDB RBAC Works\nMongoDB allows you to use a RBAC mechanism to restrict access to users through assigned ‘roles’. RBAC access control is not enabled by default and must be configured by an administrator on your team. By granting a user access to a specific resource, you are authorizing that role or user to perform actions on that resource.\n\nResources\n\nA database, collection, set of collections, or the cluster.\n\nActions\n\nSpecific operations a user can perform on a resource (usually a database).\n\nMongoDB supports pre-defined roles called built-in roles with actions collated into logical groups such as read(-Only), readWrite, backup, etc. MongoDB also supports the creation of user-defined roles.\n\nAuthorizing MongoDB reIndex RBAC Privileges\nNow that you have some context, let’s jump into the steps of authorizing a user the privilege of performing the reIndex action.\n\nHow to create reIndex privileges through MongoDB role-based access control #RBAC\nCLICK TO TWEET\nDetermine the Privilege Actions\nActions in the MongoDB context are known as Privilege Actions and you can find an exhaustive list of these actions in MongoDB’s documentation. The action we’re interested in is reIndex, or the privilege that allows a user to execute the reIndex command on a given database or collection. Since the reIndex command can be expensive for collections with large amounts of data or a large number of indexes, it’s part of administrative roles by default.\n\nGrant Privileges to a Role\nOnce we’ve determined the privileges we need, we move on to granting those privileges to a role. You can also simply pick a built-in role that already has the privilege, but we recommend creating your own user-defined role over modifying built-in roles as they’re good defaults to return to.\n\nCreate a New User-Defined Role\nHere’s what we’ll use to create our new user-defined role:\n\n> use test\nswitched to db test\n> db.createRole({role: \"reIndexing\", privileges: [], roles: [\"readWrite\"]}) // Create a new role out of the default readWrite rule.\n{ \"role\" : \"reIndexing\", \"privileges\" : [ ], \"roles\" : [ \"readWrite\" ] }\n> db.getRole(\"reIndexing\")\n{\n\t\"role\" : \"reIndexing\",\n\t\"db\" : \"test\",\n\t\"isBuiltin\" : false,\n\t\"roles\" : [\n\t\t{\n\t\t\t\"role\" : \"readWrite\",\n\t\t\t\"db\" : \"test\"\n\t\t}\n\t],\n\t\"inheritedRoles\" : [\n\t\t{\n\t\t\t\"role\" : \"readWrite\",\n\t\t\t\"db\" : \"test\"\n\t\t}\n\t]\n}\nGrant Privileges to the New Role\n\nNow we’re going to assign our desired privileges to our newly created user-defined role.\n\n> db.grantPrivilegesToRole(\"reIndexing\", [ { resource: { db : \"test\", collection: \"\" }, actions: [\"reIndex\"] } ])\n> db.getRole(\"reIndexing\", {showPrivileges: true})\n{\n\t\"role\" : \"reIndexing\",\n\t\"db\" : \"test\",\n\t\"isBuiltin\" : false,\n\t\"roles\" : [\n\t\t{\n\t\t\t\"role\" : \"readWrite\",\n\t\t\t\"db\" : \"test\"\n\t\t}\n\t],\n\t\"inheritedRoles\" : [\n\t\t{\n\t\t\t\"role\" : \"readWrite\",\n\t\t\t\"db\" : \"test\"\n\t\t}\n\t],\n\t\"privileges\" : [\n\t\t{\n\t\t\t\"resource\" : {\n\t\t\t\t\"db\" : \"test\",\n\t\t\t\t\"collection\" : \"\"\n\t\t\t},\n\t\t\t\"actions\" : [\n\t\t\t\t\"reIndex\"\n\t\t\t]\n\t\t}\n\t],\n\t\"inheritedPrivileges\" : [\n....\n\t]\n}\n\nGrant the Role to a User\nThe last step is to simply assign the user this new role:\n\n> db.getUser(\"indexUser\")\n{\n\t\"_id\" : \"test.indexUser\",\n\t\"user\" : \"indexUser\",\n\t\"db\" : \"test\",\n\t\"roles\" : [\n\t\t{\n\t\t\t\"role\" : \"readWrite\",\n\t\t\t\"db\" : \"test\"\n\t\t}\n\t]\n}\n> db.grantRolesToUser(\"indexUser\", [\"reIndexing\"])\n> db.getUser(\"indexUser\")\n{\n\t\"_id\" : \"test.indexUser\",\n\t\"user\" : \"indexUser\",\n\t\"db\" : \"test\",\n\t\"roles\" : [\n\t\t{\n\t\t\t\"role\" : \"reIndexing\",\n\t\t\t\"db\" : \"test\"\n\t\t},\n\t\t{\n\t\t\t\"role\" : \"readWrite\",\n\t\t\t\"db\" : \"test\"\n\t\t}\n\t]\n}\nRemember to perform these steps on a dummy user so you can test and confirm the new privileges work before granting and notifying the relevant user of their authorization.\n\n \n\nAdditional Privileges: mongodump & mongorestore\nWe demonstrated the reIndex example first to illustrate both granting privileges to roles and granting roles to users.\n\nA more common use case is providing authorization to perform backup and restore actions using mongodump and mongorestore. This can be done in a single step through MongoDB’s built-in roles, and both backup and restore privileges can be granted to enable users to run mongodump and mongorestore, respectively.\n\nHow to set up MongoDB backup and restore #RBAC privileges with mongodump and mongorestore\nCLICK TO TWEET\nFor example, here’s how we would grant a user permissions to backup and restore any database. Note that these roles are only available to users on the admin database.\n\n> db.grantRolesToUser(\"backupUser\", [\"backup\", \"restore\"])\n> db.getUser(\"backupUser\")\n{\n\t\"_id\" : \"admin.backupUser\",\n\t\"user\" : \"backupUser\",\n\t\"db\" : \"admin\",\n\t\"roles\" : [\n\t\t{\n\t\t\t\"role\" : \"restore\",\n\t\t\t\"db\" : \"admin\"\n\t\t},\n\t\t{\n\t\t\t\"role\" : \"backup\",\n\t\t\t\"db\" : \"admin\"\n\t\t},\n\t\t{\n\t\t\t\"role\" : \"readWrite\",\n\t\t\t\"db\" : \"admin\"\n\t\t}\n\t]\n}\nAdding permissions to backup and restore on a single database or collection requires more work. For mongodump, you must additionally grant a find privilege on that given database, however, mongorestore has more complicated privilege requirements.\n\nSource: https://scalegrid.io/blog/mongodb-basics-configuring-role-based-access-control-rbac/",
      "json_metadata": "{\"tags\":[\"technology\",\"mongodb\",\"rbac\"],\"links\":[\"https://scalegrid.io/blog/mongodb-basics-configuring-role-based-access-control-rbac/\"],\"app\":\"steemit/0.1\",\"format\":\"markdown\"}"
    }
  ]
}

{
  "trx_id": "dfd5a3c7a31c804db07aa5d59550214408c44586",
  "block": 18029286,
  "trx_in_block": 5,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2017-12-12T19:35:09",
  "op": [
    "vote",
    {
      "voter": "sateeshkodati",
      "author": "aggroed",
      "permlink": "craigslist-now-sorts-by-sellers-by-those-accepting-crypto-a-boon-to-crypto-enthusiasts-everywhere",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "79949f97c0f2c1392af4d6895cca54417dd6934c",
  "block": 18029278,
  "trx_in_block": 34,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2017-12-12T19:34:45",
  "op": [
    "vote",
    {
      "voter": "sateeshkodati",
      "author": "sateeshkodati",
      "permlink": "internet-protocols-are-changing",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "9086c64e341d98a0787054f45ee0ffc212d0bf24",
  "block": 18029264,
  "trx_in_block": 18,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2017-12-12T19:34:03",
  "op": [
    "custom_json",
    {
      "required_auths": [],
      "required_posting_auths": [
        "sateeshkodati"
      ],
      "id": "follow",
      "json": "[\"follow\",{\"follower\":\"sateeshkodati\",\"following\":\"marketingmonk\",\"what\":[\"blog\"]}]"
    }
  ]
}

{
  "trx_id": "bf6523dae10c77150379e828ae5f7b5c8ab3a781",
  "block": 18029236,
  "trx_in_block": 8,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2017-12-12T19:32:39",
  "op": [
    "custom_json",
    {
      "required_auths": [],
      "required_posting_auths": [
        "sateeshkodati"
      ],
      "id": "follow",
      "json": "[\"reblog\",{\"account\":\"sateeshkodati\",\"author\":\"aggroed\",\"permlink\":\"craigslist-now-sorts-by-sellers-by-those-accepting-crypto-a-boon-to-crypto-enthusiasts-everywhere\"}]"
    }
  ]
}

{
  "trx_id": "6ee58488783a5d0051aaf66a1dd409c310df03e6",
  "block": 18028366,
  "trx_in_block": 26,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2017-12-12T18:49:09",
  "op": [
    "comment",
    {
      "parent_author": "sateeshkodati",
      "parent_permlink": "internet-protocols-are-changing",
      "author": "cheetah",
      "permlink": "cheetah-re-sateeshkodatiinternet-protocols-are-changing",
      "title": "",
      "body": "Hi! I am a robot. I just upvoted you! I found similar content that readers might be interested in:\nhttps://blog.apnic.net/2017/12/12/internet-protocols-changing/",
      "json_metadata": ""
    }
  ]
}

{
  "trx_id": "7e6ecca823e24f7b16bcbbb66833ea75db7852ba",
  "block": 18028365,
  "trx_in_block": 14,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2017-12-12T18:49:06",
  "op": [
    "vote",
    {
      "voter": "cheetah",
      "author": "sateeshkodati",
      "permlink": "internet-protocols-are-changing",
      "weight": 8
    }
  ]
}

{
  "trx_id": "108de1ee7638dcc8d37cc42298177c0286a29a96",
  "block": 18028358,
  "trx_in_block": 8,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2017-12-12T18:48:45",
  "op": [
    "comment",
    {
      "parent_author": "",
      "parent_permlink": "internet",
      "author": "sateeshkodati",
      "permlink": "internet-protocols-are-changing",
      "title": "Internet protocols are changing",
      "body": "When the Internet started to become widely used in the 1990s, most traffic used just a few protocols: IPv4 routed packets, TCP turned those packets into connections, SSL (later TLS) encrypted those connections, DNS named hosts to connect to, and HTTP was often the application protocol using it all.\n\nFor many years, there were negligible changes to these core Internet protocols; HTTP added a few new headers and methods, TLS slowly went through minor revisions, TCP adapted congestion control, and DNS introduced features like DNSSEC. The protocols themselves looked about the same ‘on the wire’ for a very long time (excepting IPv6, which already gets its fair amount of attention in the network operator community.)\n\nAs a result, network operators, vendors, and policymakers that want to understand (and sometimes, control) the Internet have adopted a number of practices based upon these protocols’ wire ‘footprint’ — whether intended to debug issues, improve quality of service, or impose policy.\n\nNow, significant changes to the core Internet protocols are underway. While they are intended to be compatible with the Internet at large (since they won’t get adoption otherwise), they might be disruptive to those who have taken liberties with undocumented aspects of protocols or made an assumption that things won’t change.\n\nWhy we need to change the Internet\n\nThere are a number of factors driving these changes.\n\nFirst, the limits of the core Internet protocols have become apparent, especially regarding performance. Because of structural problems in the application and transport protocols, the network was not being used as efficiently as it could be, leading to end-user perceived performance (in particular, latency).\n\nThis translates into a strong motivation to evolve or replace those protocols because there is a large body of experience showing the impact of even small performance gains.\n\nSecond, the ability to evolve Internet protocols — at any layer — has become more difficult over time, largely thanks to the unintended uses by networks discussed above. For example, HTTP proxies that tried to compress responses made it more difficult to deploy new compression techniques; TCP optimization in middleboxes made it more difficult to deploy improvements to TCP.\n\nFinally, we are in the midst of a shift towards more use of encryption on the Internet, first spurred by Edward Snowden’s revelations in 2015. That’s really a separate discussion, but it is relevant here in that encryption is one of best tools we have to ensure that protocols can evolve.\n\nLet’s have a look at what’s happened, what’s coming next, how it might impact networks, and how networks impact protocol design.\n\nHTTP/2\n\nHTTP/2 (based on Google’s SPDY) was the first notable change — standardized in 2015, it multiplexes multiple requests onto one TCP connection, thereby avoiding the need to queue requests on the client without blocking each other. It is now widely deployed, and supported by all major browsers and web servers.\n\nFrom a network’s viewpoint, HTTP/2 made a few notable changes. First, it’s a binary protocol, so any device that assumes it’s HTTP/1.1 is going to break.\n\nThat breakage was one of the primary reasons for another big change in HTTP/2; it effectively requires encryption. This gives it a better chance of avoiding interference from intermediaries that assume it’s HTTP/1.1, or do more subtle things like strip headers or block new protocol extensions — both things that had been seen by some of the engineers working on the protocol, causing significant support problems for them.\n\nHTTP/2 also requires TLS/1.2 to be used when it is encrypted, and blacklists cipher suites that were judged to be insecure — with the effect of only allowing ephemeral keys. See the TLS 1.3 section for potential impacts here.\n\nFinally, HTTP/2 allows more than one host’s requests to be coalesced onto a connection, to improve performance by reducing the number of connections (and thereby, congestion control contexts) used for a page load.\n\nFor example, you could have a connection for www.example.com, but also use it for requests for images.example.com. Future protocol extensions might also allow additional hosts to be added to the connection, even if they weren’t listed in the original TLS certificate used for it. As a result, assuming that the traffic on a connection is limited to the purpose it was initiated for isn’t going to apply.\n\nDespite these changes, it’s worth noting that HTTP/2 doesn’t appear to suffer from significant interoperability problems or interference from networks.\n\nTLS 1.3\n\nTLS 1.3 is just going through the final processes of standardization and is already supported by some implementations.\n\nDon’t be fooled by its incremental name; this is effectively a new version of TLS, with a much-revamped handshake that allows application data to flow from the start (often called ‘0RTT’). The new design relies upon ephemeral key exchange, thereby ruling out static keys.\n\nThis has caused concern from some network operators and vendors — in particular those who need visibility into what’s happening inside those connections.\n\nFor example, consider the datacentre for a bank that has regulatory requirements for visibility. By sniffing traffic in the network and decrypting it with the static keys of their servers, they can log legitimate traffic and identify harmful traffic, whether it be attackers from the outside or employees trying to leak data from the inside.\n\nTLS 1.3 doesn’t support that particular technique for intercepting traffic, since it’s also a form of attack that ephemeral keys protect against. However, since they have regulatory requirements to both use modern encryption protocols and to monitor their networks, this puts those network operators in an awkward spot.\n\nThere’s been much debate about whether regulations require static keys, whether alternative approaches could be just as effective, and whether weakening security for the entire Internet for the benefit of relatively few networks is the right solution. Indeed, it’s still possible to decrypt traffic in TLS 1.3, but you need access to the ephemeral keys to do so, and by design, they aren’t long-lived.\n\nAt this point it doesn’t look like TLS 1.3 will change to accommodate these networks, but there are rumblings about creating another protocol that allows a third party to observe what’s going on— and perhaps more — for these use cases. Whether that gets traction remains to be seen.\n\nQUIC\n\nDuring work on HTTP/2, it became evident that TCP has similar inefficiencies. Because TCP is an in-order delivery protocol, the loss of one packet can prevent those in the buffers behind it from being delivered to the application. For a multiplexed protocol, this can make a big difference in performance.\n\nQUIC is an attempt to address that by effectively rebuilding TCP semantics (along with some of HTTP/2’s stream model) on top of UDP. Like HTTP/2, it started as a Google effort and is now in the IETF, with an initial use case of HTTP-over-UDP and a goal of becoming a standard in late 2018. However, since Google has already deployed QUIC in the Chrome browser and on its sites, it already accounts for more than 7% of Internet traffic.\n\nRead Your questions answered about QUIC\n\nBesides the shift from TCP to UDP for such a sizable amount of traffic (and all of the adjustments in networks that might imply), both Google QUIC (gQUIC) and IETF QUIC (iQUIC) require encryption to operate at all; there is no unencrypted QUIC.\n\niQUIC uses TLS 1.3 to establish keys for a session and then uses them to encrypt each packet. However, since it’s UDP-based, a lot of the session information and metadata that’s exposed in TCP gets encrypted in QUIC.\n\nIn fact, iQUIC’s current ‘short header’ — used for all packets except the handshake — only exposes a packet number, an optional connection identifier, and a byte of state for things like the encryption key rotation schedule and the packet type (which might end up encrypted as well).\n\nEverything else is encrypted — including ACKs, to raise the bar for traffic analysis attacks.\n\nHowever, this means that passively estimating RTT and packet loss by observing connections is no longer possible; there isn’t enough information. This lack of observability has caused a significant amount of concern by some in the operator community, who say that passive measurements like this are critical for debugging and understanding their networks.\n\nOne proposal to meet this need is the ‘Spin Bit‘ — a bit in the header that flips once a round trip, so that observers can estimate RTT. Since it’s decoupled from the application’s state, it doesn’t appear to leak any information about the endpoints, beyond a rough estimate of location on the network.\n\nDOH\n\nThe newest change on the horizon is DOH — DNS over HTTP. A significant amount of research has shown that networks commonly use DNS as a means of imposing policy (whether on behalf of the network operator or a greater authority).\n\nCircumventing this kind of control with encryption has been discussed for a while, but it has a disadvantage (at least from some standpoints) — it is possible to discriminate it from other traffic; for example, by using its port number to block access.\n\nDOH addresses that by piggybacking DNS traffic onto an existing HTTP connection, thereby removing any discriminators. A network that wishes to block access to that DNS resolver can only do so by blocking access to the website as well.\n\nFor example, if Google was to deploy its public DNS service over DOH on www.google.com and a user configures their browser to use it, a network that wants (or is required) to stop it would have to effectively block all of Google (thanks to how they host their services).\n\nDOH has just started its work, but there’s already a fair amount of interest in it, and some rumblings of deployment. How the networks (and governments) that use DNS to impose policy will react remains to be seen.\n\nRead IETF 100, Singapore: DNS over HTTP (DOH!)\n\nOssification and grease\n\nTo return to motivations, one theme throughout this work is how protocol designers are increasingly encountering problems where networks make assumptions about traffic.\n\nFor example, TLS 1.3 has had a number of last-minute issues with middleboxes that assume it’s an older version of the protocol. gQUIC blacklists several networks that throttle UDP traffic, because they think that it’s harmful or low-priority traffic.\n\nWhen a protocol can’t evolve because deployments ‘freeze’ its extensibility points, we say it has ossified. TCP itself is a severe example of ossification; so many middleboxes do so many things to TCP — whether it’s blocking packets with TCP options that aren’t recognized, or ‘optimizing’ congestion control.\n\nIt’s necessary to prevent ossification, to ensure that protocols can evolve to meet the needs of the Internet in the future; otherwise, it would be a ‘tragedy of the commons’ where the actions of some individual networks — although well-intended — would affect the health of the Internet overall.\n\nThere are many ways to prevent ossification; if the data in question is encrypted, it cannot be accessed by any party but those that hold the keys, preventing interference. If an extension point is unencrypted but commonly used in a way that would break applications visibly (for example, HTTP headers), it’s less likely to be interfered with.\n\nWhere protocol designers can’t use encryption and an extension point isn’t used often, artificially exercising the extension point can help; we call this greasing it.\n\nFor example, QUIC encourages endpoints to use a range of decoy values in its version negotiation, to avoid implementations assuming that it will never change (as was often encountered in TLS implementations, leading to significant problems).\n\nNaviate to following Url to read more https://blog.apnic.net/2017/12/12/internet-protocols-changing/\n\nSource:  Hacker news, https://blog.apnic.net/2017/12/12/internet-protocols-changing/",
      "json_metadata": "{\"tags\":[\"internet\",\"protocols\"],\"links\":[\"https://blog.apnic.net/2017/12/12/internet-protocols-changing/\"],\"app\":\"steemit/0.1\",\"format\":\"markdown\"}"
    }
  ]
}

{
  "trx_id": "15c48115f658ff2100a08c2227458ea1e7fe2a71",
  "block": 18028313,
  "trx_in_block": 19,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2017-12-12T18:46:30",
  "op": [
    "vote",
    {
      "voter": "saimon1971",
      "author": "sateeshkodati",
      "permlink": "internet-protocols-are-changing",
      "weight": 10000
    }
  ]
}

{
  "trx_id": "8766072acaa86eadd33248c405e9585fe143ac9a",
  "block": 18028277,
  "trx_in_block": 3,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2017-12-12T18:44:42",
  "op": [
    "comment",
    {
      "parent_author": "sateeshkodati",
      "parent_permlink": "internet-protocols-are-changing",
      "author": "gordonramsay",
      "permlink": "re-sateeshkodati-internet-protocols-are-changing-20171212t185158889z",
      "title": "",
      "body": "https://i.imgur.com/X7XfISK.png\nGet your post resteemed over 90000+ followers and get upto $19+ value Upvote. Your post will skyrocket and give you maximum exposer. \n\n> Send 1 SBD or Steem with your post url you will get your post share over 30000+ followers and 1 upvote $1.5+ value.\n\n> Send 2 SBD or Steem with your post url you will get your post share over 30000+ followers and 1 upvote $3+ value.\n\n> Send 3 SBD or Steem with your post url you will get your post share over 60000+ followers and 1 upvote $5+ value.\n\n> Send 5 SBD or Steem with your post url you will get your post share over 90000+ followers and 1 upvote $9+ value.\n\nSee our all pakages at: http://www.whaleboostup.ml",
      "json_metadata": "{\"tags\":[\"internet\"],\"community\":\"busy\",\"app\":\"busy/2.1.0\"}"
    }
  ]
}

{
  "trx_id": "f8a1c2c2cb4f56c022444e8737ebbb670e4bb67a",
  "block": 18028261,
  "trx_in_block": 5,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2017-12-12T18:43:54",
  "op": [
    "transfer",
    {
      "from": "hottopic",
      "to": "sateeshkodati",
      "amount": "0.001 STEEM",
      "memo": "Hello sateeshkodati. I Followed you.If you follow me, I'll be happy.Thanks :)"
    }
  ]
}

{
  "trx_id": "575c3b6299dea7cc7b8985d77c5d341fa084b35a",
  "block": 18028255,
  "trx_in_block": 4,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2017-12-12T18:43:36",
  "op": [
    "comment",
    {
      "parent_author": "",
      "parent_permlink": "internet",
      "author": "sateeshkodati",
      "permlink": "internet-protocols-are-changing",
      "title": "Internet protocols are changing",
      "body": "https://blog.apnic.net/2017/12/12/internet-protocols-changing/",
      "json_metadata": "{\"tags\":[\"internet\",\"protocols\"],\"links\":[\"https://blog.apnic.net/2017/12/12/internet-protocols-changing/\"],\"app\":\"steemit/0.1\",\"format\":\"markdown\"}"
    }
  ]
}

{
  "trx_id": "84dc16159af7ea2f56bbdc1cf9234d536a335799",
  "block": 18028025,
  "trx_in_block": 0,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2017-12-12T18:32:06",
  "op": [
    "account_update",
    {
      "account": "sateeshkodati",
      "memo_key": "STM69xHB5bKrTpJvchujQL1VVfgHJcQ1A2eBgKYzyWLKrZLjwcX4G",
      "json_metadata": "{\"profile\":{\"profile_image\":\"https://media.licdn.com/mpr/mpr/shrinknp_400_400/AAEAAQAAAAAAAAe8AAAAJDNmZjI4OWJkLTdmYzAtNDU0Ny04YjllLTBkYWM0NDA4ZTBiNA.jpg\",\"name\":\"Sateesh Kdoati\",\"about\":\"Technology evangelist | Software Engineer\"}}"
    }
  ]
}

{
  "trx_id": "ef7d6ec413120037bc48bc52cce43809ba197920",
  "block": 16298697,
  "trx_in_block": 6,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2017-10-13T16:25:45",
  "op": [
    "delegate_vesting_shares",
    {
      "delegator": "steem",
      "delegatee": "sateeshkodati",
      "vesting_shares": "29827.741980 VESTS"
    }
  ]
}

{
  "trx_id": "f6d66a84fa49e1351457b0f2f1a52486df1e53d3",
  "block": 13892566,
  "trx_in_block": 6,
  "op_in_trx": 0,
  "virtual_op": 0,
  "timestamp": "2017-07-22T01:20:45",
  "op": [
    "account_create_with_delegation",
    {
      "fee": "0.500 STEEM",
      "delegation": "57000.000000 VESTS",
      "creator": "steem",
      "new_account_name": "sateeshkodati",
      "owner": {
        "weight_threshold": 1,
        "account_auths": [],
        "key_auths": [
          [
            "STM6cJQWPqTvpkhoMq5LgHVutagWFsATMArXBGXPCFZQuPgABdThF",
            1
          ]
        ]
      },
      "active": {
        "weight_threshold": 1,
        "account_auths": [],
        "key_auths": [
          [
            "STM6ic5xNJ4r9hSW9rjuYPkQNWUfKQv7LuGbBF3bfrXXMXhEPKtzi",
            1
          ]
        ]
      },
      "posting": {
        "weight_threshold": 1,
        "account_auths": [],
        "key_auths": [
          [
            "STM6usX2Js6mMXMiVGPMNK1a183hYqBpq3jCpU1QtVQGRBAQvn4B2",
            1
          ]
        ]
      },
      "memo_key": "STM69xHB5bKrTpJvchujQL1VVfgHJcQ1A2eBgKYzyWLKrZLjwcX4G",
      "json_metadata": "",
      "extensions": []
    }
  ]
}