Adding HTTP server to desktop version

[msageryd]

I'm struggling to get the callbacks to work.

1. In order to make a request to a non http endpoint I'm using the open npm package
2. I'm using express.js to setup handlers for x-success and x-error callbacks

The data is received correclty, but the open library uses the default browser, so Chrome is opened as soon as I send a status 200 back after getting the callback.

I'm probably doing something stupid or overcomplicating stuff.

Also, I cannot make the request at all without providing the callback urls. Is there no way to just get the data in the reponse body of the initial request?

[czottmann]

Nice to see a fellow dev looking at ActionsURI! 🤙🏼 I'm not exactly sure what you're trying to do there. The receiver is Obsidian, which is hardcoded (because Obsidian registers the obsidian:// protocol), and ActionsURI is getting its incoming data from Obsidian.

I cannot make the request at all without providing the callback urls. Is there no way to just get the data in the reponse body of the initial request?

There is no way, no. These aren't HTTP request, this is XCallbackURL all the way down. Request+response are async by default. The receiver is a black hole, basically, there's no concept of "response body". ¯\_(ツ)_/¯

[msageryd]

Aha, I see.
I don't think my "open" call is the culprit when it comes to the browser opening up. Actions-uri calls my callback uris with window.open(), which I think opens the default browser. I don't know how to mitigate this.

[msageryd]

I have tried the following, and nothing works:

1. using file:// as uri scheme for the callbacks and trying to catch the response in a file
   Didn't work. I don't think Obsidian has permission to write to files.

2. registering a custom uri-scheme, obsidian-callback://
   Same problem as no 1

3. Listening for the callback on tcp (instead of http).
   Doesn't work

How are you able to listen to these callbacks in MacOS actions? Do you have any example code?

To clarify: I can get hold of your response via the callback, but the default browser is also opened, which is a no-go for me.

[msageryd]

Update..
The XCallback concept seems to be quite hard to work with.

I found a library for making it easier on my side. The library works perfect when I communicate with Bear, but I cannot get any callbacks from actions-uri. This makes me wonder if window.open() really is the correct way to initiate the callbacks.

The only way I can get information back is to use a regular http uri for x-success. But As I stated earlier, this concept will always open the default browser as well. I haven't fond any way to mitigate this.

The functions you expose in the actions-uri is perfect for what I need to build, but unfortunately I cannot use them =(

The xcall library:
https://www.npmjs.com/package/xcall

[msageryd]

I think the easiest way would be to have a regular http server like Omnisearch. If I find time I might try to implement this in actions-uri. Unfortunately, I don't have time right now.

https://github.com/scambier/obsidian-omnisearch/blob/master/src/tools/api-server.ts

Edit:
I just noticed that Omnisearch is GPL3, which does not play well with your MIT license. The linked code cannot be used as it is, but it can serve as inspiration.

[czottmann]

The XCallback concept seems to be quite hard to work with.

It's what's mandated by Obsidian. And since (to me) Actions URI is basically "just" the backend for Actions For Obsidian, and working well, I'm fine with that. ;)

This makes me wonder if window.open() really is the correct way to initiate the callbacks.

It is. There's no other way to return x-callback-url (XCU) responses from Obsidian. The Obsidian client environment is not a node env – it may be on desktop but it isn't on mobile.

How are you able to listen to these callbacks in MacOS actions? Do you have any example code?

I use an old app, Lincastor v2.4 (note: not Lincastor Browser). It allows you to register custom protocols with macOS, receives calls to those URLs, and hands them to your scripts. For example, I have x-callback-test:// set up on my dev machine which just logs all incoming calls to a file:

Lincastor's original website is offline by now but still available using the Web Archive: LinCastor App. The download on that page still works, even though it might take a while. I've been using it for years, it's good, it runs on Sonoma w/o issues.

There's also Lord-Kamina/SwiftDefaultApps: Replacement for RCDefaultApps, written in Swift. which lets you see which apps have registered what URL schemes on your local machine. There might be a text editor or other tool that could be used as an XCU receiver.

[msageryd]

Thanks a bunch!
I tried to register a custom scheme, but I didn't "hear" anything getting called back. I falsley assumed that Obsidian (Electron) was not permitted to use custom schemes, so I gave up on that. It seems likely that I made something wrong, I will revisit this concept again.

[czottmann]

IIRC, the first time Obsidian tries to send a request to another app, you'll be asked for permission. That dialog will appear once only.

And Obsidian is not deciding what to do or where to send the outgoing URL, it merely hands it over to macOS/iOS which then passes it on. Obsidian itself has no concept of "another app" here.

[msageryd]

LinCastor worked great, thank you. I have also realised that registering a custom uri scheme is not straight forward, at least not on Mac. It kind of works, but includes some manual handling (adding to plist), etc. This would not let me create a simple reusable Alfred workflow.

Instead I went another route with seems to work very well. I now have a working plugin which "wraps" actions-uri in an http server. This lets me send all actions-uri requests to my plugin via http on a specified port. My plugin awaits the x-callbacks internally and forwards to data to the original request in the response body. The key to this solution is that it's much simpler to register the uri scheme from within Electron, which already have functions for this. I think they will also work on Windows, but I haven't tried yet.

I don't have time to finish this now, but my POC works great.

So, if I would publish this as an Obsidian plugin it needs a name. Would you rather it being a completely separated plugin, or would it be ok to name the plugin "obsidian-actions-uri-server"?

[czottmann]

So, if I would publish this as an Obsidian plugin it needs a name. Would you rather it being a completely separated plugin, or would it be ok to name the plugin "obsidian-actions-uri-server"?

Would your plugin require the user to install Actions URI separately, or what do you have in mind? Because bundling Actions URI as part of your plugin would cause major routing issues in Obsidian.

[msageryd]

Yes, I think it's cleaner to keep them completely separate, in the same way you don't bundle Omnisearch.
My plugin alone will not interfere with anything.

• The endpoint for reaching my plygin will be http://localhost:customPort
• Everything added to this uri will be forwarded to obsidian://actions-uri
• I will await callback on a registered Obsidian protocol handler, currently named actions-uri-server
• Everything I get back in the callback, including any errorCode and errorMessage is sent back in the reponse body to the original request.

Example:

http://localhost:3333/tags/list?vault=my-vault

[msageryd]

Another option would be to make my plugin completely agnostic so it can convert any x-callback based plugin into an http endpoint. Either via a plugin setting (protocol = "actions-uri") or maybe by letting the user add the protocol in the original call, http://localhost:3333/actions-uri/tags/list?vault=my-vault.

In this case I should probably name the plugin something more generic.

[czottmann]

Another option would be to make my plugin completely agnostic so it can convert any x-callback based plugin into an http endpoint.

I like that idea a lot, actually.

maybe by letting the user add the protocol in the original call

The protocol here is obsidian:, the XCU host is actions-uri. But if I read you right, you want to take the original XCU host, path and parameters, and pass the whole set to your server http://localhost:3333/, correct? If so, cool idea.

[msageryd]

Settled then. I'll make a completely separate plugin. I suppose there are some more plugins utilising the x-callback concept since this seems to be standard in Obsidian.

I'll try to sort out my use of terminology. I knew that obsidian: is the protocol. Got a bit carried away with the terminology since I used registerObsidianProtocolHandler to register actions-uri-server.

I'll finish the plugin as soon as I get the time and ping back to you. Will give it another name.

And to clarify, here is an example:

Client makes this request:
http://localhost:3333/actions-uri/tags/list?vault=my-vault

My plugin forwards to:
obsidian://actions-uri/tags/list?vault=my-vault

My plugin awaits callback to a registered Obsidian protocol handler. All data from this callback will be sent back to the original request in the responde body.

[msageryd]

Almost there, but I have a stubborn problem. How ever I try, I cannot make calls to obsidian:// without the Obsidian app is put to front. Do you know of any settings that could mitigate this?

I'm not sure if this is even solvable. When you call window.open(), the opened app is supposed to be brought to front for security reasons, if I'm corectly informed. By registering a protocol handler in Obsidian I mitigated the problem I had in Node, where the default browser opened. At least I have control over the process now and can forward the data in a response body, bit it seems impossible to not put Obsidian to the front.