You are viewing limited content. For full access, please sign in.

Question

Question

Options for Modern Designer Javascript API Calls When Getting Cross Origin Errors

asked on December 18, 2024 Show version history

I do a lot of API stuff from forms.  Nothing too overly complete, these are usually managed by a button that a user clicks that does a simple API call to another system.  An example is adding a note to an account in our accounting system.

I have a couple dozen processes in the Classic Designer that have various API connections like this.  And they work well.

But I'm always trying to see what I can get get working in the Modern Designer, and this is one that I consistently have been unable to make work.

The primary issue I have is that these APIs limit the origins of calls to them.  These are all set-up so that they allow the origin to be the server that is hosting the forms environment or in a couple cases they are running on the same server.  That works for the Classic Designer because the Javascript runs directly on the form and the origin is the server address.

But in the case of the Modern Designer, the Javascript runs in a sandboxed iFrame, which means the origin always shows as NULL.  This results in any attempted calls to these APIs failing with a message like "Access to fetch at '{URL}' from origin 'null' has been blocked by CORS."

We could set the Access-Control-Allow-Origin header on the APIs to allow NULL origin, but that is risky as it opens the server up to anything.

There is an option for the iFrame sandbox called allow-same-origin which would mean the sandbox showed the same origin as the parent window instead of showing NULL.  I have no idea if Laserfiche would be willing to modify the functionality to enable that option on the sandbox or not.  But I'm wondering if they would be willing to consider it?

Or if anyone has any better suggestions?

1 0

Answer

SELECTED ANSWER
replied on December 20, 2024

This is a known issue and on my priority list of things to fix. The sandbox purposely does not have a domain to block DOM traversal and other security holes. We need to give it a known "untrusted" domain to keep the security benefits but allow CORS requests to be made

0 0
replied on December 20, 2024

Fantastic!  It's on your list, which is what I was hoping for.

As long as there is a plan to address it in the future, then I don't mind waiting since I have a working solution in the Classic Designer for the time being.

Thank you @████████!

0 0

Replies

replied on December 19, 2024

My understanding is that the newer interface limits scripting on purpose for security reasons. Is it feasible to process these external actions as workflow actions once the form is submitted?

0 0
replied on December 19, 2024

I agree with the improved security for the most part.

Using Workflow in-between Forms tasks is less ideal for a lot of situations, and adds extra time and steps for staff.

This isn't the most pressing issue, since it does work in the Classic Designer.  But this is an area where I am currently limited to the Classic Designer for this kind of functionality and want to explore options with the Modern Designer instead.

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.