Copy the canister ID fom the Internet Identity canister, and paste it into webpack.config.js in this project on the LOCAL_II_CANISTER variable on line 8.
There’s probably something wrong with my webpack installation because it keeps telling me to install it, but once I do that, I changed this line in the dfx.json
I wonder if I’m breaking something when I change the line on dfx.json?
If I don’t change that line on dfx.json I get
% dfx deploy
**Deploying all canisters.**
**All canisters have already been created.**
**Building canisters...**
**Shrink WASM module size.**
**Executing** 'bash -c 'test -f internet_identity.wasm || curl -sSL https://github.com/dfinity/internet-identity/releases/latest/download/internet_identity_dev.wasm -o internet_identity.wasm; test -f internet_identity.did || curl -sSL https://raw.githubusercontent.com/dfinity/internet-identity/main/src/internet_identity/internet_identity.did -o internet_identity.did''
**Building frontend...**
Error: Failed while trying to deploy canisters.
Caused by: Failed while trying to deploy canisters.
Failed to build call canisters.
Failed while trying to build all canisters.
The post-build step failed for canister 'rrkah-fqaaa-aaaaa-aaaaq-cai' (auth_client_demo_assets) with an embedded error: Failed to assert source paths.: Unable to determine canonical location of asset source path /Users/black/icp/auth-client-demo/dist/auth_client_demo_assets/: No such file or directory (os error 2)
I don’t think the line you pointed out needs to be modified, it just worked fine for me. On the contrary I think the sample is only meant to run on post 8080 so if you want to use 8082, you should try to find all occurences and replace these.
Following step by step works for me:
git clone https://github.com/krpeacock/auth-client-demo
cd auth-client-demo
npm ci
dfx start --background --clean
dfx deploy
npm run start
# here open browser http://localhost:8080
As I mentioned also in Discord, the Readme instructions are out of date after I incorporated @peterparker 's II canister installation strategy, simplifying the local deployment and making the canister id known to dfx
I have an app with a frontend and a backend canisters that I need to add Internet Identity functionality to.
Kyle’s repo is running fine but I’m having trouble fusing that repo with mine.
My repo already has other integrations so I’m not sure if I should try bringing the auth repo into mine, or try to bring mine into the auth repo (though mine has several .mo files and so on), and what the best and simplest way to do it is.
I’ve tried fusing dfx.json and package.json and so on but I’m getting a bit dizzy.
I integrated that last one I think but I’ve only managed to use it with the real Internet Identity, which I think is incompatible with locally run projects, so I’m getting the anonymous principal back despite seemingly correctly authenticating.
Should the steps just be: adding the above to dfx.json, adding the login button and so on to index.html, and adding the logic from index.ts into the target project’s index.ts, and (in my case) adding the whoami function to my backend canister (with the corresponding change to index.ts so that it calls that canister for whoami)?
the whoami canister is just for demonstration purposes. You may have an easier time dropping in the new web component <ii-login-button>, by simply installing @dfinity/ii-login-button and importing it in your application
Yes that would work but once piece of the puzzle is missing in this list: the webpack.config or other bundler configuration.
When you deploy canister locally, they receive a canister id. These are the ids you should use in your frontend app (or else) to execute calls and queries (like the whoami).
Without any configuration, your frontend app does not know these generated ids.
So one way to tell your app which IDs to use is to hardcode these but, that isn’t really handy because if you don’t deploy your canister always in the same order they get different ids and also, when you gonna deploy on mainnet (production) canisters might also have other ids.
That’s why, the most handy way is to handle these IDs with environment variables that are generated automatically.
Note that process.env is the example of the react app, of course there are other ways. e.g. in my svelte app I use vite so I end up loading these in with .env.
Hopes this makes a bit more clear how things works out currently.
Is there a place with all the things and resources people should know about when working on a production app for the IC?
In particular, my next steps after authentication is integrating minting and burning an ICRC token into the app, and reading from HTTP outcalls in regular intervals (though I’m hoping this can be done just with some sort of while loop with a sleep() inside it in a canister function?).
I still haven’t managed to fully integrate this repo with my project.
My project is able to get an identity, up to and including
const identity = await authClient.getIdentity();
But then when I try to create an actor, the createActor function is not defined and if I try to import it from declarations by simply placing the whoami declarations folder in my project’s directory, I get this deprecation error:
I have the feeling, since you are porting your app manually, that the actor and did files are missing.
To create an actor on the frontend side to communicate with the backend, you need few things:
the IDs of the canister, which seems now to be fixed
the agent-js dependencies, which I guess you have installed (npm i ...)
the function, the createActor iself
the definition of the backend API, the candid files (also called the did files)
These last two things are the things I guess which are missing in your project. They can be created manually but commonly they are generated automatically.
If you open the package.json of a sample starter project, you should find a scripts named generate. This is the one you need to copy in your app so that you can run npm run generate.
This should generate function and definitions in a new folder src/declarations.
From there, the import should be resolved.
I might be wrong, it is just an assumption and you are maybe also already aware of this but just in case. Let me know.
I wonder if it would be easier to move the files from my repo to the auth-client-demo instead.
It seems like a lot of automated configuration is going on and I’m not sure how easy it is to actually use it other than directly building on top of it.
But then I’m not sure how straightforward it would be to move everything in that direction.
The demo video is only like 15 minutes so I assume adding auth is not meant to be a complicated process.
I’m happy with whatever works.
To be clear, the project already communicates fine between front and backend for other purposes, including for example making http outcalls to fetch data and then display it in the frontend. The problem is only in integrating authentication, specifically in making authenticated calls to the backend.
