1

The priority-web-sdk .login function returns a BADREQUEST when included by script on a webpage using the following sample code:

<script 
    src="https://cdn.priority-software.com/upgrades/var/api/v1.5/priorityapp.nocache.js">
</script>
<script>

    var config = {
        url: 'https://www.eshbelsaas.com/ui/',
        ...
    };

    function priorityReady() {
        login(config).then(
          onsuccess=>
          {
              console.log('Your are in!! Enjoy!');
          },
          reason=>
          {
              console.log(reason.message);
          }

</script>

The full body of the message is as follows:

XMLHttpRequest cannot load www.eshbelsaas.com/…/service.svc. Response to preflight request doesn't pass access control check: No ‘Access-Control-Allow-Origin’ header is present on the requested resource. Origin ‘null’ is therefore not allowed access. The response had HTTP status code 400.

The same behaviour is exhibited by:

  • Chrome
  • Edge
  • JavaScript UWP Apps

I am however able to NPM the package in node.js and log in with the same config settings:

var priority = require('priority-web-sdk');

var config = {
    url: 'https://www.eshbelsaas.com/ui/',
    ...
};

priority.login(config)
    .then(() => priority.formStart('CUSTOMERS', null, null, 'demo', 0))
    .then(form => form.getRows(1))
    .then(rows => console.log(rows))
    .catch(err => console.log(err));

Although at this point I get a permissions error.

Debugger listening on [::]:5858
{ type: 'apiError',
  code: null,
  message: 'Privilege required for \'Customers\' form (internal name = CUSTOMERS, company = Demo Company). Contact your system manager.',
  form: null,
  fatal: true }


Update 2.

As per @leor|s comments I have added access-control headers to the /wcf on a v18 server.

telnet erpdemo.emerge-it.co.uk 80
GET /wcf/wcf/service.svc HTTP/1.1
HOST:erpdemo.emerge-it.co.uk


HTTP/1.1 200 OK
Cache-Control: private
Content-Length: 6437
Content-Type: text/html; charset=UTF-8
Server: Microsoft-IIS/7.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: POST, GET, OPTIONS, HEAD
Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept
Access-Control-Allow-Credentials: true
Date: Wed, 21 Jun 2017 10:42:04 GMT
...

Unfortunately while the clientUI no longer identifies the missing Access-Control-Allow-Origin header, the preflight still fails:

XMLHttpRequest cannot load https://erpdemo.emerge-it.co.uk/wcf/wcf/service.svc. 
Response for preflight has invalid HTTP status code 400

Can I confirm what headers are required for the pre-flight please?

2 Answers2

1

origin error you can read about it here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS

In order to solve this you need to set a proxy that will make the server requests for you. I am actually not sure why you don't get the same error when running with NPM. Are you doing something different when running from NPM?

For your permissions problem - what username are u using?

neomib
  • 3,503
  • 4
  • 17
  • 27
  • 1
    Cross-Domain restrictions are enforced only browsers because only they are vulnerable to XSS attacks. The proxy is required only during app development since in production your HTML will typically be hosted on the same origin as the service. – Leor Jun 18 '17 at 08:54
  • Would a proxy add the cross site "Access-Control-Allow-Origin" header to the server side? see:[link](https://stackoverflow.com/questions/33164596/no-access-control-allow-origin-header-is-present-on-the-requested-resource-r) – Simon Barnett Jun 18 '17 at 09:00
  • @Leor - Ah, so the "Access-Control-Allow-Origin" is deliberately omitted from the server headers to prevent cross domain calls, because the client would normally be served from the same domain? Is there any way round this for testing against the https://www.eshbelsaas.com/ui/ sandbox (using apidemo as user) please? What do you mean by a proxy? – Simon Barnett Jun 18 '17 at 09:12
  • The username 'apidemo' has permissions to access the following forms: ORDERS and its sub forms:AGENTS and EXTFILES. Also this username has permissions for the direct activation 'WWWSHOWORDER' in ORDERS form. – neomib Jun 18 '17 at 09:24
  • @NeomiBushary Ahh, that's excellent, thanks. I'm now seeing records returned in node.js. Can you give a bit more info about using a proxy to get past the cross domain issue for client design please? – Simon Barnett Jun 18 '17 at 09:37
  • How exactly are u running ur client? We are using Ionic and setting our proxies in a json file. I googled it a bit and found this link: http://www.makeuseof.com/tag/create-online-proxy-server-minutes/ Is that helpful? BTW completely missed the part u said ur running npm from node.js :| – neomib Jun 18 '17 at 10:13
  • Thinking on about this, and I have some concerns about how this will work in practice. Surely this restriction means that a website provider hosting http://www.mytradingname.tld will be unable to interact with Priority data hosted by our customer at, say, https://priority.myholdingplc.tld because of the cross site restrictions? – Simon Barnett Jun 19 '17 at 14:20
  • As @Leor suggested: ` One way to work around this is on the server side, by adding a special header to the HTTP response instructing the browser not to enforce the policy. Since this defeats the purpose of the policy, server admins are reluctant to do this.` If you are building a mobile application you wont have this problem – neomib Jun 20 '17 at 05:23
1

About proxies:

All web browsers implement a policy called Same-Origin. It's a preventative measure against various types of Cross-Site-Scripting (XSS) attacks.

This policy mandates that browsers block requests to API servers (in your case, the eshbelsaas.com domain) if the origin of the HTML page from which the page was issued differs from the API domain.

One way to work around this is on the server side, by adding a special header to the HTTP response instructing the browser not to enforce the policy. Since this defeats the purpose of the policy, server admins are reluctant to do this.

Another way to work around it is on the client side, by inserting a web proxy between the browser and the API server. The browser sees the proxy as the origin for both the HTML page and the API calls, so API calls will get through.

Many web development environments provide integrated proxies exactly for this purpose, check the documentation for your IDE to see if yours does too.

Leor
  • 1,252
  • 11
  • 12
  • Thanks for that! - I tried to hack an http redirect: [img](!http://tinypic.com/r/2hf6lup/9) but the package still detected the 302'd file as being from a different domain to the client.js. I'm using VS, but I guess I can wait till we have a shiny new v18 server to host the client on the same url as the service.wcf. – Simon Barnett Jun 18 '17 at 12:20
  • @Leor can you elaborate more on this? When referring to HTTP headers are you referring to Access-Control-Allow-Origin? Can you explain how that defeats the purpose of CORS? If I set the Allow-Origin to "my-other-domain.com"? Can you share more about how a web proxy would be set up? How would this be more or less secure? Should I understand from your answer that Priority only supports API/SDK calls from within the priority server? This feels like it would limit the ability to create services for our clients. – Abe Jan 24 '18 at 09:48