Plantronics browser integration JS

49 posts / 0 new

Wed, 03/02/2022 - 02:08

crown

Hi, In an Angular9 project, i want to init the plantronics driver for browser. I can see the attached devices on a browser tab open "http://127.0.0.1:32017/Spokes/DeviceServices/Info" or "https://127.0.0.1:32018/Spokes/DeviceServices/Info". But i get CORS error while requesting in the project. I request the device info as below: let xhr = new XMLHttpRequest(); xhr.open('GET', url, true); xhr.setRequestHeader('Access-Control-Allow-Origin', '*'); xhr.setRequestHeader('Accept', '*/*'); xhr.setRequestHeader('Accept-Language', 'en-GB,en-US;q=0.9,en;q=0.8,tr;q=0.7,de;q=0.6'); xhr.send(); This is the error i receive on browser log: Access to XMLHttpRequest at 'http://127.0.0.1:32017/Spokes/DeviceServices/Info' from origin 'http://localhost:8190' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Have you experience the CORS issue as well? Thanks

Thu, 03/03/2022 - 01:51

lcollins

Hi, I have also noticed a CORS header problem with REST API recently and we are currently investigating. Internal ref: SWD-4613 Will let you know once we find a solution or alternative integration option. Thanks, Lewis.

Thu, 03/03/2022 - 11:54

lcollins

Hi, Seems like the cause may be this: https://docs.google.com/document/d/1fdwetZXUz_Q03ZpGwXizq5AE1yn_lMhamUJMwvsHvTU/edit Apparently our JavaScript API was impacted by these pre-flight checks. And as such was impacting me too on Chrome 98, and Edge 98. However, I just updated to Chrome 99 and it's no longer happening. It is also not happening on Chrome 98 arm64 on Mac. Could you check to see if this is the cause for you? Thanks, Lewis.

Fri, 03/04/2022 - 03:03

(Reply to #3) #4

crown

Hi, On Intel Mac; chrome version is Version 98.0.4758.109 (Official Build) (x86_64), it shows up to date thus i cannot update it to version 99. On arm64 Mac;chrome version is Version 98.0.4758.102 (Official Build) (arm64), it shows up to date and still shows the CORS error. What is your exact version on arm64? Thanks

Fri, 03/04/2022 - 03:16

lcollins

arm64 version I got is 98.0.4758.109.

Fri, 03/04/2022 - 03:30

(Reply to #5) #6

lcollins

On my intel mac I have Chrome 98.0.4758.80 - and that gives continuous CORS errors in the inspector, and call control with the sample app doesn't work https://pltdev.github.io/Plantronics%20JavaScript%20Sample.html However, I've just allowed Chrome to update itself via ... > Help > About Google Chrome. It is now on 99.0.4844.51. This version on same sample app doesn't give any CORS errors/warnings, and the headset call control now works with this sample, i.e. ring/incoming call button, then call answer/end with headset Talk button.

Mon, 03/07/2022 - 02:41

(Reply to #6) #7

crown

Hi, update was available for me today. So i updated the chrome version to Version 99.0.4844.51 on Intel Mac. Still same error occurs. Access to XMLHttpRequest at 'https://127.0.0.1:32018/Spokes/DeviceServices/Info' from origin 'http://localhost:8190' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Same error occurs with http://127.0.0.1:32017/Spokes/DeviceServices/Info

Mon, 03/07/2022 - 03:19

(Reply to #7) #8

lcollins

Hi, What service is hosting on localhost port 8190? Could you add to the response headers of that service the Access-Control-Allow-Origin With value of * Which would tell you app that connections to other origins I.e. the Hub REST API are allowed? https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin Further reading: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

Mon, 03/07/2022 - 03:41

(Reply to #8) #9

lcollins

More reading: https://stackoverflow.com/questions/60287223/cors-issue-when-calling-a-localhost-api-hosted-on-one-port-from-another-port “It's the HTTP service that ultimately controls access by specifying appropriate headers in the responses it serves, and the user agent validates the cross origin request where it refuses to proceed if the server didn't indicate it allows requests from the different origin the script was served from -- the response will be discarded and an error will be thrown. In short, you need to add the headers to the responses your REST service at localhost:8501 generates…”

Mon, 03/14/2022 - 01:56

#10

crown

Hi, as you can see in the first message, i already use "xhr.setRequestHeader('Access-Control-Allow-Origin', '*');" in the request. This did not help. Does this line solve the issue on your local system? Or SWD-4613 is still open and being investigated? Thanks

Mon, 03/14/2022 - 05:04

(Reply to #10) #11

lcollins

Hi, You cannot set that header Access-Control-Allow-Origin * in the request. It needs to be set in the response headers by the http server that server your script, i.e. http://localhost:8190. Regarding the SWD-4613, this is not being investigated as it has now been reported to Google, as follows: https://bugs.chromium.org/p/chromium/issues/detail?id=1302953

Tue, 03/15/2022 - 02:44

(Reply to #11) #12

crown

Hi, btw i updated the plantronics hub on mac Intel to version 3.24.0. Plantronics hub is open and i have one attached device. Chrome, Safari, Firefox shows nothing except this site cannot be reached or unable to connect. Is there a known issue with the last version? Because also i lost the connection from node.js electron. With the previous version my electron app was listed on plantronics hub softphones list.

Tue, 03/15/2022 - 03:23

#13

crown

Hi again, i removed the updated version and installed Plantronics Hub again. Now electron app is displayed again in the softphones list. And i can see the device info on http://127.0.0.1:32017/Spokes/DeviceServices/Info on Chrome, Safari. Since the response is sent by http://127.0.0.1:32017/ , it makes sense that the Plantronics Hub adds Access-Control-Allow-Origin', '* to the response. Is that possible?

Tue, 03/15/2022 - 09:12

(Reply to #13) #14

lcollins

Hi, I made a basic electron hello world app, following this: https://www.electronjs.org/docs/latest/tutorial/quick-start I then added the REST API javascript sample to the app from this code: https://github.com/plantronics/pdc/tree/master/JavaScript%20Sample The file Plantronics JavaScript Sample.html which I renamed index.html for this demo. Take a look at this screenshot: https://developer.plantronics.com/files/electronhelloworldwithhubrestapipng I didn't get any problems with CORS. Are you using electron in a different way that is causing different behaviour to what I'm seeing? C:\dev\elechello\my-electron-app>npm -v 8.4.0 C:\dev\elechello\my-electron-app>node -v v16.13.2

Tue, 03/15/2022 - 09:28

(Reply to #14) #15

lcollins

Actually in my case electron is reading index.html, spokes.js etc as local files, rather than serving them from a web server...

Tue, 03/15/2022 - 11:16

#16

lcollins

update, I've reproduced issue now with an Angular app. I will now look for workaround...

Tue, 03/15/2022 - 11:32

(Reply to #16) #17

lcollins

Hi, I have found 2 web sites that describe how to overcome cors issues with Angular apps. Both involve changing the angular app hosting. This one: https://www.stackhawk.com/blog/angular-cors-guide-examples-and-how-to-enable-it/ And this one: https://www.techiediaries.com/fix-cors-with-angular-cli-proxy-configuration/ Could you try the suggested approaches and let me know? Thanks, Lewis

Tue, 03/15/2022 - 12:06

#18

lcollins

Further update I got it working (angular app able to make http request to Hub REST API) by one of the suggestions of creating a proxy configuration. Details to follow…

Tue, 03/15/2022 - 12:24

(Reply to #18) #19

lcollins

Here is the method I followed to create a proxy config for development. And here is a screenshot of a successful http response from Hub REST API to my angular app: https://developer.plantronics.com/files/angular-works-hub-rest-api-proxy-configpng For a production server that is hosting your app, I think you would need to follow the other advice to enable cors on the server side, which would effectively set Access-Control-Allow-Origin *. Note you could also set Access-Control-Allow-Origin for just the specific hosts used by Hub REST API, which would be more secure, e.g. 127.0.0.1:32017 / 127.0.0.1:32018

Wed, 03/16/2022 - 06:56

(Reply to #19) #20

crown

Can you pls share the code how you make the request to get device info? Because i tried that proxy solution before and it did not work for me.

Wed, 03/16/2022 - 07:08

(Reply to #20) #21

lcollins

Here you go. I think the relevant files are proxy.conf.json and app.component.ts, where I am actually doing an http.get of the /api URL (the proxy), rather than http://127.0.0.1:32017/Spokes/DeviceServices/Info which was causing the CORS error: https://developer.plantronics.com/system/files/anghello2%20copy%20without%20modules.zip

Wed, 03/16/2022 - 09:39

#22

crown

Thanks for the code. This solution works on with ng serve. Means it is not valid for production with ng build. Is it possible that Plantronics Hub adds the Access-Control-Allow-Origin * to the response? This would be the simplest solution.

Wed, 03/16/2022 - 13:44

(Reply to #22) #23

lcollins

I’m not sure that would solve the problem. From all the guidance I read online and shared in previous links, the access-control-allow-origin is an http response header that needs to be applied by the web server that is serving your Angular app. Without it the browser displaying your app will not allow connections to other resources with other origins (like Hub REST API) that are not specified in the access-control-allow-origin (or a value of * means your app can connect to other resources with any url). I have hosted other web pages (html/JavaScript) that used Hub REST API, and to overcome cors issue, I set a custom response header of access-control-allow-origin * in the web server that is hosting the web page. Then browser displaying my web page allows it to connect to Hub REST API without cors error.

Thu, 03/17/2022 - 06:56

(Reply to #23) #24

crown

Even if this is the only solution, then we can avoid CORS error only when the app is served. Not the builded app for production. So we cannot publish a version with Poly browser integration as i understand.

Thu, 03/17/2022 - 07:14

(Reply to #24) #25

lcollins

Certainly the solutions discussed previously work when the app is served. Could you clarify the detail of how the app is built for production, so I may investigate?

Tue, 03/22/2022 - 02:25

(Reply to #25) #26

crown

Hi again, "ng build" is used for production build. So proxy solution works for "ng serve" but does not help us for serving the node web server. Thanks for your investigation and help on that CORS error. After the discussions we made with my colleagues, we decided to wait until the CORS error is fixed by Plantronics Hub or Google team. Then we can make the Plantronics browser integration without any problem. We would appreciate if you may share the future updates on CORS fix. Thank you, best wishes.

Tue, 03/22/2022 - 05:53

#27

lcollins

Hi, Once you've used "ng build", which server do you deploy it to? (As per https://angular.io/guide/deployment) Thanks, Lewis.

Tue, 03/22/2022 - 08:30

#28

crown

Hi, we use our own server. If you try to test the ng build command with proxy implementation, you may test "ng build --watch" easily. It serves the app like "ng serve" does.

Thu, 04/14/2022 - 05:44

(Reply to #28) #29

lcollins

Hi, I'm still trying to get some feedback on this. Are there any developments from your side? Thanks, Lewis.

Thu, 04/14/2022 - 07:27

#30

bkellner

Hello! I noticed that you are accessing spokes api via 127.0.0.1:32017 and you are reaching your angular application via localhost:8190. Does the issue occur if you access the angular app via 127.0.0.1:8190 instead? If you get the same CORS failure, what response do you get from http://127.0.0.1:32017/Spokes/DeviceServices/Info if you send the request via Postman desktop app? Where do you plan on hosting the angular application for production? Keep in mind that Chrome is deprecating direct access to private network endpoints from public websites as part of the PNA specification. Chrome is starting to send CORS preflight requests ahead of any private network request for a sub resource to ask permission from the target server. You can read more about this here, as these changes are still on-going: https://developer.chrome.com/blog/private-network-access-preflight/ What method of communicating with the API are you using? Angular offers some methods to make http requests through the http client module, but you can also use other packages like axios, or even ajax, the fetch api, or xmlhttprequest...

Wed, 08/31/2022 - 14:41

(Reply to #30) #31

mladewski

Has anyone been able to successfully publicly host a custom integration with the Spokes SDK that communicates with localhost without hitting the CORS issue? The only site that I see working is the demo site hosted at https://pltdev.github.io . It seems this should be a simple configuration on the Plantronics Hub Controller Web Server to allow CORS traffic, but I must be missing something. Any help would be greatly appreciated. FYI development with Angular Proxy works fine. As other have stated, its when you try to host that we run into the CORS issue. Thanks,

Thu, 09/01/2022 - 06:02

#32

mladewski

I am going to answer my own question on this one to make sure others are able to follow. To get around CORS, the API supports jsonp requests. The simple "http.get" will not pass CORS. here is a quick example of how to use jsonp in Angular. ngOnInit() { this.getResponse().subscribe( res => { console.log(res) }) } getResponse() { return this.http.jsonp(myURL, 'callback').pipe( map(response => { console.log(response); }) ); }

Thu, 09/01/2022 - 06:05

#33

lcollins

Hi, Are you saying with jsonp you have overcome the CORS issue using Hub REST API from your hosted Angular app? I do recall the spokes.js file that comes with Hub SDK used jsonp... Thanks, Lewis.

Mon, 09/12/2022 - 14:19

#34

jmh

Hi, I've done some testing regarding browser integration but not had much luck yet. For XHR to work Access-Control-Allow-Origin response header must be set to the requesting site (or asterisk) by Plantronics Hub. For the JSONP approach, this almost works. But the headset button interactions are lost since each request resets the result list, and the browser always sends a OPTION request preceding the actual request. To fix this Plantronics HUB must not reset the result list on OPTION requests, only on GET's. Also, I've been unable to connect at all to version 3.24 on mac os, 3.23 works, very strange. Please let me know what I'm missing and how to proceed with the integration. Best regards

Tue, 09/13/2022 - 01:02

(Reply to #34) #35

AWhite

Good Morning @jmh, I'd say you are discussing two separate issues here. Your second issue relating to 3.24 on Mac OS not allowing you to connect to the REST API is a known issue with 3.24. A fix is underway, and will be included in 3.25. Your first issue has been reported by a couple of people over the last week or so. First off a little background. Back in Chrome 98, Google introduced 'pre-flight checks' for CORS requests. These were removed again in Chrome 99 or 100, due to them causing too much trouble. These checks have been added back into Chrome 104 and higher. These checks are the 'OPTIONS' checks you refer to in your comment. We have a process ongoing internally to identify with a resolution. There is no release information available at this time.

Thu, 09/15/2022 - 10:41

#36

lfagundes

Hello Folks Is there a release date for these fixes ? I have been impacted by the preflight issue as well. Thanks.

Fri, 10/21/2022 - 01:06

#37

andreas.paita

Hello do you have a date to communicate for the patch ? Best Regards

Mon, 10/24/2022 - 04:14

#38

lcollins

Hi Andreas, Will try to find out the status and provide an update. Thanks, Lewis

Wed, 11/02/2022 - 02:43

#39

lcollins

Hi Andreas, Hub 3.25 is targeted to have the fix and available later in November. Thanks

Wed, 11/02/2022 - 05:21

#40

andreas.paita

Hello thank you for your feedback. We will test the new version. Best Regards

Wed, 11/02/2022 - 05:21

#41

andreas.paita

Hello thank you for your feedback. We will test the new version. Best Regards

Wed, 11/02/2022 - 05:21

#42

andreas.paita

Hello thank you for your feedback. We will test the new version. Best Regards

Mon, 11/21/2022 - 05:07

#43

lcollins

Hi, We are targeting the week of Nov 28th for the Hub 3.25 release with these fixes. It will be posted here: https://www.poly.com/us/en/support/downloads-apps/hub-desktop with the corresponding SDK package posted here: https://developer.plantronics.com/softphone-integration-hub-sdks Thanks, Lewis,

Wed, 12/07/2022 - 06:56

#44

mladewski

Release imminent?

Wed, 12/07/2022 - 06:56

#45

mladewski

Release imminent?

Wed, 12/07/2022 - 07:31

#46

lcollins

Yes, should be week of 12th Dec now.

Fri, 12/16/2022 - 04:21

#47

AWhite

Good Afternoon All, Hub 3.25 has been released. You can download it through the Poly Hub page (https://www.poly.com/gb/en/support/downloads-apps/hub-desktop) or through your PMP tenants. The matching SDK has been added to this site (https://developer.plantronics.com/softphone-integration-hub-sdks) Regards, Alasdair

Mon, 01/30/2023 - 06:05

#48

crown

Hi, If the Plantronics Hub is online, REST call has no error. But when the Hub is offline (closed), i get "GET http://127.0.0.1:32017/Spokes/DeviceServices/Info net::ERR_CONNECTION_REFUSED" or with https " GET https://127.0.0.1:32018/Spokes/DeviceServices/Info net::ERR_CONNECTION_REFUSED" errors. Anyone else has the same issue or? Thanks

Mon, 01/30/2023 - 07:01

(Reply to #48) #49

AWhite

Good afternoon crown Please can we clarify by what you mean by "Hub is offline (closed)". Do you mean when Hub is not running at all? or do you mean when hub is running in the system tray? Hub is the web server for the REST endpoints. If Hub is not running, then there is no web server listening at 127.0.0.1:32017 or 32018. ERR_CONNECTION_REFUSED is a typical response when there is no server capable of providing the resources you request. This is often wrapped into a 502 error code. If you mean that you are getting that response when Hub is not running at all, then that is normal behaviour, and can be used to help identify if Hub is running - you could periodincally try to connect, and if you get ERR_CONNECTION_REFUSED, then you could go to sleep for a defined amount of time, and try again later. When you no longer get that response you can know that Hub is now running, and begin your main application code.

Add new comment