I'm sorry if this is obvious, but I can't figure out what this key is!
{
"type": "file",
"encoding": "base64",
"size": 5362,
"name": "README.md",
"path": "README.md",
"content": "encoded content ...",
"sha": "3d21ec53a331a6f037a91c368710b99387d012c1", <<THIS KEY>>
"url": "https://api.github.com/repos/octokit/octokit.rb/contents/README.md",
"git_url": "https://api.github.com/repos/octokit/octokit.rb/git/blobs/3d21ec53a331a6f037a91c368710b99387d012c1",
"html_url": "https://github.com/octokit/octokit.rb/blob/master/README.md",
"download_url": "https://raw.githubusercontent.com/octokit/octokit.rb/master/README.md",
"_links": {
"git": "https://api.github.com/repos/octokit/octokit.rb/git/blobs/3d21ec53a331a6f037a91c368710b99387d012c1",
"self": "https://api.github.com/repos/octokit/octokit.rb/contents/README.md",
"html": "https://github.com/octokit/octokit.rb/blob/master/README.md"
}
}
I marked the key with <> to help.
https://developer.github.com/v3/repos/contents/#get-contents
That's the hash for the given blob, which is how Git represents files internally. It's common knowledge that commits have hashes, but so do all other Git objects:
Git is a content-addressable filesystem. Great. What does that mean? It means that at the core of Git is a simple key-value data store. You can insert any kind of content into it, and it will give you back a key that you can use to retrieve the content again at any time.
Trees, commits, and tags are the other types of Git objects.
To generate the hash of a file manually you can use the hash-object plumbing command:
$ git hash-object README.md
3d21ec53a331a6f037a91c368710b99387d012c1
Any1 change to the file's content will change the hash, but it is not dependent on the file's name, or permissions.
1As with all cryptographic hashes, duplicate hashes are possible but extremely unlikely.
Related
There is a transaction on RSK Testnet,
0xf3b1d43850523d45b4c84c5098ff0cf6bb74d1eb350b9574315433544f990390,
where tx.to is the zero address,
and tx.data is also zero.
However, it shows that this was a deployment transaction,
and that a contract was created at this address.
It seems like (instead of a contract deployment)
this should be a "burn" transaction,
where RBTC is sent to the zero address.
How is this possible, and how does this work?
Additional detail, eth_getTransactionByHash:
$ curl https://public-node.testnet.rsk.co -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_getTransactionByHash","params":["0xf3b1d43850523d45b4c84c5098ff0cf6bb74d1eb350b9574315433544f990390"],"id":1}' | jq
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"hash": "0xf3b1d43850523d45b4c84c5098ff0cf6bb74d1eb350b9574315433544f990390",
"nonce": "0xdbd",
"blockHash": "0x0ecc95ab88bb1d72e8d83d015e9e31e65230c3035809db4476a28e56d22ef11c",
"blockNumber": "0x12f7d9",
"transactionIndex": "0xe",
"from": "0x1bb2b1beeda1fb25ee5da9cae6c0f12ced831128",
"to": null,
"gas": "0x186a0",
"gasPrice": "0x3dfd242",
"value": "0x1558df2903f400",
"input": "0x",
"v": "0x61",
"r": "0x976033c43bed3a37cde8808bcf32930d396f3c035d8fe21246dd8ef9dbade200",
"s": "0x3777a1fa46829fe8fbb976b464ccccb3d2d2c255379bbf878efcbb5140351fcd"
}
}
"from": "0x1bb2b1beeda1fb25ee5da9cae6c0f12ced831128",
"to": null,
"value": "0x1558df2903f400",
"input": "0x",
Additional detail, eth_getTransactionByHash:
$ curl https://public-node.testnet.rsk.co -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_getTransactionReceipt","params":["0xf3b1d43850523d45b4c84c5098ff0cf6bb74d1eb350b9574315433544f990390"],"id":1}' | jq
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"transactionHash": "0xf3b1d43850523d45b4c84c5098ff0cf6bb74d1eb350b9574315433544f990390",
"transactionIndex": "0xe",
"blockHash": "0x0ecc95ab88bb1d72e8d83d015e9e31e65230c3035809db4476a28e56d22ef11c",
"blockNumber": "0x12f7d9",
"cumulativeGasUsed": "0xd1f15",
"gasUsed": "0xcf08",
"contractAddress": "0x3c9c7b9f43ad1ffe46beb4f58232157fb26f88c0",
"logs": [],
"from": "0x1bb2b1beeda1fb25ee5da9cae6c0f12ced831128",
"to": null,
"status": "0x1",
"logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
}
}
Relevant parts
"contractAddress": "0x3c9c7b9f43ad1ffe46beb4f58232157fb26f88c0",
"logs": [],
"from": "0x1bb2b1beeda1fb25ee5da9cae6c0f12ced831128",
"to": null,
"status": "0x1",
A contract without code is simply an account that was created by CREATE or CREATE2,
but without specifying any data to put as initializer (which is the piece of code that when executed returns the code to install in the contract).
When this happens, an empty smart contract is deployed.
In RSK, contracts are identified internally when they have a "storage node root" in the trie. Every time a contract is deployed (with empty code or not), the storage root node is created in the RSK trie below the account node.
RSK internally does not identify contracts when they have code or not.
Note that this is a difference in the RSK consensus when compared to Ethereum consensus.
This consensus difference is reflected in
RSKj network node,
which is different from geth (Ethereum most used network node).
When RSK creates an account, it creates a small portion of the trie that stores the storage data (even if there is no data yet). RSK pre-creates a single node in the storage trie (a very compact one, storing a single byte). This dummy node has several purposes. One is to be able to easily compute the storage size, or the storage hash digest (both fields are embedded in the node).
When you call isContract() in the code, the RSK node looks for this "dummy" storage root node and returns true if it is present.
It does not check the existence of non-empty code.
Additional notes regarding smart contracts and isContract():
Currently isContract() is not called by consensus code except by the CODEHASH opcode, and CODEHASH returns the same result (KECCAK_256_OF_EMPTY_ARRAY) if the code is empty, and if isContract() returns false, so we may say that alternate definition of isContract() has no "visible" consequences from outside the node (i.e. by performing Web3-RPC calls). The RSK node behaves exactly as the Ethereum node.
However it was called by consensus code prior the CODEHASH opcode was fixed, as specified in RSKIP-169 "Rectify EXTCODEHASH implementation". Therefore there may have been visible consequences of isContract() in blocks before RSKIP-169 was activated.
Can I disable login for a particular CouchDB user while leaving their user doc in the authentication database?
This question is similar to How to temporarily disable particular user in couchdb?, but in that case the actual question was how to "temporarily disable particular user read/write access" [emphasis mine].
What I am trying to do is to completely prevent a user from login until a password is set.
The behavior isn't necessarily guaranteed by the CouchDB maintainers in the future, but inspired by the Unix password lockout feature it seems possible to do this in practice by replacing at least the derived_key field with a bogus value like "*" or "!".
For example, this user could login in by providing a certain password:
{
"_id": "org.couchdb.user:test",
"name": "test",
"roles": [],
"type": "user",
"password_scheme": "pbkdf2",
"iterations": 10,
"derived_key": "e7666ce1536488d8c0ceb2b2e9baf25d83e1d720",
"salt": "8b7ea88d05181c77553169354decb0b7"
}
By replacing the scheme-relevant fields with garbage data, the user is no longer able to log in while the CouchDB logs do not register any particular upset/crash:
{
"_id": "org.couchdb.user:test",
"name": "test",
"roles": [],
"type": "user",
"password_scheme": "pbkdf2",
"iterations": 10,
"derived_key": "!",
"salt": "-some other random nonce-"
}
I have not completely confirmed, though, how this gets handled inside of CouchDB. My read of the authenticate logic and how it interacts with the its pbkdf2 implementation is that the stored derived_key is compared as a raw byte string to the re-calculated one and thus there would be no way to generate a collision. So this should always disable the account. (As opposed to a situation where, say, the stored "!" is optimistically expected to be hex of a certainly length and gets quietly "coerced" to a buffer of all zeroes in any case where parsing fails or something…then it might be possible to find an input password such that the result looks correct. Leaving the salt set to a new random-but-valid nonce value would presumably keep a bypass like that prohibitive in practice.)
I'm trying to get the result sorted by the posting date for which i have defined an index
{
"index": {
"fields": [{
"PostingDate": "DESC"
}]
},
"ddoc": "indexPostingDate",
"name": "indexPostingDate",
"type": "json"
}
Acc to the hyperledger fabric documentation i have to place this in META-INF/statedb/couchdb/indexes
With Sap hyperledger fabric platform i tried placing this folder both in vendor folder as well as directly under src folder.But none worked for me.
This is my code for querying result
queryString := fmt.Sprintf("{\"selector\":{\"id\":\"%s\"},\"sort\": [{\"PostingDate\": \"desc\"}],\"use_index\": \"indexPostingDate\"}",
id)
logger.Infof("Getting data for %s", id)
oResultsIterator, responseMetaData, oFetchErr := stub.GetQueryResultWithPagination(queryString,
pageSize, bookmark)
On invoking this function, i get this following error
{
"error": {
"message": "GET_QUERY_RESULT failed: transaction ID: 9b7c42c09069855758ccdfbc30f5d75d38b51569a78e101584051e0fa142ebc3: error handling CouchDB request. Error:no_usable_index, Status Code:400, Reason:No index exists for this sort, try indexing by the sort fields.",
"code": "CustomError",
"status": 500
}
}
How do i resolve this?
It's a known limitation that you can't specify the sort direction in the Query with Fabric. If you need an ordered search, your index creation should specify the direction, so you can simply exclude it in your query.
Now that we support and recommend you use the official CouchDB:3.1, this may work, but I would need to test it.
You can simplify your query by the way by using backticks so you don't have to escape your quotes for ease of reading and writing: fmt.Sprintf(`{"selector":{"id":"%s"},"sort": [{"PostingDate": "desc"}],"use_index": "indexPostingDate"}`, id)
I'm using wit ai for a bot and I think it's amazing. However, I must provide the customer with screens in my web app to train and manage the app. And here I found a big problem (or maybe I'm just lost). The documentation of the REST API is not enough to design a client that acts like the wit console (not even close). it's like a tutorial of what endpoints you can hit and an overview of the parameters, but no clean explanation of the structure of the response.
For example, there is no endpoint to get the insights edge. Also and most importantly, no clear documentation about the response structure when hitting the message endpoints (i.e. the structure the returned entities: are they prebuilt or not, and if they are, is the value a string or an object or array, and what the object might contain [e.g. datetime]). Also the problem of the deprecated guide and the new guide (the new guide should be done and complete by now). I'm building parts of the code based on my testing. Sometimes when I test something new (like adding a range in the datetime entity instead of just a value), I get an error when I try to set the values to the user since I haven't parsed the response right, and the new info I get makes me modify the DB structure at my end sometimes.
So, the bottom line, is there a complete reference that I can implement a complete client in my web app (my web app is in Java by the way and I couldn't find a client library that handles the latest version of the API)? Again, the tool is AWESOME but the documentation is not enough, or maybe I'm missing something.
The document is not enough of course but I think its pretty straightforward. And from what I read there is response structure under "Return the meaning of a sentence".
It's response in JSON format. So you need to decode the response first.
Example Request:
$ curl -XGET 'https://api.wit.ai/message?v=20170307&q=how%20many%20people%20between%20Tuesday%20and%20Friday' \
-H 'Authorization: Bearer $TOKEN'
Example Response:
{
"msg_id": "387b8515-0c1d-42a9-aa80-e68b66b66c27",
"_text": "how many people between Tuesday and Friday",
"entities": {
"metric": [ {
"metadata": "{'code': 324}",
"value": "metric_visitor",
"confidence": 0.9231
} ],
"datetime": [ {
"value": {
"from": "2014-07-01T00:00:00.000-07:00",
"to": "2014-07-02T00:00:00.000-07:00"
},
"confidence": 1
}, {
"value": {
"from": "2014-07-04T00:00:00.000-07:00",
"to": "2014-07-05T00:00:00.000-07:00"
},
"confidence": 1
} ]
}
}
You can read more about response structure under Return the meaning of a sentence
I'm getting set up with CouchDB on Cloudant, and I'm confused because Cloudant seems to do auth differently than regular CouchDB. Specifically, Cloudant seems to lack a _users database.
I read the Cloudant auth FAQ here, and it provided the following instructions:
Can I use CouchDB security features (_users database, security
objects, validation functions) on Cloudant?
Yes you can. If you want
to use the _users database you must first turn off Cloudant's own
security for the roles you want to manage via _users. To do this you
need to PUT a JSON document like the following to the _security
endpoint of the database (for example
https://USERNAME.cloudant.com/DATABASE/_security):
{ "cloudant": {
"nobody": ["_reader", "_writer", "_admin"] }, "readers": {
"names":["demo"],"roles":[] } }
These instructions worked fine, and allowed me to update the _security object of a database.
What wasn't clear was how to set up the _users database. It didn't exist automatically, so I tried creating it using a regular:
curl -X PUT $COUCH/_users
This worked fine, but when I attempt to add a new user to _users as follows:
curl -HContent-Type:application/json \
-vXPUT $COUCH/_users/org.couchdb.user:me \
--data-binary '{"_id": "org.couchdb.user:me","name": "me","roles": [],"type": "user","password": "pwd"}'
It appears to create the document correctly:
{"ok":true,"id":"org.couchdb.user:me","rev":"3-86c3801fdb8c32331f5f2580e861a765"}
But the new user in _users on Cloudant lacks a hashed password:
{
"_id": "org.couchdb.user:me",
"_rev": "3-86c3801fdb8c32331f5f2580e861a765",
"name": "me",
"roles": [
],
"type": "user",
"password": "pwd"
}
So when I attempt to authenticate at this user, I get the following error:
{"error":"bad_request","reason":"missing password_sha property in user doc"}
On my local CouchDB installation, creating a new user in _users would automatically create the hashed password:
{
"_id": "org.couchdb.user:test",
"_rev": "1-9c1c4360eba168468a37d7f623782d23",
"password_scheme": "pbkdf2",
"iterations": 10,
"name": "test",
"roles": [
],
"type": "user",
"derived_key": "4a122a20c1a8fdddb5307c29078e2c4269abffa5",
"salt": "36c0c05cf2a3ee321eabd10c46a8aa2a"
}
I tried copying the "_design/_auth" document from my local CouchDB installation to Cloudant, but the results are the same - no hashed password.
I appear to have gone off the rails at some point, but I'm not sure where this happened. How can I set up Cloudant to use the same kind of auth as regular CouchDB?
I found the answer via #cloudant IRC:
09:59 <+kocolosk> creating _users was the right thing to do
09:59 <+kocolosk> the API matches an older version of CouchDB where the passwords needed to hashed client-side
10:00 < jbeard> oh, I see
10:00 <+kocolosk> we're addressing that lack of support for automatic hashing
10:01 < jbeard> I'm trying to find documentation on client-side hashing in Couch.
10:02 < jbeard> What version of Couch is Cloudant aiming to be compatible with for _users?
10:04 <+kocolosk> jbeard: http://wiki.apache.org/couchdb/Security_Features_Overview
10:04 <+kocolosk> see "Generating password_sha (only applicable for 1.1.x and earlier)"
10:04 <+kocolosk> jbeard: this particular feature is the last bit where we are compatible with 1.1.x but not newer version
10:05 < jbeard> Excellent
10:05 < jbeard> That's what I needed to know
In fact, cloudant does not support the hash value generation.
I found this alternative that helps to use the _users db in the cloudant service...
https://github.com/doublerebel/cloudant-user
As of 2020, Cloudant hashes the password but doesn't use the same hashing algorithm as CouchDB currently does (pbkdf2). For better security and compatibilty, it is still advisable to generate the hash yourselves, e.g. with couch-pwd.
And instead of supplying
{ "cloudant": { "nobody": ["_reader", "_writer", "_admin"] }, "readers": { "names":["demo"],"roles":[] } }
The docs now suggest the couchdb_auth_only flag:
{
"couchdb_auth_only": true,
"members": {
"names": ["demo"],"roles":[]
},
"admins": {
"names": ["admin"],"roles":[]
}
}
But mind that the _admin role is not set automatically as in CouchDB 3.