Trigger.io: Android Issue Access Origin Policy - trigger.io

Trigger.io has just updated today and we found the new UI great! But when we run our Application to android Emulator, we suddenly found this issue:
[ERROR] XMLHttpRequest cannot load http://site.com/api/. Origin content://com.sample.android.app is not allowed by Access-Control-Allow-Origin. -- From line 1 of null
[ERROR] Uncaught SyntaxError: Unexpected token o -- From line 1 of
We are trying to access the api and then an error occured. It is working fine in Iphone but having a trouble in Android.
I hope trigger.io can address this issue please.

Trigger apps on Android are served via content:// urls which means they are not permitted to make requests to other domains, on iOS file:// urls are used so this restriction is not in place.
You have 2 options to fix this, either set the Access-Control-Allow-Origin header sent by the server to *, or use forge.request.ajax to make the request. forge.request.ajax uses native code to make the request and so avoids any Javascript security limitations, more documentation is available here: https://trigger.io/docs/current/api/modules/request.html

Related

Running ServiceWorker in Capacitor App on iOS

tl;dr
Essentially i need to set COOP/COEP headers to enable SharedArrayBuffer functionality in my Capacitor v3 iOS App and running a ServiceWorker to set the headers is the only solution i have found so far.
Background to the problem
Both Chrome Android and Safari iOS now support SharedArrayBuffer
which now means Ffmpeg.wasm can utilise multi-threading. SharedArrayBuffer requires a secure context to enable functionality, this is done by setting the following headers;
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin
Further requirements;
The site needs to be served over HTTPS or localhost
The headers have to be set server side (headers cannot be set using meta http-equiv=".." in the head tag)
I've found this problematic in Capacitor to implement. My App is self contained (App files served locally), it doesn't require external http requests to serve the App files. This means setting the required headers server-side isn't an option.
The Work-around solution
The following solution suggests using a ServiceWorker to set the COOP/COEP headers client-side, which is exactly what i need. Enabling COOP/COEP without touching the server
The Problem
ServiceWorkers have their own set of requirements and this is where i'm stuck.
To enable this ServiceWorker API on iOS i'm using App-Bound Domains.
The following issue in github Support deploying a PWA with capacitor as native app outlines the steps required to implement App-Bound Domains in Capacitor.
Which include;
Adding a list of your domains incl. server.hostname / localhost to Info.plist.
Enabling limitsNavigationsToAppBoundDomains in your src - capacitor/capacitor.config.json
After setting App-Bound Domains i can the following error;
serviceWorker.register() must be called with a script URL whose protocol is either HTTP or HTTPS
This happens because Capacitor apps are served from capacitor:// in iOS.
Is there anyway around this? ( that does not require serving from a remote url).
Or has anyone discovered a better approach to setting COOP/COEP headers client-side in Capacitor?
Thanks Cam

Network Error on iOS emulator from Capacitor App

I am using Angular Capacitor v3 with axios. Receiving a Network Error when making any request to any external server. This is only occurring while emulating with XCode. The request never reaches the server, just returns immediately with status 0.
I cannot repeat this problem locally on Windows, or published website, or Android Studio emulators, or published to android device.
Not sure if I am missing a permission or configuration, but I have tried adding "Local Network Usage", "Location Always and When In Use" permissions and played around with NSAppTransportSecurity settings to the Info.plist.
I do not believe its an issue with the server since it seems like it never even reaches it. But I have a verified HTTPS certificate, hosted by Azure, with valid CORS rules.
I have also tried HttpClient with Angular, same result.
The error occurs immediately and does not give specific information but here is the message:
{"headers":{"normalizedNames":{},"lazyUpdate":null,"headers":{}},"status":0,"statusText":"Unknown
Error","url":"https://jsonplaceholder.typicode.com/users/1","ok":false,"name":"HttpErrorResponse","message":"Http
failure response for https://jsonplaceholder.typicode.com/users/1: 0
Unknown Error","error":{"isTrusted":true}}
After extensive research and rebuilding from scratch, I found this was a CORS related issue but specific to setup with Azure, which was my hosted server. The confusing part was that even external example calls, such as to "http://jsonplaceholder.typicode.com/users/1" still gave the same error, which wouldn't have CORS issues, as far as I understand. If anyone knows why that happens, please let me know.
This was related to the fact that in ios, the http/https schemes cannot be used, instead it uses capacitor. This scheme is not allowed in Azure App Service CORS settings, unless you allow all, but I could not because I needed to enable Access-Control-Allow-Credentials. So I had to build the CORS configuration with the capacitor scheme allowed in my C# app service code. Removing all settings from CORS in Azure App Service then allowed the settings in my C# code to be applied.
I am just facing same issue
It was working on different domain, no hostname is different and it stopped working.
So it doesn't even make a request to a server.
Also same configuration works on android. just not IOS

Safari Web Extension background request CORS issue

I am working on Safari Web Extension on on iOS 15, everything seems smooth so far except one thing:
The fetch request from background.js will always fail since it is cross origin and hence throws CORS error.
If I add the "Access-Control-Allow-Origin: *" in server, the request is completed without any error. However, we are reluctant to allow all origins.
Solutions tried
Access-Control-Allow-Origin: safari-web-extension://<guid>
Access-Control-Allow-Headers:< some request header we sent >
This didn't work because the GUID changes every-time the app is installed.
Any advice to resolve this?
Thanks a lot

Can I use the Google Picker API in an electron app?

I'm trying to use the Google Picker API to display a picker for the user to select a file. I have this working great in a web app (in a normal browser), but when I run the same code in an electron app, I see a 400 message in the popup iframe, and get the following console errors:
Failed to execute 'postMessage' on 'DOMWindow': The target origin provided ('https://docs.google.com') does not match the recipient window's origin ('file://').
Failed to load resource: the server responded with a status of 400 ()
The core problem seems to be that the electron browser window has an origin of file://. This seems to cause two problems:
The (chromium) browser security blocks the cross-origin iframe communication
Google rejects the request as not coming from a valid origin (and you can't add file:// as an origin in the developer console)
I can't think of any way to overcome these problems, but I'm hoping that someone has an idea.
You could create an app and host it in something like following, and then point the electron BrowserWindow to the url.
https://app.yourdomain.name/gdrive/picker?token=access_token
That should work I believe.

Office365 API App registration fails: Bad Request

When registering an app at https://dev.office.com/Getting-Started/office365Apis, I get the following error:
The following error occurred while processing your request:
ERROR: Request_BadRequest - Invalid value found for property 'identifierUris' of resource 'Application'.
I have registered an another app successfully before with the same account. The URIs for my app are https.
How can I overcome this problem?
sorry to hear you're having trouble. Our team is investigating and will update this answer once we have it identified.
Is it possible to share the App Name and/or Redirect URI that your are using, as well as the platform chose? Understand if it's not. Are there any non-alpha numeric characters?
In the meantime, you can register your app manually through Azure AD. Here is how: https://msdn.microsoft.com/en-us/office/office365/howto/add-common-consent-manually

Resources