Allow access to webserver API from other locations

[Azzar]

I'm playing around with the newly released Stream Deck SDK, and am trying to make a Stream Deck plugin that allows sending and receiving actions and data via the web interface.

This works ok for sending actions from the Stream Deck, but for receiving data - in this case a GET/EXTSTATE/key/value request - I run into problems because of the servers cross-origin policy. I get this error:
"No 'Access-Control-Allow-Origin' header is present on the requested resource"

The problem is basically that the Stream Deck runs it's plugin on it's own webserver - that is also on localhost, but on a different port.

Opening up for all cross-origin access is probably a security no-no, but how about the common solution of requiring an API key to be sent with a request?

Alternatively it could be solved if you for a web control surface entry could specify specific ports (or port ranges) on localhost that would be allowed access.

It would be super nice to be able to have a Stream Deck act as a Reaper control surface, and specifically being able to change its layout based on Reapers cursor context, so a solution for this would be most welcome.

[miguelcobain]

I second this feature request.

It would be great if Reaper added the appropriate CORS headers.
It's such a simple thing to add and would unlock many interesting possibilities for building (and hosting) remote UIs!

[mschnell]

What exactly is the request ?

Reaper does provide a web (HTTP) server. Same can be accessed from "anywhere". You can do the web pages (HTTP content) it provides, using a text editor (in the "reaper_www_root" dir).

Such pages can be used by a Browser (providing a GUI that way) or by other appropriate software.

It seems such HTTP-content is where "CORS headers" are supposed to live ?

[miguelcobain]

@mschnell, reaper does provide an HTTP server that serves both the html/js files AND its api for sending the actual commands or get info. That's all perfect.

The problem is that the http api DOES NOT respond with CORS headers. For that reason, we're limited to run our apps in the domain/address that reaper serves.

When you run an application in a browser and your app makes a request to a domain other than the app you're running in, then the browser needs some special headers to know that the server "accepts" cross-origin requests.

What I wanted to do was to host my own web app publicly, let's say at https://reaper-awesome-remote.com. Then, in that app, people would enter the ip/address of the reaper instance they want to control.
This doesn't work because reaper doesn't return the CORS headers, so the browser will fail any request to reaper.

To fix this is really simple. Reaper would just have to return the http header

Access-Control-Allow-Origin: '*'

on every response to allow requests from any domain.
Again, this is only limitation on browsers. Native apps would be able to make this request just fine.

Nowadays, this is more important than ever because you can do so much more in a domain that is secured with ssl (https). You can make your web app look native and unlocks very useful features for a reaper web control (fullscreen with no browser ui, screen wake lock, etc).
https is hard to get right in a local network.

If the devs think this might pose a security risk for some reason, then I think enabling this behind a checkbox would be probably safer.
But I don't think there's anything dangerous.

If this ever gets implemented, my plan is to:
- host the remote web at https://remote.myband.com
- make the app offline ready with service workers
- we then install the web app on our phones and can point it to our reaper instance to control our monitor levels
- because the original domain is running under https we get useful features like Screen Wake Lock API, Service Workers and probably more.

It's such a simple thing to implement but it can unlock many possibilities.
Imagine people hosting their own cool reaper remotes that you can easily install securely and point to your own reaper instance to control.

[mschnell]

Originally Posted by miguelcobain

For that reason, we're limited to run our apps in the domain/address that reaper serves.

I don't understand.
The server in Reaper has the IP address of the computer Reaper runs in. It will answer to any IP address that sends a request.
(OTOH, if "CORS headers" are doable with that server is unknown to me. )

If you set up your own server (software), same might work as a gateway and receive request from anywhere in any protocol and "convert" the communication to standard HTTP traffic it communicates with the Reaper HTTP server. Reaper does not need to know about this.

The "App" would talk with your server (https://remote.myband.com) and not directly "know" about Reaper.

[mschnell]

OTOH, I did a quick lookup regarding "CORS" and it seems you just need to add
Access-Control-Allow-Origin: '*'
in the appropriate files in "reaper_www_root"
(maybe wrong impression)

[Justin]

adding the ability to set arbitrary headers via reaper.ini [csurf_www] header1= etc.

[miguelcobain]

@mschnell I think the confusions stems from the fact that you're assuming that there is a server running at https://remote.myband.com

Yes, we could implement a server there that proxies the requests to the real Reaper server, bypassing any cross domain restrictions that way.
But that's a scenario that adds unnecessary complexity and, in some cases, might not even be feasible:
- if the app could communicate directly to 192.168.0.1, why not? It would be way faster to make the requests within the local network. Again, reaper does not allow for this to happen because it doesn't respond with CORS headers.
- it might not even be possible because we might not always have internet access. I wish to go to https://remote.myband.com (which is offline-ready), install that web app (a PWA) and then that web app would communicate directly to the reaper server. If there is no internet access, then everything would still work beacause the app ois on the phone and Reaper is in the local network.

I made a diagram to explain what's going on:



@Justin setting arbitrary headers via reaper.ini would totally fix this issue, I believe.
Did you mean your comment as a suggestion or were you stating that such a thing is currently possible/planned?

[akademie]

Originally Posted by miguelcobain

...<snip>
@Justin setting arbitrary headers via reaper.ini would totally fix this issue, I believe.
Did you mean your comment as a suggestion or were you stating that such a thing is currently possible/planned?

It is already in

Originally Posted by matt_t

v7.26+dev1028a - October 28 2024

• + Web interface: allow adding extra HTTP headers via reaper.ini [csurf_www] header1=name:value header2= etc [t=216538]

v7.26+dev1028 - October 28 2024

[X-Raym]

Having demo code or tutorial about what need to be done on a reaper web interface to be able to run on a server would be nice !

EDIT: I may not have understood what all this is about, please enlight me.

[mschnell]

What do you mean by "a reaper web interface to be able to run on a server" ?

(Asking because in my language a web interface is a GUI and a server does not feature a GUI. )

No you mean a non-GUI (or "independent GUI") program accessing Reaper via Reaper's HTTP server ?

[X-Raym]

What do you mean (...)?

Actually, I am the one looking for infos here, I can't answer any question😅


I'm looking for explantations about what is this feature, what it allows, how to implement it. The thread isn't very clear about this, it speak to people who already know what all this is about/

[nofish]

Originally Posted by mschnell

What do you mean by "a reaper web interface to be able to run on a server" ?

(Asking because in my language a web interface is a GUI and a server does not feature a GUI. )

No you mean a non-GUI (or "independent GUI") program accessing Reaper via Reaper's HTTP server ?

What's not clear from this picture?
https://forum.cockos.com/showpost.ph...68&postcount=8

[mschnell]

What would you denote a "server" ?

[miguelcobain]

Originally Posted by akademie

It is already in

Amazing! Thank you so much.

Originally Posted by X-Raym

I'm looking for explantations about what is this feature, what it allows, how to implement it. The thread isn't very clear about this, it speak to people who already know what all this is about/

I really can't explain it better than my diagram above: https://forum.cockos.com/showpost.ph...68&postcount=8

But I'll try to reiterate the problems, to hopefully clarify why this is needed and the logic that leads to it:

1. browsers are very strict about where you can request information from
2. if you try to request to a url on a different domain than what the app is currently running from, the browser will fail
3. so, if app is running on domain1.com and the javascript client side (not the server) tries to request to domain2.com, it will block that request

Despite this, there is a way for domain2.com to explicitly allow requests from other domains to be made: by returning CORS headers.

I hope we've now established why we need CORS headers in Reaper. The reason is to be able to request the Reaper remote server from a different domain than the one of Reaper remote server itself.

Now the question might be "Ok, I get it, but why would you ever need that?"

The answer to that question might be one of many reasons:

• simply to make development easier. You might want to run a server on localhost:1234 for development, and you want to control reaper on localhost:8080 (it's still considered a different domain if the port is different)
• web apps have improved a lot. You can do so much with them nowadays. However, some of those things are dependent on the app being served by https. Reaper can't serve HTTPS (and setting up HTTPS on a local server can be a real challenge), so one simple option would be to host the remote somewhere on the web with HTTPS and then that app could directly request Reaper remote server.
• another reason I can think of is to make remotes that can control multiple instances of reaper (either simultaneously or one at a time). You can host the remote somewhere, and then it can directly request whatever Reaper address you want to to give it. Since it will respond with CORS headers, the browser won't block those cross-domain requests.

These are the reasons I could think of. Hopefully this makes this whole feature request clearer.

[X-Raym]

Thanks for the explaination !


I guess I was confused cause the fact I was asking about hosting web interface on remote server raised some other users eyesbrows, yet it seems what this is about (or Instill don't understand ^^)

, so one simple option would be to host the remote somewhere on the web with HTTPS and then that app could directly request Reaper remote server

My question is : how a web remote placed on a server would know how to communicate with your particular instance of reaper ? how the request are send local URL ? (by how I mean code exemple. I you go this road and make such interface, let us know &#128521

[miguelcobain]

Originally Posted by X-Raym

My question is : how a web remote placed on a server would know how to communicate with your particular instance of reaper ? how the request are send local URL ? (by how I mean code exemple. I you go this road and make such interface, let us know &#128521

You could either hardcode a Reaper instance URL if you know it before hand (you can set up a local network with static ip addresses).
Or, (which I think is more interesting), you could enter the Reaper address in the app itself (in a text input or something). Then, store it in localstorage to avoid asking the address again when the user opens the app again. You can make it configurable, basically.

I'm building a UI for my band's live shows. It's very specific as it uses specific custom reaper action IDs.
I could make it more generic and configurable and release it. Or, indeed, even if it is specific, I could release it anyway for others to use it as a basis. I'll try to do that.

However, I found this excellent project which I took a lot of inspiration from: https://github.com/nikarh/reaper-remote-bandui

(That one doesn't ask you for the reaper address. Which makes sense, because you couldn't do that until now)

[vitalker]

Originally Posted by miguelcobain

You could either hardcode a Reaper instance URL if you know it before hand (you can set up a local network with static ip addresses).
Or, (which I think is more interesting), you could enter the Reaper address in the app itself (in a text input or something). Then, store it in localstorage to avoid asking the address again when the user opens the app again. You can make it configurable, basically.

I'm building a UI for my band's live shows. It's very specific as it uses specific custom reaper action IDs.
I could make it more generic and configurable and release it. Or, indeed, even if it is specific, I could release it anyway for others to use it as a basis. I'll try to do that.

However, I found this excellent project which I took a lot of inspiration from: https://github.com/nikarh/reaper-remote-bandui

(That one doesn't ask you for the reaper address. Which makes sense, because you couldn't do that until now)

Perhaps this one will come in handy?
https://forum.cockos.com/showthread.php?t=200154

[X-Raym]

@miguel
Yes, you can just share minimal code, just to see how the request is encoded (is it in a <a> markup, in wwr_req_recur, or anywhere else.

thx !

[miguelcobain]

Originally Posted by Justin

adding the ability to set arbitrary headers via reaper.ini [csurf_www] header1= etc.

In Reaper v7.27, I can confirm that after adding the following to reaper.ini

[csurf_www]
header1=Access-Control-Allow-Origin: *

I do get the header in the response:

Before:


After:


Thank you so much!

[X-Raym]

@miguelcobain
WHy it says Expires in 1997 ?

[miguelcobain]

@X-Raym sorry for the late reply.

The Expires header is sent by Reaper http server itself. It's used to control HTTP Caching in the browser. By sending a date in the past, it makes sure that this response is never cached, which makes a lot of sense for an API response.

More info: https://developer.mozilla.org/en-US/...eaders/Expires

[miguelcobain]

I'm now facing a new problem. My web app served via https can't request a server running at http due to Mixed content restriction in the browser.

So, I'm basically back at square one with the same problem.

I'm thinking that the only option is to run a lightweight proxy alongside reaper that just receives https requests and proxies it to reaper via http (the proxy wouldn't be subject to browser's security restrictions).

Perhaps the Reaper team could think about somehow adding ssl support to their http server. It's 2025, and http without ssl is getting harder and harder to use.

Perhaps we could provide a certificate path in reaper.ini and Reaper would pick it up and use it to serve https?