New Request Script for anyone who wants it.

[dblevins]

could this be used for the website to get active playing info

That is already available without needed a script for it

 

[HMMMM]

When i try this with data in my url it transposes it with real data to "http://$rb_server:$rb_port/?pass=$rb_password";

 

[HMMMM]

That is already available without needed a script for it

Yes but it takes up a lot of resources to get from XML then put it into SQL http://deniserose.ezyro.com/music_now_playing.php and i havent managed to work out how to get it into https, which has a http stream, which means mixed formats, which https doesnt like

 

[HMMMM]

You need to enable API in Radio Boss and ceate a password. For the address you need to set up a static ip

Yes i had this done

 

[djsoft]

I don't know how to do that

When you edit a post, select the code and in the toolbar click three dots at the right, then click code.

 

[djsoft]

Yes but it takes up a lot of resources to get from XML then put it into SQL http://deniserose.ezyro.com/music_now_playing.php and i havent managed to work out how to get it into https, which has a http stream, which means mixed formats, which https doesnt like

If you need HTTPS that can be configured in RadioBOSS, but you need a certificate (buy it or create self signed).
See "Using HTTPS" section here: https://manual.djsoft.net/radioboss/en/remote_control_api.htm

 

[HMMMM]

Yes, but my stream is http, not https. I thought you could not mix them? Oh I see you mean the request to RB.

 

[dblevins]

When i try this with data in my url it transposes it with real data to "http://$rb_server:$rb_port/?pass=$rb_password";

I am not able to replicate this on my server

 

[HMMMM]

This could be because of hidden security changes.

1. Early Implementation of the Same-Origin Policy (SOP) (1995–2000s)
   SOP prevents a script on one domain from accessing resources (such as cookies, DOM elements, or files) on another domain.
   This stopped direct JavaScript access to files from other sites.
2. Cross-Origin Resource Sharing (CORS) (2009)
   W3C introduced CORS to allow controlled cross-origin access by requiring explicit permission from the target server.
   Without the correct Access-Control-Allow-Origin headers, browsers block cross-origin requests.
3. Blocking Cross-Origin File Access (2010s)
   XHR & Fetch API Restrictions: Browsers began blocking cross-origin file requests unless explicitly allowed.
   File URI Restrictions: Accessing local files (file://) from a remote webpage was blocked for security reasons.
   Cross-Origin Read Blocking (CORB) (2018): Google Chrome implemented CORB to block sensitive data in cross-origin responses that lack proper CORS headers.
4. More Stringent Fetch Metadata (2020s)
   Browsers introduced Fetch Metadata Request Headers (Sec-Fetch-Site, Sec-Fetch-Mode) to detect and block unauthorized cross-origin resource access.
   Websites can now configure Cross-Origin-Opener-Policy (COOP) and Cross-Origin-Embedder-Policy (COEP) to fully isolate their context.
5. Deprecation of Insecure Protocols & Third-Party Access
   Blocking Mixed Content (2019–2023): Browsers started blocking HTTP resources from loading on HTTPS pages.
   Third-Party Cookie Phase-Out (2024): Google Chrome and other browsers have begun restricting cookies and storage access across sites.