How to make caller verification

Developers
1

I know this is might silly questions but how can I

  1. Validate where is current frontend’s url of caller?
  2. Make sure client who is calling the method, is using our frontend not other 3rd or direct from canister.

I want to only accept user from our frontend call to backend method and reject any request from other sources.

2

Others can confirm, but if you want a “quick” feeback, out of the box, I believe this isn’t possible. The request hitting your endpoints contains no trace of the caller other than their principal.

You could maybe switch to an http_request_update API approach, but you’d need to find a way to pass the caller’s identity yourself. I’m not sure it’s worth the effort or cost, and there are probably other pros and cons to consider.

But again, this is just quick feedback—if I’m wrong, I’d be happy to be corrected.

1 Like
3

Hmm, I heard that @NathanosDev are working one same thing like you said.

But It would required more work to convert api to using http gateway.

Thanks for helping

4

It’s not possible to restrict incoming canister/http requests to a particular domain, there might be http headers you can check but those can be spoofed.

You might need a proxy to spoof these headers within a browser context, but even that is relatively straightforward e.g. a CORS proxy is only a few lines to implement.

The primary method to e.g. avoid spam is a captcha prompt during user sign up.

If the concern is regarding another service using your canister implementation for free, make sure that either only your own canisters or authenticated users can call it.

5

I believe this is achievable. The rationale:

  1. Backend must verify the identity originates from a specific domain
  2. II-generated identities are indeed domain-bound, with forgery prevention enforced by browsers
  3. However, domains are hashed during II identity generation - userPublicKey can’t validate domains (ref: internet-identity/src/internet_identity/src/delegation.rs at main · dfinity/internet-identity · GitHub)
  4. We could implement a custom II system where userPublicKey carries domain info for backend validation. Could even restrict identity usage to your system via delegation targets.

A simpler approach: Implement a Sign-In proxy service between your App and II. This service can:

1. Handle the login flow for your App
2. Generate verifiable proof of the origin domain
3. Provide this proof to your App for backend verification

When calling backend services, your App includes this origin proof for validation.

2 Likes