Can the plugin support host ip rather than 127.0.0.1

[kchen0x]

My PC's IP address is 10.0.x.x. And I tried call the local api with both 127.0.0.1 and 10.1.x.x:

GET / HTTP/1.1
Authorization: Bearer xxx
User-Agent: PostmanRuntime/7.29.0
Accept: */*
Postman-Token: c702eb23-b467-4516-98d8-ad4a4338cf41
Host: 127.0.0.1:27123
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
 
HTTP/1.1 200 OK
X-Powered-By: Express
Access-Control-Allow-Origin: *
Content-Type: application/json; charset=utf-8
Content-Length: 152
ETag: W/"98-/ubTTso4uaXjt2NmuEnNOi94qUE"
X-Response-Time: 0.627ms
Date: Mon, 25 Apr 2022 03:54:03 GMT
Connection: keep-alive
Keep-Alive: timeout=5
 
{
"status": "OK",
"versions": {
"obsidian": "0.14.6",
"self": "1.3.1"
},
"service": "Obsidian Local REST API",
"authenticated": true
}

It works. However:

[coddingtonbear]

No -- this plugin is intended for local use only, and thus intentionally binds only to localhost.

[Gavin-Gong]

No -- this plugin is intended for local use only, and thus intentionally binds only to localhost.

Hi, Can we add support access from other IP devices on local network? By exposing LAN IP e.g. 192.168.1.2. So that other devices can make an obsidian API request via 192.168.1.2.
If you accept this idea, I would be happy to submit a PR to implement it. And thanks for your plugin.

[coddingtonbear]

I'm right now fairly opposed to enabling that sort of support given that it dramatically increases the risk profile of a plugin like this. Although most of the time a local network like 192.168.* or 10.* is your home network and probably reasonably safe, local IP addresses can also be handed out by users' office networks, airport or coffee shop WIFI hotspots, and sometimes even honeypots.

I really don't have anywhere near the time necessary to vet the libraries used here now and in the future (as new versions of these libraries are released, they need to be re-vetted) to the degree that would be needed for me to be comfortable supporting non-local access to folks' notes via this plugin. I might be able to justify that if there were more contributors willing to take on that responsibility after they'd demonstrated some kind of long-term willingness to do that, but at the moment, we're really far from that point.

For now, what I'd recommend for such cases is just to open an SSH tunnel between the machines you'd like to access this API from. I do this regularly myself given that I do not want to run Obsidian on, for example, my work laptop, and instead add an .ssh/config entry like this:

Host somehostname
User someusername
HostName somehostname
LocalForward 127.0.0.1:27124 127.0.0.1:27124

If you do that, the computer from which you have run your ssh somehostname command will be able to connect to the rest API running on somehostname:27124 via connecting to 127.0.0.1:27124. This adds essentially no additional risk and would probably solve this problem in all reasonable use cases that i can think of.

Sorry for not being easily convinced that this is a good idea! Don't read this as the end of discussion, though; I could still be convinced, and maybe you'll be able to do that.

[Gavin-Gong]

Sorry for the delay response. I appreciate your understanding of cautious attitude towards not exposing LAN IP addresses.
In the future, if sufficiently many users request the ability to expose their LAN IP, we can consider offering a dangerous button that allows users to voluntarily choose to expose their LAN IP after being informed of the risks.
However, in my case, the SSH solution you proposed has already effectively solved my issue. Thanks a lot.

[JamborJan]

I'm trying to use the Obsidian local REST API extension in combination with Obsidian Remote to enhance some automation. E.g. I want to "star" posts on Mastodon and have them add to my daily note for further processing. Therefore I need the API working within a docker container behind a traefik proxy. Is there a work around for that? I tested a bunch of things which are not working. Only after these tests I found this discussion. Would be great to get some help.

FYI, some details about my current tests and setup.

To Reproduce
Steps to reproduce the behavior:

1. Startup container as described in the example yaml below
2. Install the obsidian-local-rest-api extension, enable http only API access
3. Add the port for the API
4. Run curl in the container of obsidian remote: curl localhost:27123, you'll get the status info of the API
5. Run curl from another client with the proper working traefik service: you'll get something like this: curl: (7) Failed to connect to 172.29.52.3 port 27123: Connection refused
6. You can setup also a port mapping from the container to the docker host. curl will not work as well, the error will be something like this: curl: (7) Failed to connect to 192.168.0.1 port 27123 after 111 ms: Couldn't connect to server

Expected behavior
I would expect that exposing the API port 27123 would work exactly like port 8080 works. In the described setup exposing 8080 works. The same doesn't work for 27123. Thats the used docker-compose.yml:

services:

  obsidian:
    # source: https://github.com/sytone/obsidian-remote/pkgs/container/obsidian-remote
    container_name: obsidian
    hostname: obsidian
    image: ghcr.io/sytone/obsidian-remote:0.1.1
    restart: unless-stopped
    user: ${UID}:${GID} #PUID=1000:PGID=100
    expose:
      - 8080 # UI
      - 27123 # REST API insecure
      - 27124 # REST API TLS
    environment:
      - PUID=${UID}
      - PGID=${GID}
      - TZ=Europe/Zurich
      - KEYBOARD=de-ch-qwertz
    volumes:
      - '${CT_DATA_BASEPATH}/container/obsidian/vaults:/vaults'
      - '${CT_DATA_BASEPATH}/container/obsidian/config:/config'
    labels:
      - "traefik.enable=true"
      # UI
      - "traefik.http.routers.obsidian.rule=Host(`obsidian.${INSTANCE}.domain.tld`)"
      - "traefik.http.routers.obsidian.entrypoints=websecure"
      - "traefik.http.routers.obsidian.tls.certresolver=mytlschallenge"
      - "traefik.http.routers.obsidian.service=obsidian"
      - "traefik.http.services.obsidian.loadbalancer.server.port=8080"
      # API
      - "traefik.http.routers.obsidianapi.rule=Host(`obsidianapi.${INSTANCE}.domain.tld`)"
      - "traefik.http.routers.obsidianapi.entrypoints=websecure"
      - "traefik.http.routers.obsidianapi.tls.certresolver=mytlschallenge"
      - "traefik.http.routers.obsidianapi.service=obsidianapi"
      - "traefik.http.services.obsidianapi.loadbalancer.server.port=27123"
      # IP Whitelist
      - "traefik.http.routers.obsidian.middlewares=TestIP@docker"
      - "traefik.http.routers.obsidianapi.middlewares=TestIP@docker"
      # Basic auth user
      #- "traefik.http.routers.obsidian.middlewares=TestAuth@docker"
      # Flame app dashboard
      - "flame.type=application" # "app" works too
      - "flame.name=obsidian"
      - "flame.url=https://obsidian.${INSTANCE}.domain.tld"
      - "flame.icon=note-multiple-outline" # optional, default is "docker", source: https://materialdesignicons.com/
    logging:
      driver: "json-file"
      options:
        tag: "{{.ImageName}}|{{.Name}}|{{.ImageFullID}}|{{.FullID}}"
    networks:
      - TestDockerLAN

networks:
  TestDockerLAN:
    external:
      name: TestDockerLAN

[JamborJan]

Am I guessing right, that this would be the right part to adjust the behavior:

obsidian-local-rest-api/src/constants.ts

Line 5 in b8db79d

export const HOSTNAME = "127.0.0.1";

Changing this to 0.0.0.0 would make the API listen on all interfaces, right?

Update:
Yes, it is working. Anybody who wants to test this with a non-productive vault: go to .obsidian/plugins/obsidian-local-rest-apiand edit main.js.

Replace:

var HOSTNAME = "127.0.0.1";

with this:

var HOSTNAME = "0.0.0.0";

I cannot say anything about the security implications in your cases. So please handle with care.

[coddingtonbear]

For those of you finding this conversation after-the-fact, I've (after a ton of back-and-forth on this) decided to add this feature, and it was added as part of 371b951. This'll be part of the next release of this plugin -- probably later this week.

I'm a little embarassed to say that what changed here isn't the security risks, but that I, myself, needed to run Obsidian in a container for complicated reasons and although I assumed it wouldn't be too complicated to get it to work, I also couldn't find a reasonable path for exposing the port in a way that it would be accessible outside the container. There probably is a way, I suppose, but, well, this is also now an option, too, albeit one hidden under an "Advanced Settings" section at least.

[motion2082]

Hi @coddingtonbear

I know your post above is a couple of years old but did you end up implementing a feature to allow the API to be called externally?

I have N8N running on https://n8n.myserver.com and trying to make a request to a reverse cloudflare tunnel https://mytunnel.com which points to my Windows PC running Obsidian