otaris / mf-rest-api Goto Github PK

You never really need to know the real username on the external service (or the email address for Google OAuth), but only if the user name of the response equals the registered user name. Therefore we can basically handle them like passwords.

Integrate OWASP Dependency Check into Github Actions Pipeline.

Add several Unit Tests.
Later they should be integrated into a CI pipeline to verify functionality with every push.

In the docker-compose file unnecessary environment-variables are mapped.
At least the MF_PROPERTIES is not needed in the db services.

Maybe a solution would be to add the environment variables directly in the docker-compose file with a comment which of them have to be exactly the same like the postgres user and pw to avoid unnecessary settings.

Since we want to be able to receive notifications by the block chain, we need to hold a session. All required functions should be inside our Utils class.

This is related to the requirement of the shipping order form for specific types of users (they should be customizable). Following is the user story formulation of this requirement:

As a dashboard operator I need to be able to define or change the existing roles without having to directly change the database in order to be able to signal upstream systems (currently through the token) which access control policies should be applied.

One can implement an additional role system in the upstream system, but it makes it really complex to map the roles there to the roles in the REST API and also make sure that the UI does not even attempt to give the user the impression that specific actions are possible.

I suggest one workflow for pull-requests to the master, where we build and push the docker files and check for vulnerable dependencies, and another workflow for pushing to branches, where we run unit tests and spotbugs.

Hi everyone,

please note that in the master branch the file generate_connection-json.sh lines 43 and 55 it says

"url": "grpcs://${MF_HOST}:7050",

this is not correct (the rest api itself is not a gRPC host).The corresponding orderers or peers should be inserted her e.g. orderer.myorg.net:7050 or peer.myorg.net:7050

Best
Razvan

The REST API is supposed to provide the functionality of the chain code (see the corresponding chain code issue). This required the REST API to hold a connection (see the holding the connection issue).

Environment variables should be used for connection file, private key and admin certificate in Main.java instead of having paths to the files. The user must set CONNECTION_JSON, PRIVATE_KEY and ADMIN_CERT variables on their system before starting up the API.

The docker build fails, since its expects a directory ./build to copy
=> ERROR [5/6] COPY ./build /app/build/

Therefore it should be stated in the documentation, that projects needs to build before or the build should be integrated in the start script.

With this feature we offer users a mechanism of validating tokens, issued from another entity beside the REST-API and Authorization Server.
With minor changes it will be possible to request a protected resource from the REST-API with a token issued by Google. At the same time, the user will be authenticated by Google. With that, it's possible to host the REST-API without much effort to maintain a database infrastructure.

At the moment it is not possible to request all possible function names (when adding them to whitelists) to display in a User Interface.

Extend the Github Actions pipeline with a tool for static code analysis.

It is important to add the endorsing peers to the connection profile depending on the chaincode endorsement policy.
If not done, the peer will throw validation errors.
The default policy is Majority.

Repro steps

Request:
{{url}}/get?function=readObject&args=MILK10

{"key":"MILK10","amount":100.0,"unit":"Liters","alarmFlag":false,"productName":"milk","receiver":"","actualOwner":"DeoniMSP","privateDataCollection":[],"predecessor":{},"successor":{},"tsAndOwner":{"2020-10-02T07:45:46.941880900Z":"DeoniMSP"},"attributes":{"Quality":"100"}}Private Data: {}

The last part: Private Data is outside the JSON brackets, this leads to confusion when trying to parse the returned string.

Desired state

Private Data array is inside the returned JSON object. No parsing errors are returned.

The OAuth2 Standard was created for authorization of users but is also widely used for authentication purposes.
By integrating OAuth2 into the REST-API we'll offer clients a scalable method of authentication which can be used with an own Authorization Server or other providers like Google.

A CI pipeline needs to be created. This can be done using Github Actions.

We want to introduce versioning of MetaDefs in order to tackle issues with changing definitions during runtime.
Therefore we need to support a function like "META_getMetaDefVersion(objectId)" and an optional version parameter for the function "META_readMetaDef()".

There are still many hardcoded Strings, which we might want to configure. Examples are the database name and the custom OAuth server credentials.