Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix ddo encrypt for browsers #822

Merged
merged 3 commits into from
May 28, 2021
Merged

fix ddo encrypt for browsers #822

merged 3 commits into from
May 28, 2021

Conversation

alexcos20
Copy link
Member

Warning: Needs aquarius >=2.2.12

@alexcos20 alexcos20 self-assigned this May 28, 2021
@alexcos20 alexcos20 merged commit 6ce02ec into main May 28, 2021
@alexcos20 alexcos20 deleted the bug/fix_ddo_encrypt branch May 28, 2021 09:53
@@ -146,12 +146,12 @@ export class MetadataCache {
* @return {Promise<String>} Hex encoded encrypted DDO.
*/
public async encryptDDO(ddo: any): Promise<any> {
const fullUrl = `${this.url}/api/v1/aquarius/assets/ddo/encrypt`
const fullUrl = `${this.url}/api/v1/aquarius/assets/ddo/encryptashex `
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally we we stick to one form of encryption with one encrypt endpoint in Aquarius instead of adding multiple endpoints for one use case. If we want to support multiple types of encryptions then we should stick to REST principles and use the same endpoint, but with e.g. a body param

But I guess it's yet another hack for one use case. At least we should type what this methods returns which seems to be now Promise<string>.

And what's the implications for users who have used this encryptDDO method before, is this a breaking change for them?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants