Jump to content

Calling the API and hitting CORS


Recommended Posts

Does anyone have any experience on accessing the eurapi api outside of Hornbill?

We have a customer app that I wrote several years ago in PHP and Laravel. It uses an API KEY and fetches some info from Hornbill using the xmlmc and works ok. Now I'm looking at migrating my app to a fresher environment still using Laravel, but moving the front end to Vue.js.

I thought I'd just rewrite my PHP xmlmc into JavaScript and all would be well. But I didn't allow for CORS.

At present the PHP app acts as a kind of proxy where the client browser asks the server for data and the php xmlmc fetches it and hands it out to the browser. So no CORS issue here.

In the world of Vue.js I was hoping to pass off the calls for data out to the client browser. So then the servers load is lightened and the clients round trip speeds up as they get the response hot from eurapi.

I'm making a call to a "generic" user that is assigned tasks and I just want to use the task/taskGetList at this stage but in the browser ran into:

Failed to load https://eurapi.hornbill.com/xxxxxxxxx/xmlmc/task/taskGetList: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://192.168.56.2' is therefore not allowed access.

Where the 192.168.56.2 is my virtual test server.

So is this because eurapi won't allow CORS? And am I wasting my time?

Link to comment
Share on other sites

@Bob320

This is not something that has come up yet but we do have the ability to allow different domains into the Options Accept Origin Header for each customer, currently, this is not something we have had to expose for any customer. I will raise this internally to get an answer for you.

In the meantime, you can pretend to be any *.hornbill.com subdomain which will pass our CORS checks.  

Just out of interest other than browsing tasks assigned to a generic user what other functionality are you trying to get from this application? 

Kind Regards

Trevor Killick

Link to comment
Share on other sites

Hi @Bob320,

Aside from the CORS check issue, I noticed that you've mentioned you'll be making XMLMC calls using an API key for a generic user in the frontend JavaScript. This isn't very secure - anyone who has access to the web app (and therefore can see the API calls being made in the browser developer console) will be able to read the API key and use it to initiate any API calls that the generic user has rights to... I'd suggest you keep the API calls server-side, to protect the key from your web app users.

Kind regards,

Steve

Link to comment
Share on other sites

2 hours ago, Steve G said:

Hi @Bob320,

Aside from the CORS check issue, I noticed that you've mentioned you'll be making XMLMC calls using an API key for a generic user in the frontend JavaScript. This isn't very secure - anyone who has access to the web app (and therefore can see the API calls being made in the browser developer console) will be able to read the API key and use it to initiate any API calls that the generic user has rights to... I'd suggest you keep the API calls server-side, to protect the key from your web app users.

Kind regards,

Steve

Yeah I get that. But as we're only able to use the app within an environment that meets compliant device checks, or is within a "walled garden" and is within the corporate domain it's not a major concern. If our users can trawl minified js and figure that out I want them working for me :D

Ultimately I may stick with the server end xmlmc, just thought a client side would provide a faster UX.

@TrevorKillick the primary role of this app is to allow non-Hornbill users the ability to authorise the procurement of equipment. So the service work flow assigns a task to our "generic" user that needs to be authorised.

My app then monitors the task list, queries the service request and does a looks up on a Hornbill list of who can authorise that task based on a cost centre that is passed as one of the questions. Then emails the non-Hornbill user to get their authorisation. Which My app then caries out by proxy. So the work flow can then continue to the next step.

image.png.693cb8e2cf719d264a7198f03462c507.png

Thanks for the responses though. Very useful to know so I can make a decision which way to go..

Link to comment
Share on other sites

@Bob320

I was reading your post with interest.  As @Steve Goldthorpe the CORS checks are there for security reasons, notionally we *could* expand the list of domain names as previously mentioned but we would need a very good reason to do so that was not in conflict with our security controls.  As for the API Key I would be very concerned for the security of your data if you expose the API key to your end users - you may well be in a controlled domain but as we know most security attacks originate from within trusted groups.

That aside, I wanted to mention that what you are doing (creating a generic user and writing an app to enable non-users of our solution to authorize workflows) is actually in conflict with our subscription/licensing intent.    We have two types of defined users on our platform, those that are "users", we call these collaboration/process users, and those that are "guests/basic", which are users that are in receipt of the support services "users" provide.   Our basic policy is, those users who participate in the provision of service, which includes authorizations that drive workflow, and those users who are in receipt of the support service being provided.  The former requires a subscription, that latter does not.   The way in which we facilitate this is to provide collaboration/platform subscriptions which as you know can amongst other things authorize BPM generated tasks/authorizations, but these users require a subscription.  it would seem to me from your description above that you are circumventing that licensing policy by using a generic user account to enable non-subscribed users to participate in the workflows that are being used to provide the service you are offering.  Are you aware of this?

Gerry

Link to comment
Share on other sites

This is a feature not available within Service Manager, for which we originally asked for and were assured it would do, but doesn't.

It was originally part of our Support Works capabilities, but like many other Support Works features we lost when we upgraded to the "new improved" Service Manager.

Link to comment
Share on other sites

@Bob320

It is possible for anyone to authorize and complete tasks, even via email if they are a collaboration/process user.  Are you saying that we have misrepresented what the product can/cannot do in order to convince you to adopt the solution? if so would you be kind enough to provide more details? which feature are you saying should be available which is not?

There were many possibilities in Supportworks that are not possible in Service Manager because Supportworks was a development environment whereas Hornbill Service Manager is not, they are in that regard very different solutions.  We have a prescribed way of supporting authorizations on the Hornbill platform, in Supportworks it was possible to basically build whatever you want.  However, our license policy on Supportworks was always based on the same principles of requiring those users that were providing the support service, including authorizers would require a user license.  In fact, in Supportworks, we had a specific authorizer license, but in practice, those customers that were capable of doing the development work themselves would simply work around it. 

Thanks,
Gerry
 

Link to comment
Share on other sites

The key part here is "those users that were providing the support service". Which those with authority are not. Budget holders who sit outside of the IT service and are typically managers of other non-analyst type users who put in a request for service that requires expenditure.

For example: as a non-IT user I request a laptop using the Service Manager "request stuff" portal. My manager must authorise the expenditure before IT can begin to service the request by purchasing or supplying a laptop. The manager has no access to Service Manager, but must be notified someone wants something from their cost centre and then authorise IT they can proceed with the expense.

Link to comment
Share on other sites

@Bob320

Quote

The key part here is "those users that were providing the support service". Which those with authority are not. Budget holders who sit outside of the IT service and are typically managers of other non-analyst type users who put in a request for service that requires expenditure.

I think this is a matter of interpretation so for the avoidance of any doubt let me try to clarify.  Hornbill is fundamentally a business process automation tool.  Service Manager is an app that runs on our platform and is built with business process automation at its heart. 

In your example above you are describing a service being delivered to a non-IT user, actually, it can be any user that you deliver service to, the service being in this case, order a new Laptop computer.  Once they initiate the request, you will be running a business process which will orchestrate the required activities needed to fulfill the request for service.  In the circumstance you are describing above, the budget holder is required to "approve the spend", without such approval the service cannot be delivered, therefore the budget/spend approver is in fact a required function in the *fulfillment process* of the service being delivered, and in our subscription model, that person is considered "an approver" for the purpose of delivering service - the fact they are not a Service Manager app user is not relevant   As you probably know, an approver or task participant on our platform is required to be a platform/process user (not a service manager user) in order to approve a task.  You stated...

Quote

My app then monitors the task list, queries the service request and does a looks up on a Hornbill list of who can authorise that task based on a cost centre that is passed as one of the questions. Then emails the non-Hornbill user to get their authorisation .Which My app then caries out by proxy (presumably by a single generic user account using an API key). So the workflow can then continue to the next step.

which appears to suggest you want to develop an app that removes the need for your approvers to be Hornbill process users and/or approvers, yet provide approvals for service requests to progress, which is in conflict with our subscription and licensing intent - this is why approvers and task users are required to have a Hornbill Process User subscription.
 

Quote

This is a feature not available within Service Manager, for which we originally asked for and were assured it would do, but doesn't.

Can you please confirm one way or the other if you believe we misled you here, I take this very seriously, I would be personally mortified if we have misled you, if we have I very much want to get to the bottom of that ASAP. 

Thanks,

Gerry

Link to comment
Share on other sites

Back in year zero when we had SW Hornbill came in and created the authentication process for us and all was good. When we migrated to Service Manager we knew we'd lose some functionality, but we were assured that BPM would resolve the authorisation process. But it looks like what was left unsaid was - "Yes, you can make the BPM process do that... but you'll need to purchase Analysts licenses for everyone who authorises expenditure."

Link to comment
Share on other sites

Hi @Bob320

Quote

 but we were assured that BPM would resolve the authorisation process. But it looks like what was left unsaid was "Yes, you can make the BPM process do that... but you'll need to purchase Analysts licenses for everyone who authorises expenditure."

Can I just clarify that you DO NOT require an analyst subscription to be an authorizer, you need a collaboration/process subscription which is significantly lower cost, like 1/10th of the cost and less with volume.   I am 99% sure we would have made that clear to you as part of the process of talking to you about the migration, I will be deeply concerned if we have misled you and set the wrong expectations, so I would like to get to the bottom of that.  I will drop you a PM as I would like to know who at Hornbill you dealt with and what you were told/led to believe.

Gerry  

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...