Previously there were 2 ways to validate the access_token
1. define auth_url, which will send the access_token to
keycloak for validation
2. define absolute user_info_endpoint_url to validate the
custom url
In this patch we have removed the 1st option to validate
everytime with keycloak instead we are taking keyclaok certs
and constructing public key with it and then validating using
access_token using public key and iss(optional).
We are keeping the public key in cache to not to request
keycloak repeatedly.
Change-Id: Ie0551c2f9f8a37debd50e7aebcf35f7143db44f9
Due to https://www.python.org/dev/peps/pep-0479/ stopIteration
will not be caught anymore and needs to be use return instead.
updated with relevant changes.
Change-Id: If25b6ccecd46fed0225a230096041996fb91c0c5
closes-bug: #1837778
While extracting zip and saving it in database, if any of the fize size
is biggger than 65535 it is getting truncated during save.
It is because of the data which is a LimitingReader object has
BlobIterator as internal content iterator which has internal
chunk limit of 65535.
Change-Id: I3220abcd7cbc38db821478989c4c226a6f3366b5
closes-bug: #1821866
We got a specific case in which this change
is needed:
An aritifact type that only one instance is
allowed to be in 'active' status.
To enforce that we want to use pre_update_hook,
and check if there is any other artifact in 'active' status.
To do so we need json_patch info (we need to know if the json_patch
change status to "active" or "deactivated".
This change aim to suuport this case and also support backward
compatibility.
With this background, if the a user update 'active' artifact
to be with status "deactivated", we must know the patch info.
Change-Id: I6e85ff89144ca6d3a69c7a240de3f41bd1d999e7
Client should be able to create a token using “auth_url” (e.g. ”https://keycloak:7443/auth”)
Server should be able to validate the token using “user_info_endpoint_url” (e.g. “https://cbnd:9443/something/custom”)
also be backward compatible
Change-Id: I247ae280710cb42c21e0c888f41622fa6dedfe9d
In case artifact's field is defined to be
nullable=false and also doesn't have any
default, we had a problem:
While creating new artifact of this type
with a value for this field we got:
"BadRequest <artifact_name> field: <field_name>.
value: [None]. Exception.
That happened although a field value was provided.
This kind of error is expected if the field does
not get any value at creation, but not expected
if value is provided.
The following patch suggest a fix for that.
closes-bug: #1775502
Change-Id: I642249f067ab853b4b7d56a8da4db5809ee414c6
In case Artifact does not have tags associated and query
constain tags/tags-any condition with any other base artifact
field or custom field condition. It used to fail because of
INNER JOIN between glare_artifacts and glare_artifact_tags table.
Replaced "join" with "outerjoin" to rectify this issue.
Change-Id: Ie03520a38d2c726117195ea92c7fbd88c04bff18
While re-uploading blob if pre_upload_hook or store_api throws
exception, Existing content needs to be retained.
Change-Id: I51effe4c76de9a353dec99c634c173840c792198
In case of more than one tags values in request query with other
condition it was not using separate alias name for artifact_tag table
to join with glare_artifacts table. To rectify this we have created
aliases beforehand and using it updating the tag search condition.
Change-Id: Ic7afe47fcf8f23a694f2c3d99dbdbd7797d506dd
closes-bug: #1765338
If artifact data has multiple properties other than base
artifact properties i.e. which needs to be stored in
glare_artifact_properties table. In that case providing limit will
always result in less no of artifacts then limit.
This issue is not available in sqllite database, therefore no additional
testcase is added.
Change-Id: I933783cabb5b71d92b4d645d340bd9d1c9f6f8b5
closes-bug: #1766537
In case that "artifact data" does not contain properties other
than base artifact properties, query will return no records.
That because of INNER JOIN usage between glare_artifacts and
glare_artifact_properties tables (as there are no rows in
glare_artifact_properties corresponding to that artifact_id).
Therefore INNER JOIN needed to be added only if there is
any glare_artifact_properties based condition.
Change-Id: Icfcbeb41703771145db5405ffc2609dbb6ca1741
updating the value of source location in move operation
as part of artifact update.
Change-Id: Ic6912fa9c714762e38ba01793a7a8da1a70a12ba
Closes-bug: #1743971
when glare requests are failing with "401 Unauthorized"
against keycloak, more data can be added to the logs,
to understand the reason better.
In case keycloak return 401 it must provide the www-Authenticate
response header with the reason:
https://www.w3.org/Protocols/HTTP/1.0/spec.html#WWW-Authenticate
This code take care of it by adding the WWW-Authenticate value to
glare api-log.
Change-Id: Ia3966ad00868b559874610f552c8e491d8a01acd
With the new changes it is be possible to search tags based on or query.
it can be used with both tags and tags-any filter parameters.
Change-Id: Ib7a0054cb7e220e64d19839d79367b1ac180ea94
Implements: blueprint glare-search-artifact-query-update
Provides an option to specify query combiner ("and/or")
for attribute based filters in query parameter.
So if user wants to search artefact a based on filters :
field1 = value1 and (field2 = value2 or field3 = value3)
it can be specified in query like :
field1=eq:value1&field2=or:eq:value2&field3=or:eq:value3
"and" is the default value of combiner in case it is not specified.
Change-Id: I16c7c7fecefab5d615fa9e933234725249c5d97a
Implements: blueprint glare-search-artifact-query-update
default filter for name and type_name does not
allow to use like operator by default due to performance issue,
therefore we have added filters_ops for name in base_artifact
and type_name in all.py
Change-Id: Ib6c5f0d249c33f52858c03c454a0a7a0859e9301
display_type_name provides admin a facility to
define a more user friendly type_name for artifact.
Change-Id: I8b1b08e4fa647c87c65f7af94f8f49d6269e03cf
Currently in order to list artifacts from all tenants,
keyclock token must include 'admin' role.
The same goes for getting artifact from different realms,
or download blob of artifact from different realm.
The following changes enable more flexbility:
to list artifacts from all tenants, user can define
artifact:list_all_artifacts in policy.yaml with his
own choice for role.
E.G.
"artifact:list_all_artifacts": "role:su_role"
^ this will allow any user with role "su_role" to
list artifacts from any realm.
The same logic holds for getting artifact from other
realm (get_any_artifact), or download blob from artifact
in any realm (download_from_any_artifact)
Change-Id: Iaaa7f4b366230e0c5e4bee136bcdf9d072d498d8