| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Replace couch_js with ateles
|
| | |
|
| |
|
|
|
|
| |
Fixes this warning:
couchdb/src/couch_eval/src/couch_eval.erl:168: Warning: this clause cannot match because a previous clause at line 167 always matches
|
| |
|
|
|
|
| |
Use couch_eval when filtering docs with a filter function or a map
function. This allows CouchDB to configured to use different engines
through couch_eval.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Port ba638783b5d87b855939dae69fd63ffd41cb5ed7 from 3.x
This should fix the edge case where deletion with a bad rev was returning a
404. Now it should returna 409.
Issue: https://github.com/apache/couchdb/issues/2146
|
| |
|
|
| |
This eliminates several warnings when running `make exunit`.
|
| |
|
|
|
|
|
|
|
| |
Add a `js_engine` field when starting test applications.
When the couch apps are loaded it will load the js engine defined
in the ini files.
This allows us to swop out and use different javascript engines for
`couch_eval` for eunit tests.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
This is a port of
https://github.com/apache/couchdb/pull/3424/commits/a8622f0cca40d8f2338ec24b40f14d013a0f69d4
to main
Issue #3424
|
| |
|
|
|
|
|
|
| |
Fixes:
```
warning: unknown compiler variable "___MODULE__" (expected one of __MODULE__, __ENV__, __DIR__, __CALLER__, __STACKTRACE__)
src/couchdb/test/elixir/lib/step/start.ex:62: Couch.Test.Setup.Step.Start.teardown/2
```
|
| | |
|
| |\
| |
| | |
Remove case sensitivity for basic auth
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
This is a port of the 3.x PR https://github.com/apache/couchdb/pull/3634 to main
|
| |/ |
|
| |
|
|
|
| |
* Format all src files and remove beam comparison
* Apply make erlfmt-format
|
| | |
|
| | |
|
| |\
| |
| | |
Normalize config options main
|
| |/ |
|
| |
|
|
|
| |
This URL is a 404 now, but fortunately we don't care as
foundationdb.org is no longer dependent on GeoTrust at all in its
root of trust.
|
| |
|
|
|
|
|
| |
Previously, in 4.4.2-4 ibrowse upstream rebase also included the commit which
unconditionally unquoted userinfo credentials. Since we know have a better way
of handing basic auth creds bump ibrowse with a rebase which doesn't include
that commit.
|
| |
|
|
|
| |
* mochiweb : upgrade crypto functions to support OTP 23+
* ibrowse : update time functions and fix flaky unit test
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts the update to ibrowse to always unquote userinfo
(username and password) in endpoint URLs, as it has issues with
compatibility since it would unqoute passwords which had a literal '+'
as ' ' for example.
There is a new recommended way of specifying passwords which may
contain '@', ':' and other such symbols in
https://github.com/apache/couchdb/commit/1860ebbf2fa1731a62f3c9b107b2e52811489c1e.
Issue: https://github.com/apache/couchdb/issues/2892
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a port of commit ecd266b0e87f44e1080cabdb4c28e4758f5a4406 from 3.x to
main. Including the same commit message from there for completeness and then
towards the end, there is a description of changes required to port the PR to
main.
Previously, there were two ways to pass in basic auth credentials for endpoints
-- using URL's userinfo part, and encoding them in an `"Authorization": "basic
..."` header. Neither one is ideal for these reasons:
* Passwords in userinfo don't allow using ":", "@" and other characters.
However, even after switching to always unquoting them like we did recently
[1], it could break authentication for usernames or passwords previously
containing "+" or "%HH" patterns, as "+" might now be decoded to a " ".
* Base64 encoded headers need an extra step to encode them. Also, quite often
these encoded headers are confused as being "encrypted" and shared in a
clear channel.
To improve this, revert the recent commit to unquote URL userinfo parts to
restore backwards compatibility, and introduce a way to pass in basic auth
credentials in the "auth" object. The "auth" object was already added a while
back to allow authentication plugins to store their credentials in it. The
format is:
```
"source": {
"url": "https://host/db",
"auth": {
"basic": {
"username":"myuser",
"password":"mypassword"
}
}
}
```
{"auth" : "basic" : {...}} object is checked first, and if credentials are
provided, they will be used. If they are not then userinfo and basic auth
header will be parsed.
Internally, there was a good amount duplication related to parsing credentials
from userinfo and headers in replication ID generation logic and in the auth
session plugin. As a cleanup, consolidate that logic in the
`couch_replicator_parse` module.
The commit is quite different from the 3.x one for these two reasons:
* `main` uses two types of replication endpoint "objects": `#httpdb` records
and `HttpDb` maps. In most cases it uses maps which can be serialized and
deserialized to and from json. But in lower level, connection handling code
in couch_replicator_httpc, it uses `#httpdb` records. This explain the need
to still handle both representations. Auth session plugin, for instance,
uses the lower level #httpdb records while replicator ID handling code uses
the map based one.
* `main` has all the parsing of replication documents and `_replicate` request
bodies in a separate `couch_replicator_parse`. So, most of the code which
handles normalizing basic auth creds is there instead of
`couch_replicator_docs` or `couch_replicator_utils` like it is in 3.x
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On a heavily loaded system, it is possible for `is_key_fresh/1` to
return true, but subsequently for `lookup/2` to return `{error, not_found}`.
An example occurred during performance testing, where a `badmatch`
error in aegis_server generated this stack trace:
```
May 6 21:34:48 c-fdbcore-perf-api-5bc54ff569-jkjxx db error [error] 2021-05-06T21:34:41.337533Z dbcore@127.0.0.1 <0.18553.273> 6adfd54aa5 req_err(3074846293) {{badmatch,{error,not_found}},
[{aegis_server,handle_call,3,[{file,"src/aegis_server.erl"},{line,170}]},
{gen_server,try_handle_call,4,[{file,"gen_server.erl"},{line,636}]},
{gen_server,handle_msg,6,[{file,"gen_server.erl"},{line,665}]},
{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,247}]}]} : {gen_server,call,
[aegis_server,
{encrypt,
#{after_doc_read => undefined,before_doc_update => undefined,
check_current_ts => -576456460633,db_options => [],
db_prefix => <<21,22,21,15,1,23,5,202,10,0>>,
db_version => <<"f518950b94a759bb410f86d32126f421">>,
interactive => true,is_encrypted => true,
layer_prefix => <<21,22>>,
md_version => <<0,0,12,155,121,36,204,80,0,0>>,
name =>
<<"test-user-standard-0002/ccm_capacity_unit_1620334990_test-user-standard-1512">>,
revs_limit => 1000,
security_doc => {[]},
security_fun => undefined,
tx => {erlfdb_transaction,#Ref<0.4001737934.1270480897.28885>},
user_ctx =>
{user_ctx,<<"test-user-standard-0002">>,
[<<"_admin">>,<<"_reader">>,<<"_writer">>],
<<"cookie">>},
uuid => <<"97e681cfd7224680f72213b8bf59a25c">>,
validate_doc_update_funs => []},
[<<"gen_server:call/2 L206">>,<<"aegis_server:encrypt/3 L93">>,<<"fabric2_fdb:-write_doc_body/2-fun-0-/3 L1430">>,<<"lists:foreach/2 L1338">>,<<"fabric2_fdb:write_doc/6 L851">>,<<"fabric2_db:update_doc_interactive/4 L1944">>,<<"fabric2_db:update_docs_interactive/5 L1808">>,<<"fabric2_db:batch_update_interactive_tx/1 L1752">>]
```
The crash occurred in aegis_server [1] (now at a slightly different
line from the trace) because `lookup/2` returned `{error, not_found}`
[2] when unable to find the UUID in the cache.
This commit introduces a configurable grace period, defaulting to 5
seconds, which expired entries remain in the cache, so that such a
race is less likely to occur. It also handles the error case,
preventing a badmatch, and finally DRYs out the code by factoring a
`handle_crypto_call/6` function for both encryption operations.
[1] https://github.com/apache/couchdb/blob/main/src/aegis/src/aegis_server.erl#L173
[2] https://github.com/apache/couchdb/blob/main/src/aegis/src/aegis_server.erl#L339
|
| |
|
|
| |
A convenience function for configuration debugging.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When aegis is configured to use an operational key manager, the
get_db_info test can fail since the `passthrough` option is used, but
`get_db_info/1` doesn't get mocked, resulting in the operational key
manager's implementation unintentially being used in the test.
This replaces the `passthrough` option with `non_strict`, and mocks
`get_db_info/1` so that the same mocked functions are used in tests
regardless of whether `AEGIS_KEY_MANAGER` is `aegis_noop_key_manager`,
or an operational key manager.
|
| | |
|
| | |
|
| |
|
|
| |
This code is generating an unused function compilation warning.
|
| | |
|
| |
|
|
| |
Solved conflicts from "cherry-pick" 3.x commit with kdiff3 merge tool.
|
| |
|
|
|
|
|
| |
* Re-enable cookie auth elixir test
* Re-enable copy elixir test
* Add retry to cookie auth test
|
| |
|
|
|
|
| |
Upgrade random -> rand
https://github.com/apache/couchdb-hyper/releases/tag/CouchDB-2.2.0-7
|
| |
|
|
| |
Eliminate compiler warnings
|
| |
|
|
| |
Solved conflicts from "cherry-pick" 3.x commit
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, if a transaction got a `commit_unknown_result`, during the next
successful attempt that result would be returned to the user. However, if the
next attempt was another retryable error, then the committed result was ignored
and the whole transaction would be applied again. This could result in document
update transactions conflicting with themselves as described in issue
https://github.com/apache/couchdb/issues/3560
To prevent that from happening we remember that there was an
`commit_unknown_result` error during the course of any previous retries and try
to return that result.
|
| | |
|
| |
|
| |
When ApiMod:acquire_map_context returns with {error, any()}, the caller(s) fail with badmatch. This commit changes the caller hierarchy so that those {error, _} are propagated back and a failing update gets retried (up to retry_limit times).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Switching crypto functions to use the new ones such as:
```
crypto:hmac(Alg, Key, Message) -> crypto:mac(hmac, Alg, Key, Message)
```
To simplify Erlang 24 support, in which some crypto functions have
been removed, bump the minimum version to 22.
Other fixes were in dependencies:
* Bumped meck to 0.9.2. New meck from upstream supports Erlang
24. Also required bumping folsom since it depends on meck
* Example in passage module would not compile, so commented out
the parse transform. Required bumping jaeger passage since it
depends on passage
|
| |
|
|
|
|
| |
During buggify runs we disable max tx retries by setting it to -1. That's FDB's
documented way to of doing it. However, when we re-use that setting to handle
restart_tx logic we don't account for -1, so we that's what this PR fixes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add `buggify-elixir-suite` target to run Elixir integration tests
under FoundationDB's client buggify mode [1]. In this mode, the FDB C
client in the `erlfdb` application will periodically throw mostly
retryable errors (`1009`, `1007`, etc). Transaction closures should
properly handle retryable errors without side-effects such as
re-sending response data to the user more than once or, attempt to
re-read data from the socket after it was already read once.
In order to avoid false positives, provide a custom .ini settings file
which disables transaction timeouts (`1031` errors). Those are not
retryable by default, as far as the `on_error` callback is
concerned. Ff we do have timeouts set ( = 60000), it signals the
FoundationDB client that we expect to handle timeouts in buggify mode,
so it starts throwing them [2]. Since we don't handle those everywhere
we get quite a few false positive errors.
Buggify settings I believe are the default -- 25% chance to activate
an error, and 25% chance of firing the error when the code passes over
that section. In most test runs this should result in a pass, but
sometimes, due to lingering bugs, there will be timeouts, 409
conflicts and other failures so we cannot yet turn this into a
reliable integration test step.
[1] https://apple.github.io/foundationdb/client-testing.html
[2] https://github.com/apple/foundationdb/blob/master/fdbclient/ReadYourWrites.actor.cpp#L1191-L1194
|
