Problem Background:
“Hello everyone! I’m trying to connect to the https://ic0.app API using Rust with ic-agent and reqwest to call a canister interface deployed on the Internet Computer (IC) network. However, my requests consistently return a 403 Forbidden error.”
Context and Troubleshooting Steps Taken:
"To ensure compatibility and legitimacy of my request, I have taken the following steps:
- Set the user agent and redirect policy to simulate a browser request;
- Configured TLS settings and ensured the network is functioning correctly in my Docker container. When I access
ic0.app via curl, I receive a 307 redirect response;
- Attempted to add
fetchRootKey() in the code to account for differences between local and mainnet environments, but this didn’t resolve the issue."
Example Code:
use reqwest::blocking::Client;
fn main() -> Result<(), Box<dyn std::error::Error>> {
let client = Client::builder()
.user_agent("Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36")
.redirect(reqwest::redirect::Policy::limited(10))
.build()?;
let response = client.get("https://ic0.app").send()?;
println!("Status: {}", response.status());
Ok(())
}
Specific Issue:
“My requests are consistently returning a 403 Forbidden error. I’ve reviewed similar issues on the forum and Discord, and I found that it might relate to canister authentication or signature validation. Are there additional steps or configurations I need to take to gain authorized access to ic0.app? For instance, is it necessary to use Internet Identity for specific configurations, or are there other methods of authentication suitable for both mainnet and testnet?”
What I Hope to Learn:
“I’m looking for insights on the correct way to configure authentication when calling the IC API in Rust and whether there is a specific process to avoid the 403 error. Any relevant experience or advice for further troubleshooting would be greatly appreciated!”
Hey @EdenCapital,
Based on the 403, I assume that you are trying to access a canister that is not available under ic0.app. Just replace ic0.app with icp0.io and try again (see this thread for some explanation).
If the issue persists, then I need more information from you on what you are actually trying to do (e.g., what URL you are calling). For example, in your snippet above, getting a 307 that redirects to dashboard.internetcomputer.org is the expected behavior.
1 Like
Yes, my goal is to use the Rust agent (GitHub - dfinity/agent-rs: A collection of libraries and tools for building software around the Internet Computer, in Rust.) to connect to an ICPSwap Pool Canister (e.g., mohjv-bqaaa-aaaag-qjyia-cai) from Rust and interact with its interfaces.
However, despite several attempts, I keep encountering the “Unknown TLS backend passed to use_preconfigured_tls” error. Here is the error output:
thread 'main' panicked at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/ic-agent-0.11.1/src/agent/http_transport.rs:62:18:
Could not create HTTP client.: reqwest::Error { kind: Builder, source: "Unknown TLS backend passed to use_preconfigured_tls" }
stack backtrace:
0: rust_begin_unwind
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panicking.rs:645:5
1: core::panicking::panic_fmt
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/panicking.rs:72:14
2: core::result::unwrap_failed
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/result.rs:1653:5
3: winicp_wkrust3::main
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
After analyzing this issue, it seems to be related to connecting to https://ic0.app. To simplify the testing, I tried making a basic request to https://ic0.app and received a 403 Forbidden status in response.
Following your advice, I also tested with https://icp0.io, but the result was still a 403 Forbidden. However, when I tested with https://google.com, the request succeeded with a 200 OK status.
Here’s the code snippet I used for testing these links:
rust
use reqwest::blocking::Client;
use std::error::Error;
fn main() -> Result<(), Box<dyn Error>> {
let client = Client::builder()
.use_rustls_tls() // Enforce the use of rustls
.build()?;
let response = client.get("https://icp0.io").send()?;
println!("Status: {}", response.status());
Ok(())
}
Can you try with https://icp-api.io?
1 Like
I tried https://icp-api.io, the result is the same: Status: 403 Forbidden.
I also opened https://icp-api.io through my browser and it jumped to https://dashboard.internetcomputer.org/ quite normally.
ic0.app and icp0.io are similar, which confused me much.
I’m using Docker to download the Image from dfinity/icp-dev-env:latest, everything is officially from Dfinity, so I can’t really figure out why? Are none of you experiencing this problem?
I can’t really say, as I never use agent-rs. I mentioned https://icp-api.io because that’s the domain I use for my project and those of the foundation when connecting the JavaScript agent on mainnet.
1 Like
Thanks for sharing.
What confuses me the most right now is the inability to get to the root of the problem. I’ve also tried JavaScript agent and it doesn’t have this problem. So, I think it might be an agent-rs issue, or something else that I can’t understand at the moment.
I wonder if there is any way to get more targeted help, for example from the agent-rs development team.
Hey @EdenCapital,
The 403 that you see is not coming from ic0.app/icp0.io/icp-api.io, but from dashboard.internetcomputer.org. When you just try to request the root of the three domains, you will be redirected to the IC dashboard. The dashboard has some policies in place, which lead to the 403 (you can see that by changing the redirect policy or simply making a direct request to dashboard.internetcomputer.org). So, also there nothing unexpected is happening.
In order to help you with your actual call to the ICPSwap Pool, it would be great if you could share what you are actually trying to do (e.g., what method you are trying to call on which canister).
2 Likes
I’m not sure exactly what it was, but eventually the problem was solved.
It may have been a configuration issue with one of my environments that caused the 403.
But thank you very much for the reply from your Dfinity team, it made me find different paths to try to get to the root of the problem.
2 Likes