[bossanova808]

Ok, lately I have been working on a little personal project - a '2nd screen' for Kodi where I use a tablet which shows a clock and weather, normally, but then switches to a nice 'Now Playing' type view when Kodi is playing some media.  It then shows the artwork, the time remaining, and a mini clock and weather info thing. 

I've used fairly standard modern approach (Vite for building, AlpineJS for reactivity, Tailwind for styling).  I deploy to Github Pages (which serves over https only as per really any modern server thing).
 
Then, from any browser I can call my app by going to its url, and I pass the local Kodi IP & and a weather location code as parameters - and then my Now Playing display ' just works'.  

I decided on a web browser approach (vs. say some sort of electronics approach, Arduino + a screen or whatever) - because I have a bunch of old tablets, phones, etc, as I imagine most people do by now.  One could also use a Raspberry Pi...basically, anything that can run a browser.  Being a web app, in theory it's 'write once, deploy on any browser supporting platform'.

I'm fairly familiar with using the JSON-RPC from Python - which is easy and works well.  I suppose one could investigate the new Python in the browser developments, but nothing there looks ready for prime time yet.

So - to Javascript.  Unfortunately, things are a bit more problematic, with modern Javascript and Kodi.
 

• Kodi does not set CORS headers (and work on this seems to have halted - https://github.com/xbmc/xbmc/pull/12252) - so the default modern approach (fetch) - can not be used at all.  Without faffing about with running a proxy between Kodi and this client (which would basically add the CORS headers, e.g. - https://github.com/Rob--W/cors-anywhere), I don't think there is a workaround if you want to use the default modern approach to fetching remote resources in JS.
  
  
• Websockets is an alternative and there are no CORS issues.  You also get notifications, which is cool - means you can avoid polling.  Seems great...but Kodi does not support wss - secure web sockets - only ws.  This forces one to bypass browser security features that block non secure content being sent over a secure connections (workarounds for common browsers here: https://www.damirscorner.com/blog/posts/...tions.html - but e.g. iOS won't let you do this at all, so all Apple devices are out).  It then works, but it's far from ideal.
  
  
• Using older libraries with modern build approaches and reactive frameworks is...painful/impossible.  Apparently there are some older libraries (atomic, good ol'jquery/ajax) - that just seem to ignore CORS (which really makes a mockery of any security CORS might in theory provide...).  This is not a Kodi thing, just a general thing about JS - which, from a packaging/lib/versions perspective is a god-awful mess, generally.  (Looking at Kodi web interfaces, it seems old libraries are the way those tend to go...I see lots of jquery...)
  

I think that's a fair description of the state of play currently.  Am I missing anything, or misunderstanding anything?

Given Kodi basically doesn't currently meaningfully support any security other than basic authentication w. JSON-RPC (e.g. there's nothing for websockets) - is there any reason Kodi couldn't just set a CORS allow anywhere header (if the settings for 'allow control...' are appropriate).  That would solve the issues with fetch, at least.   And one could push the rest of the debate about CORS and auth down the road, again, I guess. 

Alternatively, could Kodi not come with a certificate (or have some mechanism for installing one) - to then enable WSS?  Although that seems more complicated...

Apologies if this reads like a rant.  I've got my think working well, and I can do the browser workarounds (for now, at least) - but it all feels a bit messy.

[izprtxqkft]

i love what youre going for here @bossanova808
tell me bluntly if im not welcome to comment on this, i can take it im fully grown

that being said, proxying is really sort of meh, a third wheel to the perfect date etc and so on but is a wss server built into an addon severely out of the queston?
it would be a "proxy" but, not, sort of... made more sense before i started typing but anyway here i am, here's a quick something to look at - https://websockets.readthedocs.io/en/6.0/intro.html

i havent looked at the web server addons which ive been meaning to but can wss be built into one?


lastly ive recycled old tablets and phones for odd things like this before and if youre using android check out the full screen browser, its perfect for the job - https://play.google.com/store/apps/detai...eenbrowser

[bossanova808]

that being said, proxying is really sort of meh, a third wheel to the perfect date etc and so on but is a wss server built into an addon severely out of the queston?
it would be a "proxy" but, not, sort of... made more sense before i started typing but anyway here i am, here's a quick something to look at - https://websockets.readthedocs.io/en/6.0/intro.html

lastly ive recycled old tablets and phones for odd things like this before and if youre using android check out the full screen browser, its perfect for the job - https://play.google.com/store/apps/detai...eenbrowser

Well, that's a possibly solution I suppose (an addon) - but a solution more at the source of the issue (i.e at Kodi itself) would be of much greater benefit and more applicable, and there's wouldn't be another layer of latency etc...

(Yes, on Android, as OS is ruled out by the 'no mixed content' rules (shame as I have some old iPads...) - I use Fully Kiosk web browser at the moment, working well, but I will check that one out too.

[izprtxqkft]

i see what youre going for, native implementation, that would in fact be quite awesome and in my own opinion very very easy

i dont want to assume what level anyone is on so im going to put out what i know and if its a "no sh" to anyone reading thats fine

what i do know is that a socket connection to the json rpc server on kodi has live events, ive used it, its rather nice

what else i know is that a socket and a websocket are only 1 http request in difference, ive also done this too.

when requesting a websocket there is an http handshake, at the end of which the socket is accepted by a real socket server the same as whats already implemented in kodi

i used this to create a web interface to an existing VT120 telnet server that i wrote 20 years ago - websockify https://github.com/novnc/websockify

not saying it should be used as is but its code is a great template for what you want

[bossanova808]

Yep, I'm really looking for input at the Kodi level, thoughts from Kodi devs etc.  It's an area where Kodi is close but would really benefit from some modernisation.  But at the least, throwing on a CORS header when the system has been explicitly opened seems sensible/easy and would allow modern JS to be used.

[wsnipex]

just fyi, kodis webserver supports SSL for years on unix platforms: https://github.com/xbmc/xbmc/pull/13165

[bossanova808]

That's interesting.  Does that apply to the websockets side of things as well?  All my Kodi boxes are CoreElec - is that unix enough, or...?

[wsnipex]

tbh, I don't really know how the websocket implementation works, so no idea how that applies to it.
And CoreElec certainly is unix enough, provided that they build microhttpd with SSL support. If they do, you should have the option in settings

[bossanova808]

Hmm, I've not seen that option.  Will ask over there, but suspect they don't do so currently.  And in this context it would be useful for the websockets (mixed content) side of things - SSL won't solve the CORS issues with fetch, unfortunately.

[bossanova808]

Looks like they do build with https support:

 https://discourse.coreelec.org/t/microhttpd-ssl/20428/3

But I've never seen that option. Anything else needed for it to come up?

[wsnipex]

microhttpd requires gnutls, not sure if that has changed since openssl has switched to a gpl compatible license

[bossanova808]

So CoreElec does support SSL, I was somehow just looking straight past the option. Thus, I will have a play with it soon, see whether or not it works for web sockets as well.  But I anticipate self generated certs will raise their own issues...

(Another solution is to serve my app over plain http, so the content is then not mixed, of course.  But of course that requires having my own server - all those static deploy things are all https these days (which is a good thing, generally!).