Huawei Ability Gallery — Account Binding for Card Ability — Solution 2
Hello,
In this article, we will talk about Account Binding with Huawei ID, which is the second way to syncronize user accounts (Account Binding-Solution 2) for the Card Ability feature offered by the Huawei Ability Gallery. Since we talked about solution 1 and the difference between them in my previous article, we will not talk about this difference too much in this article. You can read my previous post from the link below.
In Account Binding Solution 2, which is the subject of this article, there is no need for any OpenID & Developer’s Account pairing, as there is Account Kit / Auth Service SDK on the client side. Because the Client can always access OpenID and by using it, our application can send an event push by the Client Server to the Card Ability widget on the “-1” screen provided by HAG.
Here, we can bind the user account with shorter steps, since there is no login process and deeplink returning processes that we did in solution 1. To make it easier to understand, I have drawn the operations to be done in the diagram below. In order not to cause confusion because the steps in this diagram conflict with the steps of the “implementation process” in the official document, I have numbered step 5 as the first step, which is the scope of my article, as in my 1st article. In addition, we will not mention the client side in this article, because we do not need to do an extra process on the client side in account binding with HW ID. Only later, where synchronization is required according to your usecase, we can send the OpenID, which we have accessed thanks to the Account Kit / Auth Service SDK, to the backend and synchronize with event push from there.
We will make a demo to better explain how to do Account Binding using Huawei ID. In the backend, we will use Java Spring as in my previous article. Now we can move on to the development stages.
Demo Development
In this demo, we will use Account Binding in an e-commerce application scenario, as in my previous article. In this way, we will connect the user’s account with Account Binding to the widget on the -1 screen, where we use the Card Ability feature.
Using Account Binding, we will be following the implementation process below to bind users’ accounts. However, in addition to this, I should add another step and specify that we need to perform server side authentication. Because we will need an access token in the header when declaring the Account Binding process to the HAG server.
First of all, I would like to talk about what we will do as an overview step by step. Afterwards, I will explain the codes to be written at each stage.
In this article, since I will talk about server-side developments, I will start from step 5. First of all, an OpenID comes to our server by Huawei Ability Gallery. We will return the mandatory values specified in the official document to the incoming request. Then we will complete the Account Binding process by saving the OpenID to our database and notifying the HAG server. If you notice, we do not need an ID match as in our previous article. Because the Client can access the OpenID of the logged in user, thanks to the Account Kit.
What we achieve as a result of these processes is to synchronize our users’ accounts by connecting their accounts to the Card Ability widget provided by Huawei Ability Gallery on the -1 screen.
Now, for the first step (5th step in the diagram), we need to get the OpenID from the request received by the HAG server to the endpoint we specified on the server. For this, we need to write the Controller on the backend side. However, we must first create the classes and interfaces that we will use in this Controller. When connecting the controller and the service, we will use interfaces to facilitate testability and create a better structure. For this, we first create our HAGService interface.
Here, I also added the function that we will use for the Account Unbind operation in order not to add this interface and extend the article. But what we need for step 5 is the accountBindWithHwId function.
Now let’s create the AccountBindingHAGRequest object, which is the parameter of this function. Since we only need OpenID in the demo we will do here, it will be useful for the AccountBindingHAGRequest object to be as follows. (I’m only sharing the json file instead of java classes since creating individual objects will take up a lot of space. While you are developing, you will need to create classes to represent this json file.):
Now, as stated in the official document of HAG Card Ability Account Binding, we will create a response object in the format that the HAG server will accept.
AccountBindingHAGResponse.java (Representative json object):
Here, since we do not need deeplink parts for Solution 2 (HW ID Account Binding), which is the scope of our article, and accountLoginAddr, which already contains these values, is not mandatory, we will return null without setting these values.
We should not forget that every property is case sensitive and the type of “minVersion” is Long.
Now we will create our HAGController that accepts the request in the format we have created and will return a response message in the format we have created.
In this controller, we autowire our HAGService interface. Then we wrote a function to handle the POST requests coming to the
domain name/hag/account/bind/hwidendpoint.
Note: According to this function and Controller, the url we need to specify for account binding in HAG console should be “ ‘your domain’ /hag/account/bind/hwid”.
Since the HAG server will send a POST request to the url we will specify on the console side, we have added the @PostMapping annotation to the accountBinding method where we will handle this request. Since the HAG server will send the OpenID here in the body and in the request object format that we created before, this function should take the request object that we created before as a parameter, with the ResponseBody annotation at the beginning. This is how we created our function.
Then we send this parameter (request body) to the Async function on the service side. And without being blocked, after checking whether OpenID comes with a request or not, we created a response message just like in the code above and returned it.
Note: You can create a response message in the same way as I did in the code above. Because the values here will not change our result.
So far, we have actually completed step 5 in the diagram. Now we go to step 6. In step 6, we will save the OpenID from the request to our database. For this, we need to create our HAGServiceImpl class, which includes the accountBindWithHwId() function and implements the HAGService interface, which will work asynchronously. In addition, we must create our OpenIDRepository interface that extends the JpaRepository to perform operations such as writing and updating and the table in our database to keep the relevant data.
First of all, we create a class as follows to create the table where we will save the OpenID.
OpenID.java:
Now we create our Dto class for access here.
OpenIDDto.java:
Then we create our repository to benefit from Spring Data, which facilitates our database operations.
OpenIDRepository.java:
Yes.. Now we can create our HAGServiceImpl class.
Here we have wired our repository. Then we specified that this function will work asynchronously with @Async annotation. Because we do not want to block the request from the HAG server.
Since we call this function from HAGController and it will take AccountBindingHAGRequest parameter from there, we specified the parameter like this. We get the OpenID from the incoming request. Then, if there is no OpenID in the database, we save it. In this way, we have completed the 6th step.
Then, as the 7th and last step for our part, we report this to HAGServer.
Note: The next steps (notifying the HAG server) from here are the same as the steps 10 and later of the previous post (for Solution-1). But I’m adding it again so that you don’t have to search.
We will use WebClient to declare binding to HAGServer. For this, we send a request to the account binding url of the HAG server. For this request, we must first get the Bearer token we need in the header. For this, we will use WebClient again.
We are creating a form data because the url content type we will receive tokens supports url-encoded. This form data should contain grant_type, client_id and client_secret values as above. Here, the fields that you need to fill in according to your own project are as follows;
- client_id
- client_secret
You can access these values from the console.
Then, we get the Bearer token we need in the header of the request of account binding by sending a POST request to TOKEN_URL using WebClient.
Now we have to create the body of the request that we will send to the HAG server to report the account binding result.
Finally, we will request to declare the account binding status to the HAG server with the values we will obtain using these functions.
Here, the parameter openID comes from the id match request thrown from the application.
In this way, users of our application will be able to connect their accounts with the Card Ability feature provided by the Huawei Ability Gallery.
For Unbind, we only need to change the BIND_URL. All remaining operations are the same.
Unbind URL: https://hag-eu.cloud.huawei.com/open-ability/v1/open-account-events/unbind
Output
