How to identify app users data in the backend?

peterparker · July 23, 2021, 10:51am

My users are able to create data once they signed in in my app with their Internet Identity. I want to set rules on the backend side to allow them to only edit their own data.

“user A can edit his/her data, user B can edit his/her data, user A cannot edit user B data”.

On the client side, the HttpAgent has to be created with the signed in user identity or is it optional`?

const agent = new HttpAgent() // as generated by the sdk

or

const agent = new HttpAgent({identity}) // identity is the one of the signed in user through authclient

On the backend (Motoko) side, is it correct to say that the function’s caller is the identification of the end user (the user who use the app and signed in with the internet identity)?

public shared({ caller }) func who: async() {
    // the caller == the end user?
}

How should I save the data with the end user information?

public shared({ caller }) func set(obj : MyObj): async() {
    // TODO: save obj with caller
}

I was trying to set the principal.toText in my object on the client side and comparing it in the backend but, it does no work out.

Client:

await set({...myObject, user: authClient.getIdentity().getPrincipal().toText()});

Backend:

public shared({ caller }) func set(obj : MyObj): async() {
    if (Principal.toText(caller) != obj.user) {
       // => Always true => does not work for my use case
    }
}

I am not that successful, therefore would appreciate any help to solve some these questions.
Thanks in advance.

peterparker · July 23, 2021, 11:42am

I guess I can answer questions 2. and 3. with the linkedup example.

yes most probably the shared({ caller }) is the signed in user
the (all) user should be save within the data in the collection and it should not be provided by the frontend but only handled on the backend side. the entry point for such statement is the function hasAccess of the linkedup example.

claudio · July 23, 2021, 12:08pm

In Motoko, caller will be the principal of the immediate caller of the shared function - so in a recursive call from the canister, it will be the principal of the calling canister, and in a external call from the frontend, it should (I believe) be the principal of the user (authenticated or anonymous).

If you haven’t seen already read it, maybe this would help Integrating with Internet Identity | Kyle Peacock's website.

(I’ve alerted the II team to your query…)

peterparker · July 23, 2021, 12:19pm

Thanks Claudio!

Glad to hear your feedback about the caller. I hope you are right.

Regarding Kyle’s blog post, I had a look, but, I am confused about my 1. question because the code displayed in the article does not match the one automatically generated by the SDK.

In the article, the {identiy} is provided to create an httpAgent but, in the automatic code, the agent is generated without (see createActor and related comment).

export const createActor = (canisterId, options) => {
    const agent = new HttpAgent({...options?.agentOptions});

   ...

/**
 * A ready-to-use agent for the decks canister
 * @type {import("@dfinity/agent").ActorSubclass<import("./decks.did.js")._SERVICE>}
 */
export const decks = createActor(canisterId);

Maybe I should just understand the automatic generated code as a sample one and not the proper actor to be used.

claudio · July 23, 2021, 12:50pm

I believe the argument is optional, and will default to using the anonymous identity when omitted.

github.com

dfinity/agent-js/blob/main/packages/agent/src/agent/http/index.ts#L110

    
      
          // allowing extensions.
          export class HttpAgent implements Agent {
            private readonly _pipeline: HttpAgentRequestTransformFn[] = [];
            private readonly _identity: Promise<Identity>;
            private readonly _fetch: typeof fetch;
            private readonly _host: URL;
            private readonly _credentials: string | undefined;
            private _rootKeyFetched = false;
            public rootKey = blobFromHex(IC_ROOT_KEY);
          
          
  constructor(options: HttpAgentOptions = {}) {
              if (options.source) {
                if (!(options.source instanceof HttpAgent)) {
                  throw new Error("An Agent's source can only be another HttpAgent");
                }
                this._pipeline = [...options.source._pipeline];
                this._identity = options.source._identity;
                this._fetch = options.source._fetch;
                this._host = options.source._host;
                this._credentials = options.source._credentials;
              } else {

peterparker · July 23, 2021, 1:08pm

It confirms the blog post is correct, the identity of the signed in users need to be provided to the http agent and the createActor in the automatically generated code should be considered as a sample code.

kpeacock · July 23, 2021, 1:37pm

I’ll update the blog post and example code to 0.8.0 today. I’d been focused on official doc updates over my blog

peterparker · July 23, 2021, 1:57pm

Awesome! Looking forward to it.

peterparker · July 26, 2021, 8:32am

I gave a try to the your updated auth-client-demo for v0.8.0 but did not manage to pass the local sign-in.

The local anonymous identity provider redirect to the Internet Identity but, after successful authentication, it does not redirect to localhost:8000.

I face the exact same problem with my app too.

Something is buggy or is missing in your demo?

git clone GitHub - krpeacock/auth-client-demo: Example demo of how to use https://www.npmjs.com/package/@dfinity/auth-client to make authenticated calls to an IC app
cd auth-client-demo
npm ci && npm i @dfinity/identity @dfinity/candid @dfinity/auth-client @dfinity/authentication --save-dev
dfx start --background
dfx deploy
find local internet identity canister id in .dfx/local/wallets.json
update webpack.config.js with this canister id for LOCAL_II_CANISTER
dfx deploy
open browser localhost:8000?canisterId=web_app_canister_id
click sign in
open new tab localhost:8000?canisterId=local_idenity_canister_id
click “Authenticate”
redirect to identity.ic0.app
click “Authenticate” and process
=> no redirect to localhost:8000!

kpeacock · July 26, 2021, 2:29pm

Oh, I bet it’s the II URL - do you have the #authorize hash at the end?

peterparker · July 26, 2021, 2:53pm

Yes. As I said I tried with your auth-client-demo and did not change the url beside updating the canister id with the one I found locally in wallets.json.

Note that there is a redirect when I access the anonymous local identify provider.

When I click “Log in” in your app, it does open a new tab with http://localhost:8000?canisterId=...#authorize but, it is shortly redirected to http://localhost:8000/authorize?canisterId=..., not sure that’s the expected behavior.

kpeacock · July 26, 2021, 6:30pm

Yeah, that redirect seems weird to me. If you have chrome available, try going to http://<canister-id>.localhost:8000#authorize

peterparker · July 26, 2021, 7:20pm

Oh I think I get it. It probably doesn’t work because I did not had deployed a local internet identity. I thought it was already deployed. Anyway, I think we can therefore consider the topic as closed, thanks for the support.

peterparker · July 26, 2021, 7:34pm

Regarding my original questions, summarized and tested:

yes the identity of the sign in users (the users of the web app) has to be use to instantiate a new HttpAgent({identity})

see my function ic.utils.ts

yes it is correct to say that the function’s caller is the identification of the end user (the signed in user of the web app)
the data can be saved as in linkedup. Next to the data, the user principal can be saved. Upon any request, the corresponding element should be read from the collection, for example a Trie, and both msg.caller and saved user can be compared to check if it matches or not.

See the function getDeck in my implementation.

To with my user identity I signed in in my web app and created a data. On my friend’s laptop, with his internet identity, we tried to fetch the data which was rejected by the check I have build. Therefore it practically validated that the user identity on the data level was valid .

Thank you for your answers and help!

Topic		Replies	Views
Are Principals unique? Language Support Motoko	3	414	June 29, 2021
Get unique ID on the frontend Language Support Motoko	7	1430	March 25, 2022
Problems with cross referencing principals Developers	15	1106	July 17, 2021
Verify signed message Language Support	0	437	October 14, 2021
How can I associate the generated principal by login with II and the internet identity's principal? Programs & Applications	2	671	January 18, 2022

How to identify app users data in the backend?

Related Topics