Hawkin
/
arangodb
mirror of https://gitee.com/bigwinds/arangodb
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Bug fix 3.4/jwt base64url encoded (#7904) 

* Use base64url encoding and decoding for jwt header and body as specified in the rfc.

* Added changelog.
This commit is contained in:
Lars Maier 2019-01-08 16:55:17 +01:00 committed by Max Neunhöffer
parent 9c099ba5da
commit bc9f9ed14d
2 changed files with 14 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
CHANGELOG
View File

@ -1,6 +1,8 @@
v3.4.2 (XXXX-XX-XX)
-------------------
* Use base64url to encode and decode JWT parts.
* added AQL function `CHECK_DOCUMENT` for document validity checks
* when detecting parse errors in the JSON input sent to the restore API, now
@ -8,7 +10,7 @@ v3.4.2 (XXXX-XX-XX)
but hiding there was a problem.
* do not respond with an internal error in case of JSON parse errors detected
in incoming HTTP requests
in incoming HTTP requests
* added arangorestore option `--cleanup-duplicate-attributes` to clean up input documents
with redundant attribute names
@ -25,7 +27,7 @@ v3.4.2 (XXXX-XX-XX)
default values for the number of shards and the replication factor, resp. for all
restored collections. If specified, these default values will be used regardless
of whether the number of shards or the replication factor values are already present
in the metadata of the dumped collections.
in the metadata of the dumped collections.
It is also possible to override the values on a per-collection level by specifying
the options multiple times, e.g.
@ -41,10 +43,10 @@ v3.4.2 (XXXX-XX-XX)
--number-of-shards mycollection=3 --number-of-shards test=4
This will use the number of shards as specified in the dump, except for the collections
"mycollection" and "test".
"mycollection" and "test".
The `--replication-factor` option works similarly.
* validate uniqueness of attribute names in AQL in cases in which it was not
done before. When constructing AQL objects via object literals, there was
no validation about object attribute names being unique. For example, it was
@ -54,9 +56,9 @@ v3.4.2 (XXXX-XX-XX)
This resulted in a document having two "a" attributes, which is obviously
undesired. Now, when an attribute value is used multiple times, only the first
assigned value will be used for that attribute in AQL. It is not possible to
assigned value will be used for that attribute in AQL. It is not possible to
specify the same attribute multiple times and overwrite the attribute's value
with by that. That means in the above example, the value of "a" will be 1,
with by that. That means in the above example, the value of "a" will be 1,
and not 2.
This changes the behavior for overriding attribute values in AQL compared to
previous versions of ArangoDB, as previous versions in some cases allowed
@ -65,11 +67,11 @@ v3.4.2 (XXXX-XX-XX)
value. In order to explicitly override a value in an existing object, use the
AQL MERGE function.
To avoid all these issues, users are encouraged to use unambiguous attribute
To avoid all these issues, users are encouraged to use unambiguous attribute
names in objects/documents in AQL. Outside of AQL, specifying the same attribute
multiple times may even result in a parse error, e.g. when sending such data
to ArangoDB's HTTP REST API.
* fixed issue #7834: AQL Query crashes instance
* Added --server.jwt-secret-keyfile option.

8
arangod/Auth/TokenCache.cpp
View File

@ -252,7 +252,7 @@ std::shared_ptr<VPackBuilder> auth::TokenCache::parseJson(std::string const& str
bool auth::TokenCache::validateJwtHeader(std::string const& header) {
std::shared_ptr<VPackBuilder> headerBuilder =
parseJson(StringUtils::decodeBase64(header), "jwt header");
parseJson(StringUtils::decodeBase64U(header), "jwt header");
if (headerBuilder.get() == nullptr) {
return false;
}
@ -287,7 +287,7 @@ bool auth::TokenCache::validateJwtHeader(std::string const& header) {
auth::TokenCache::Entry auth::TokenCache::validateJwtBody(std::string const& body) {
std::shared_ptr<VPackBuilder> bodyBuilder =
parseJson(StringUtils::decodeBase64(body), "jwt body");
parseJson(StringUtils::decodeBase64U(body), "jwt body");
if (bodyBuilder.get() == nullptr) {
LOG_TOPIC(TRACE, Logger::AUTHENTICATION) << "invalid JWT body";
return auth::TokenCache::Entry::Unauthenticated();
@ -369,8 +369,8 @@ std::string auth::TokenCache::generateRawJwt(VPackSlice const& body) const {
headerBuilder.add("typ", VPackValue("JWT"));
}
std::string fullMessage(StringUtils::encodeBase64(headerBuilder.toJson()) +
"." + StringUtils::encodeBase64(body.toJson()));
std::string fullMessage(StringUtils::encodeBase64U(headerBuilder.toJson()) +
"." + StringUtils::encodeBase64U(body.toJson()));
if (_jwtSecret.empty()) {
LOG_TOPIC(INFO, Logger::AUTHENTICATION)
<< "Using cluster without JWT Token";