I want to host my documentation on ReadTheDoc because.... it's great.
Problem my repository use Google Earth Engine as a dependancy. This lib require a manual authentification or an authentification through a private key.
Is it possible to use private key in ReadTheDoc ? (in Json or string format)
In the RTD administration panel of your repository go to "Environment Variables". there you will be able to add as many env keys as you fancy.
note that once set, the key will not be publicly displayed to you or any other maintainer for security reasons obviously
Troubleshooting
As referenced in this issue if your key is bigger than 2048 characters, it will not be managed by RDT. In this case encrypt your key in a file inside your repository and add the decoding key as an environment variable in RDT.
Related
We're trying to troubleshoot a situation where some files sent to us can be successfully decrypted on the command line using GPG but not in a GUI program that interfaces with that library. The error reported by the GUI program is "the key is not marked for encryption". What does it mean for a key to be "marked" for encryption? When is that marking done? When the key is first created, or later, when the key is used to encrypt a file?
I have a key in my KV store, let's say /global/test/my-key and I use a token that has the following policy :
key "/global/test/my-key" {
policy = "read"
}
Why, using the UI, I can access the URL http://localhost:8500/v1/kv/global/test/my-key/edit but I have a 403 on the following URLs http://localhost:8500/v1/kv/global/test and http://localhost:8500/v1/kv/global ?
Is there a way for me to access my key from the UI starting at the URL http://localhost:8500/v1/kv ?
NOTE: I have tried the "list" policy, but it gives read access to the other keys, which is not what I want.
EDIT: I just realized I had forgot to mention another condition that I am trying to meet. I have another key called for instance /global/secret/my-other-key and I don't want that key to be viewed from the UI nor the folder /global/secret/.
If you wish to have access to all of the mentioned paths, you should use this policy instead:
key_prefix "global" {
policy = "read"
}
This policy will give you access to global and any "sub-paths" of it.
Consul does not currently support performing recursive reads on paths where your token only has access to a subset of the keys under that parent path.
There's an open GitHub issue requesting this functionality be added https://github.com/hashicorp/consul/issues/4513. I recommend upvoting that issue to indicate your interest, and subscribe to it for updates so that you can track its progress.
If your particular use case is not accurately reflected in the initial description, feel free to leave a comment with additional information.
I am building my Jekyll site with Algolia search.
The documentation about jekyll-algolia says the admin key must be provided in the environment variable ALGOLIA_API_KEY.
However, another page about API key security says
Your admin API key is the most sensitive key: it provides full control of all your indices and data. The admin API key should always be kept secure. Do NOT release it to anybody or do NOT use it in any application, and always create a new key that will be more restrictive. This API key should almost exclusively be used to generate other - more limited - API Keys that will then be used to search and perform indexing operations.
Reading the second page, I'm trying to create a more restrictive key for use with jekyll-algolia in CI builds of my Jekyll website:
However I still get complaints from bundle exec jekyll algolia:
ibug#ubuntu:~/iBug.github.io$ ALGOLIA_API_KEY="0123456789abcdef0123456789abcdef" bundle exec jekyll algolia
Configuration file: /home/wsl/iBug.github.io/_config.yml
Processing site...
AutoPages: Disabled/Not configured in site.config.
Pagination: Complete, processed 1 pagination page(s)
Jekyll Feed: Generating feed for posts
GitHub Metadata: No GitHub API authentication could be found. Some fields may be missing or have incorrect data.
Extracting records...
Updating records in index iBug_website...
Records to delete: 428
Records to add: 420
[✗ Error] Invalid credentials
The jekyll-algolia plugin could not connect to your application ID using the
API key your provided.
Make sure your API key has access to your 14DZKASAEJ application.
You can find your API key in your Algolia dashboard here:
https://www.algolia.com/licensing
ibug#ubuntu:~/iBug.github.io$ echo $?
1
How should I do that? Or must I provide the admin key in CI environments?
Minimum API key ACLs required to allow indexing with jekyll-algolia are deleteIndex, addObject, deleteObject and 'editSettings`.
If one of those ACLs is not set you get an error like this :
[jekyll-algolia] Error:
403: Cannot PUT to
https://APP_ID.algolia.net/1/indexes/your_folder/settings:
{"message":"Method not allowed with this API key","status":403} (403)
In your case, the error message indicates that your application ID is not connected with the API_KEY you provide.
Check your application ID in your Algolia dashboard, and verify that you have a correct algolia.application_id entry in your _config.yml.
If you provide the right application_id and one of her API key, it must work, otherwise it's an Algolia problem.
When configuring and installing an EOS blockchain, you're required to use the "eosio" account as the block producing account or blocks aren't signed. I haven't been able to find much info. however about this pseudo account as it appears to come w/the software by default.
From EOSIO documentation, the "eosio" account is an authorizing account, used to bootstrap EOSIO nodes. But is it stored someplace, or just the default "root" account for EOS blockchains?
You even use this account to create new accounts.
My question is, where is its private key? Is this the key set in the genesis.json file? Can I use another account to configure my blockchain? I would imagine so b/c you specify it at the cmd. line, otherwise the parameter wouldn't be needed.
I'm just frustrated by the lack of documentation surrounding EOS and kindly request help from the community.
UPDATE: 7/13/2018
I changed the "producer-name" to another value but then the blockchain doesn't sign transactions and it sits idle. This is why I'm confused about "eosio." Its key is configured in the config.ini but it doesn't appear that you can change the "producer-name," which is fine, but then why have a "-p" cmd. line parameter? It's just not making sense to me.
its private key is stored at config.ini
# Tuple of [public key, WIF private key] (may specify multiple times) (eosio::producer_plugin)
private-key = ["EOS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV","5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3"]
The second value is the private key.
In addition I think that you can use another account to configure your blockchain . EOSIO is just the testing account .
So i suppose that you can use another block producer if you use another producer name and account with different keys at config.ini
Check this : https://medium.com/coinmonks/test-4fbd38fdc4e8 chapter 4
As I understand when using web3.eth.accounts.create(), it doesn't add the account to chain (I'm using ganache-cli for testing), but web3.eth.personal.newAccount() does.
Is it the main purpose or is it a bug?
Is there other differences?
web3.js version: 1.0.0-beta.34
Both versions create a new account on the blockchain. The difference is how you interact with the node and having access to the private key. If you have a local node, you can use web3.eth.accounts.create which will create the account and provide you access to the private key generate so it can be stored locally. However, since returning the private key over a connection isn’t secure, you should never use this approach to create an account if you connect through a provider like Infura.
On the other hand, you can use web3.eth.personal to create a new account on a remote node. In this case, the private key will not be returned to you, so you lose some flexibility with accessing your account. When you don’t have the private key, you can’t sign transactions locally. In order to run transactions, you have to call unlockAccount on the remote node. Note that you have to send your password to create/unlock your account using web3.eth.personal, so you still need to make sure you using a secure connection.
Review this Medium blog post for additional info.