Xojo Web + proxy issue caused by X-Requested-With

Targets Web
1

I have a Xojo Web app that works fine on most networks, but fails behind a customer’s corporate proxy (ProxySG / Blue Coat).

We traced the issue to X-Requested-With: XMLHttpRequest being added to Xojo’s client requests (via jQuery), which causes the browser to require a CORS preflight. The proxy appears to block or mishandle that preflight.

Removing X-Requested-With at the XHR level seems to resolves the issue and eliminates the preflight.

Is this a known issue with strict proxies?

Is there a better way to handle this?

Thank you for your help!

1 Like
2

I don’t see this mentioned in the issues database.

You could of course report it there as a bug or make a feature request.

I See the X-Requested-With in the jquery-3.5.1.min.js file. It would be simple to just patch that out, e.g. by changing a text “X-Requested-With” e.g. “X-DisabledOption”. Just a little shell script to modify the file and overwrite the two positions with X-Requested-With with the new text.

3

Thanks for your help, Christian!

My customer is running into issues with my app again, despite no changes on my side. I’m guessing there may be several factors involved, potentially linked to a very defensive IT department.

Has anyone experienced something like this?

4

Not something that Xojo should though as it could break other things.

2 Likes
5

If I’m not mistaken, this is one of the reasons jQuery 4.0.0 has migrated most requests to script tags from XHR (unless they include request headers). CORS security has been tightening significantly across server environments, and it can be a real pain to trace and mitigate the resulting issues.

I’d argue that it’s the job of the IT department to ensure that what’s needed for the project is provided in as limited scope as necessary, not to simply say “Nope, that’s not happening here.”

1 Like
6

Hello!

I directly asked Ricardo about my problem, and he suggested allowing my app to be executed in an iframe (Self.Security.FrameOption = WebAppSecurityOptions.FrameOptions.Allow). That did the trick, it worked!

I am not sure why this resolved the issue, but I wanted to share the fix anyway in case it helps someone else.

Thanks for your help everyone!

1 Like
7

Thanks for sharing this @Sébastien_Poisson =)

Xojo adds the X-Frame-Options: SAMEORIGIN header by default, and it looks like it wasn’t working fine with that corporate proxy. The browser log you’ve sent me made me suggest you to disable that header.

I don’t know exactly how that proxy works, it was kind of blind shot. Glad it worked :sweat_smile:

2 Likes
8

Blind shot? Of course. Don’t worry, your code-god identity is safe with me.

1 Like
9

The only way that should be possible is if the domain attached to the jQuery request is not the same as the page it’s sitting on. Now… if the thing that’s giving you trouble is an htmlviewer that contains another webpage that has its own jQuery stuff, that I could see causing this… because it’s an Iframe essentially. That would explain why wrapping your app in an iframe with those security options worked. If my theory is correct though…you may be just hiding a security hole from your customer. Basically, that security option is saying “hey proxy, I know this is weird but you can trust me!”

1 Like
10

Following up on this: the iframe solution only worked for a short period. It appears that the customer’s proxy initially treated our application as a new app after the change, but it later flagged it as potentially harmful and revoked its long-connection privileges (I think).

The resolution was to ask the customer’s IT team to add an exception for our application in their proxy.

2 Likes