# IPFS Webapp Detect Local Node **URL:** \ **Category:** Uncategorized\ **Created:** [September 12, 2020, 11:24pm UTC](https://discuss.ipfs.tech/t/ipfs-webapp-detect-local-node/9049 "2020-09-12T23:24:23Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![logasja](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/logasja/32/4103_2.png) [@logasja](https://discuss.ipfs.tech/u/logasja)\ **Post date:** [September 12, 2020, 11:24pm UTC](https://discuss.ipfs.tech/t/ipfs-webapp-detect-local-node/9049/1 "2020-09-12T23:24:23Z")
Hello! I am building a webapp and would like to be able to connect to a local daemon if possible. However when trying to connect to localhost:5001 for the API I run into the CORS issue. Ideally I wouldn’t have to ask my users to change their IPFS daemon settings to allow CORS, does anyone know a way to modify the outgoing headers of the ipfs-http-client to change the origin or some other CORS solution? Thanks! ---
**Author:** ![hector](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/hector/32/178_2.png) [@hector](https://discuss.ipfs.tech/u/hector)\ **Post date:** [September 13, 2020, 9:18am UTC](https://discuss.ipfs.tech/t/ipfs-webapp-detect-local-node/9049/2 "2020-09-13T09:18:16Z")
> > ---
**Author:** ![logasja](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/logasja/32/4103_2.png) [@logasja](https://discuss.ipfs.tech/u/logasja)\ **Post date:** [September 13, 2020, 2:54pm UTC](https://discuss.ipfs.tech/t/ipfs-webapp-detect-local-node/9049/3 "2020-09-13T14:54:17Z")
So, there is no way of doing this without asking users to change their CORS settings on the daemon then. ---
**Author:** ![hector](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/hector/32/178_2.png) [@hector](https://discuss.ipfs.tech/u/hector)\ **Post date:** [September 14, 2020, 8:11am UTC](https://discuss.ipfs.tech/t/ipfs-webapp-detect-local-node/9049/4 "2020-09-14T08:11:30Z")
Depends what you want to do. I think the gateway endpoint has CORS enabled by default, so you can make reads through that. ---
**Author:** ![logasja](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/logasja/32/4103_2.png) [@logasja](https://discuss.ipfs.tech/u/logasja)\ **Post date:** [September 14, 2020, 5:15pm UTC](https://discuss.ipfs.tech/t/ipfs-webapp-detect-local-node/9049/5 "2020-09-14T17:15:01Z")
I’d like to provide the site’s visitor’s the option to pin the site to their node as a show of support, this is especially useful if they have a daemon that is always on (e.g. IPFS desktop). Plus the IPFS HTTP API is a much smaller package to provide when loading. Maybe I’m thinking about this wrong. ---
**Author:** ![hector](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/hector/32/178_2.png) [@hector](https://discuss.ipfs.tech/u/hector)\ **Post date:** [September 15, 2020, 8:12am UTC](https://discuss.ipfs.tech/t/ipfs-webapp-detect-local-node/9049/6 "2020-09-15T08:12:38Z")
@lidel does IPFS companion permission-management help for this? ---
**Author:** ![logasja](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/logasja/32/4103_2.png) [@logasja](https://discuss.ipfs.tech/u/logasja)\ **Post date:** [September 15, 2020, 5:40pm UTC](https://discuss.ipfs.tech/t/ipfs-webapp-detect-local-node/9049/7 "2020-09-15T17:40:26Z")
IPFS Companion would be perfect, but as far as I know the window.ipfs interface is still not functional as of now. ---
**Author:** ![lidel](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/lidel/32/9853_2.png) [@lidel](https://discuss.ipfs.tech/u/lidel)\ **Post date:** [September 20, 2020, 11:53pm UTC](https://discuss.ipfs.tech/t/ipfs-webapp-detect-local-node/9049/8 "2020-09-20T23:53:06Z")
We’ve disabled the `window.ipfs` experiment some time ago because it exposed regular JS API that caused [breaking changes](https://github.com/ipfs-shipyard/ipfs-companion/issues/852) due to [async await refactor](https://blog.ipfs.io/2020-02-01-async-await-refactor/) (not to mention user fingerprinting issues). It may come back in some shape or form, but it will be a much smaller and more robust subset of APIs. Exposing full API on the web is too risky, we need to be very careful and follow the security model on the web, and we need a versioned, stable web-specific API to avoid issues like the one linked above. If you are interested in following this problem space, we are tracking it in: > > > This is a placeholder for tracking open problems and related issues / notes > Embedding js-ipfs on a page binds it to specific... @logasja regarding your use case specifically (“option to pin the site to show support”), we will have an improved flow for that in browser extension at some point ([details](https://github.com/ipfs-shipyard/ipfs-companion/issues/888#issuecomment-689713119)), removing the need to trust website with access to the API.