I am new to Block chain development.I am now trying to write a smart contract in Hyperledger Composer. My smart contract should do this function.
It should access a file on the cloud and run an encryption algorithm on that file and should send to the user on request file transaction invocation.I have a few questions on this:
Is it possible to access a file on the cloud through smart contract code?
I have an encryption algorithm in Java.How can I include it in smart contract so that it can encrypt the file?
Hyperledger Composer Transactions allow you to 'call out' using the Node Request module, so if your cloud file system can make documents available on a REST service then you will be able to access them from Composer. The details of calling out to a REST service are covered here in the Composer documentation.
For the encryption as with the Cloud File, if you can expose your java algorithm as a REST service then you can call it. Otherwise you would need to re-write your encryption in javascript whilst remembering that Composer does not allow 'Import' or 'Require' in the transaction functions.
Related
Before I conclude that I can't do this with google cloud workflows alone, I just wanted to check with the community that I'm not missing anything...
I have a google cloud workflows program which exports data from BigQuery to GCS and then sends an email to a user with a URL in the body of the email. I want this URL to be signed.
The gcloud CLI and language-specific libraries all come with nice helpers to do this but I can't access any of this direct from google cloud workflows. I considered implementing my own sub-workflow which would perform the logic described in the signing URLS manually documentation but I don't think I can do this from Workflows alone (I could easily create some cloud func which I call [and in that case, I could just use the helper from the python SDK for example] but I'm trying to avoid that). The following functionality from the python example constitute blockers; logic that I believe I can't do from google cloud workflows alone - unless anyone knows of public web services that I can call to get around this?
canonical_request_hash = hashlib.sha256(canonical_request.encode()).hexdigest()
signature = binascii.hexlify(google_credentials.signer.sign(string_to_sign)).decode()
Everything else I could just about do in a fairly long and drawn out sub-workflow... but it would be possible.
Cloud Workflows do not natively support hashing & RSA signing libraries within its Standard library which is a core requirement of GCS URL signing algorithm.
As also advised in public docs, Cloud workflows / sub-workflows should be primarily used as an orchestration flow to invoke services, parse responses, and construct inputs for other connected services. Services (like Cloud Function / Run etc.) should be created to perform any work that is too complex for Workflows or for operations that are not natively supported by Workflows expressions and its standard library.
Solution for above use case is to either:
a) Create a service (~ triggered from Cloud Workflow) like Cloud Function to generate signed GCS URLs.
OR b) Generate the GCS Signed URL as an independent task outside & after execution of the core workflow operation as shown in this sample.
I am working with Google Firestore in native mode and CRUD'ing data within it using the "cloud.google.com/go/firestore" api in Go. Access to the data is wide open as long as you know the project id and using the Firestore API on a server. I don't want to try the rules until I figure out how to secure the data from server attacks that. Again, all the API requires is the project id to access the data so I need to lock that down firstly before I move any further. Rules are only for mobile/web clients from what I read and Server side clients completely bypass the rules. Please help. I do not want to use the Firebase API because attackers can still use the Firestore api to access the data.
It's unclear from the limited information in your question but, your Firestore database is not open to anyone with the Project ID.
The service is only accessible to any thing (human|machine) that has valid credentials. Either humans with e.g. Gmail accounts or Service Account key holders.
In either case, only identities that you've explicitly added to the project will be able to access its resources and then only those with the appropriate IAM roles|permissions.
Google provides an elegant facility called Application Default Credentials (ADCs) that simplifies authenticating clients.
I suspect that your code is using ADCs to authenticate you to the project|service.
Access to the data is wide open as long as you know the project id and using the Firestore API on a server.
If that is a concern, consider disallowing all access in the Firebase security rules for your Firestore database.
Also have a look at my answer here to understand why sharing your project ID is not a security concern, and in fact is necessary if you want to allow direct access from client-side devices: Is it safe to expose Firebase apiKey to the public?. If you don't want to allow direct client-side access, closing down the security rules (as they are by default, unless you choose test mode when creating the database) is the way to go.
I want to use the Direct Mail SDK(Java) directly within client application which is distributed across. The way to authenticate users within the application, I need to provide access keys as below,
IClientProfile profile = DefaultProfile.getProfile("cn-hangzhou", "<your accessKey>", "<your accessSecret>");
How can I prevent user to know the Access Keys and still prevent the need of third-party API? Is it possible?
First, it is bad practice to code an application that requires secrets that runs on the client. You should manage everything on the server and provide an API that the client software interfaces with.
Second, there is no way to hide those credentials once passed to the client. You could encrypt the credentials but at some point the client application will need to decrypt them. Even amateur programmers can figure out how you are processing your credentials.
Ignoring the above advice, Alibaba Cloud supports STS which provides temporary access keys. Using your Alibaba credentials, you would call AssumeRole which creates temporary access keys giving the user permission call DirectMail. You can limit the time that the credentials are valid. The range is 900 to 3600 seconds. After that duration the keys become invalid.
Keep in mind that 900 seconds is a long time. A bad actor getting access to those keys could send thousands of emails using your account. Therefore implement strong user authentication, STS and temporary access keys.
If you think that just keeping your interface secret is enough, don't. There are millions of script kiddies on the Internet poking at every IP address. Launch a new ECS instance and you will see attacks within hours.
As you said since it is a Java Web Application(assuming), currently I think of something using similar to JBOSS Vault to store the access keys securely.
If it is some standalone client application still you can use some encryption methodologies to store the data. But this will only prevent easy access to the data/keys. But it is not impossible. The best bet would be creating another third-party API
I am working on a POC and do not want to write any specific transaction processing functions. Created assets, participants etc. and all, so the model is ready. Generated rest api using hyperledger composer-rest-server. The frontend is developed in simple html/javascript.
the problem is that i need events also available whenver i CRUD using composer generated APIs, but not able to figure out how.
IS it that to capture events, we need to create assets using transaction processing functions only and not via composer rest server apis - a little novice kinda question but i am stuck in this thought.
regards,
Sophia
I think you have figured it by now, but here's the answer for the rest of us: you can only generate events from your chaincode, and every event has to be described in your model.
I am building an PoC using Fabric v0.6 and composer-ui. The question I have is regarding how to interact with the Fabric peers once I have deployed my .bna file in the Fabric network. In the past I have made invoke and query calls to my chaincode using gRPC and passing the function name and arguments through the call. In the case of chaincode deployed through composer, there is a whole abstraction happening so I am not sure if the name of my transactions created in composer translate exactly to names I can call via my gRPC calls on the client side (my node application). I also don't know if the arguments that I pass to the chaincode are the same or if any special argument is expected.
So I guess my question is, from the client side, how do I make calls to transactions in my chaincode that have been creating using Composer? Are there client examples out there for Fabric v0.6? Thanks!
The first example that comes to mind is the sample-applications repository at https://github.com/fabric-composer/sample-applications
if you look in the sample-applications/packages/getting-started there is an example of a client application. The landRegistry.js file in the lib directory contains the bulk of the code used to interact with the business network.
There is also an application generator which is described in more detail at
https://fabric-composer.github.io/applications/genapp.html
You can also find reference documentation for both client side and businessnetwork implementations at
https://fabric-composer.github.io/jsdoc/
You should also consider using the REST API that Composer can generate for your business network.
npm install -g composer-rest-server
composer-rest-server
Then fill in the details required to connect to your business network and the composer-rest-server will expose a Swagger defined REST API that you can exercise using Swagger UI. The REST API is expressed in terms of the assets, participants and transactions that are modeled in your business network.
More docs here:
https://fabric-composer.github.io/integrating/getting-started-rest-api.html
The advantage of using the REST API is that it keeps the coupling between the client application and the blockchain loose; the client doesn't need any Composer libraries and doesn't even need to know that the data source is a blockchain.