IPFS Authentication Error 403 - Forbidden

Questions
24

Any update on this ? We still get 403 - Forbidden

25

Do you mind explaining this? Iā€™ve never faced this type of problem before and am still learning about API requests

26

Disable the user-agent blocker.

27

how would you do that?

28

I was able to get around this in my Remix application by setting up a backend api route and pinging that and essentially using the same calls above looks like this is broken in the browser

29

Unfortunately this broke at the worst possible time for me. Would this work if I set up a backend, have to probably use python backend in my case.

30

Having the same issueā€¦

We are making the API call from the browser so the user-agent/origin headers are both already being sent and we have no way to alter this behavior without introducing a backend.

It seems like according to that github issue that the IPFS node needs to be configured to accept alternative origins

Thanks in advance and let me know if there is something else I can try

31

Itā€™s returning 403 with this exact code. Was working fine yesterday, today itā€™s broken for authorized and unauthorized, everything pretty much stopped uploading

1 Like
32

Hi,

It seems that the reason for most people in this thread have problems is due to this:

If Iā€™m summarising the problem correctly -
Browsers (basically all of which send ā€œMozillaā€ as part of their User Agent header) always send an Origin header according to the spec. Correspondingly the go-ifps node looks for this Origin header when it thinks itā€™s a browser as the client. This seems to be new behaviour (some people above have been authenticating for months OK). go-ipfs does not insist on the Origin header if the User Agent does not contain Mozilla (indicating the client is not a browser.)

If you are accessing the IPFS API from within a browser, then Origin should be sent for you. Your problem may be elsewhere if you are still getting 403.

If you are using curl or code outside of a browser you should not need to send an Origin header. If you do send the Origin header, donā€™t include Mozilla in the string.

I hope thatā€™s correct, Iā€™ll do some testing. If you still have trouble please send your code, especially the headers you are sending with your request.

33

Is there anyway to by pass this issue (any option in ipfs-http-client lib for example).
This is my code that work before

  const authorization =
      'Basic ' +
      btoa(process.env.NEXT_PUBLIC_IPFS_INFURA_PROJECT_ID + ':' + process.env.NEXT_PUBLIC_IPFS_INFURA_PROJECT_SECRET);
    const ipfs: IPFSHTTPClient = create({
      url: `${process.env.NEXT_PUBLIC_IPFS_INFURA_ENDPOINT}/api/v0`,
      headers: {
        authorization,
      },
    });
34

Hi nmaddp1995,

I think the correct way to pass the authentication header is like this:
headers: {
authorization: authorization,
},

You need an authorization key, then the header itself you are building further up as well.

Does that work for you?

35

you can pass a custom user-agent like this:

headers: {
authorization: auth,
ā€œUser-Agentā€: ā€œfoobarā€
}

The problem is that Chrome ignores it, it seems to work in other browsers.

2 Likes
36

so this is on go-ipfs side? how is this resolved? Iā€™m running chrome and sending the requests from my browser and following the recommended solution for the authentication

37

Doesnā€™t work for me on Edge. The user-agent is still being ā€œmozillaā€

Here is my code:

import { create as ipfsHttpClient } from "ipfs-http-client";

const auth = "Basic " + Buffer.from(projectId + ":" + projectSecret).toString("base64");
const client = ipfsHttpClient({
    host: "ipfs.infura.io",
    port: 5001,
    protocol: "https",
    apiPath: "/api/v0",
    headers: {
      authorization: auth,
      "Access-Control-Allow-Origin": ["*"],
      Origin: "https://ipfs.infura.io:5001",
      "User-Agent": "foo"
    },
});

client.pin.add(file) gives 403 forbidden error
38

I met the same issue Is there a way to solve this problem?

39

Itā€™s working for me. Thanks

40

How did you change, i set user agent but chrome still set it to mozila

41

yeah, i try it but it still show 403 error in chrome browser

42

so I tried this in safari. Overwriting user agent appears to work. But it does not work in chrome and I suspect all chromium browsers (tried in Brave as well). so the latest go-ipfs update basically breaks all web3 applications that relies on accessing ifps through browser?

1 Like
43

I thought you guys should revert whatā€™s just get merged or something else because it affects a lot of customer that is using this function on chrome