With a Sonos player, adding local service to customSD does not show up Music Services - sonos

I have the starting shell of a SMAPI service programmed in Node.js. The service is running off of a local IP address.
When I goto the customSD page for my Sonos Play:1 and add the service details to it and it returns 'Success!' upon clicking submit.
When I open the Sonos Controllers on both my desktop and mobile, the service does not show up in the list of music services you can add.
I have logging on the server turned on to max and there are no connection attempts ( either SSL or HTTP ) at all.
From what I've read, a running service is not needed for it to show up in the list. Once it's added via customSD it should show up in the Music Service settings.
TO NOTE: A self signed cert is being used for https for connection testing only. I have certificate request logging turned on and there is NO connection attempt from the Sonos Play:1 to the local server at all. From everything I've read this shouldn't matter as it should show up in the Music Service list until you try to add it and then it will connect to the service.
The only thing I can think of is if this service needs to be registered with Sonos before it can be added via customSD, however at this time nothing I've read says that.
The other thing is if this service needs to be running off a domain name for some reason. However in the documentation it lists IP address so it would be bad documentation then.
I expect the service added via customSD should show up in the list. It does not appear when clicking on add.

Understood the issue and YvesGrantSonos has updated the documentation.
If you're developing locally a non-https IP address should be used for both the secure and non-secure API URI's.

You should be able enter a local IP address for the SMAPI service. For testing, this should be on the same local network as the Sonos player. Be sure to include the port number that the service is running on (i.e. http://192.168.1.2:8080/musicservice). You can use the same IP and port for secure and insecure connections.

Related

Is HTTPS required for any Sonos service in a developer sandbox?

I have the Sonos Acme developer test service setup and running but my Sonos Player doesn't seem to be able to connect. I'm wondering if a TLS SSL certificate is required no matter what even in a sandboxed environment.
I'm running the java service on a remote AWS instance behind a domain. The service is setup with the default installation details. It does not log any sort of connection attempt once I add the service to the Sonos player via customSD.
Accessing the Sonos Player via customSD and adding the Acme service does respond with Success! But again it doesn't show up in the service list. Manually pulling the WSDL does work correctly via the http request.
Also to note that Sonos seems to be in the middle of creating it's new developer portal and since last Monday ( June 24th ) the new portal no longer references the Acme test service. I'm wondering if this is due to it no longer being valid and it's documentation out of date (est. 2017-2018).
I expect the service to show up in the Sonos Controller when adding a new service but it doesn't appear and the log doesn't show any attempts to connect.
An SSL endpoint is required for production, but you can use a non-SSL endpoint for testing. See the comments in this answer for details: With a Sonos player, adding local service to customSD does not show up Music Services

openshift ssl edge termination risk

I have been reading the Openshift documentation for secured (SSL) routes.
Since I use a free plan, I can only have an "Edge Termination" route, meaning the SSL is ended when external requests reach the router, with contents being transmitted from the router to the internal service via HTTP.
Is this secure ? I mean, part of the information transmission is done via HTTP in the end.
The connection between where the secure connection is terminated and your application which accepts the proxied plain HTTP request is all internal to the OpenShift cluster. It doesn't travel through any public network in the clear. Further, the way the software defined networking in OpenShift works, it is not possible for any other normal user to see that traffic, nor can applications running in other projects see the traffic.
The only people who might be able to see the traffic are administrators of the OpenShift cluster, but the same people could access your application container also. Any administrators of the system could access your application container even if using a pass through secure connection terminated with your application. So is the same situation as most managed hosting, where you rely on the administrators of the service to do the right thing.

How to access localhost via https with a valid certificate

We have a Web-Application that should interact with a desktop application that has a helper tool character (e.g. no setup, no need for admin privileges). The helper is listening via http/https on a simple port bound to localhost.
The Web-Application uses a SSL certificate. Every customer has a machine on its own for his data. For claryfication: The Web-Application is running on a server, serving one customer but multiple people.
The problem is, the Web-Application cannot reach the helper tool via https (using image or iframe). The main issue is, that the local webserver listening on localhost has no signed certificate. So the web browser is blocking the interaction.
Is there any way to get around this trouble? I think, I cannot get a certificate for localhost, because no one would sign it.
I know, that I cannot use XMLHttpRequest for this, but that's not the point.
The goal is to have a customer friendly - no install - just works - solution. The customer should not do ANY configuration. Just downloading and starting the tool. We'd like to have a direct communication to the tool (e.g. no outbound direction to the web server).
Is the any solution for this?
If it is Active-directory environment , you can create your own CA and sign certificates and distribute them across the domain. also you can add to trusted sites through domain policies this way client side you don't need to configure anything .

Foursquare Realtime User API

I have a problem with my app that I want to use as sink for the push POST requests. I programmed it in Java as a straight forward servlet, I verified that I can send POST requests to it, but the test push from my consumer’s admin page says 404.
Is it possible that I can’t run the push sink on another port than 80? My secure Tomcat port is 8888. I don’t see any calls from the Foursquare servers in my Tomcat access log.
Thanks!
As stated in Realtime API self signed certificate 4sq seems currently not to be able to send POST requests to other ports than 443 (standard SSL).
I worked around this by using the mod_jk connector to let Apache2 send requests to a special directory directly to Tomcat7. This works for me.

captive portal authentication theory

I'm a little confused on how captive portal authentication works. In some implementations, after a user is authenticated with a login page, their IP and MAC address are whitelisted and allowed to connect through the gateway. Obviously this has the problem of people spoofing MAC addresses to gain access. If the portal sets up a session between itself and the client, does that mean that every piece of traffic that the client requests from the internet must go through the portal's server?
Generally, security in a captive portal is not considered particularly important. However, there are solutions that lock a MAC to the first port to use it and disallow the use of that MAC on any additional port. Similar techniques can be used wirelessly, where the AP will refuse to pair with an additional client using the same MAC address as an existing client. This requires enterprise authentication where a unique key is negotiated for each attached device.
It's not clear to me what you mean by "the portal's server". But generally, once a MAC address is authorized and the wired port is configured or the wireless connection is established, nothing further needs to be done by the portal. The traffic for authenticated connections is just routed/NATted normally.