Firebase RTDB - How to avoid CSP problems in chrome extension mv3 - firebase-realtime-database

I have a private chrome extension that at the moment I'm publishing as private in the CWS.
I've noticed that sometimes the extension will stop working because of the CSP policy of mv3. I've used firebase RTDB using vite to include it, is there any way that I can use to avoid this problem?
Also I need to apply some rules to the database but I don't have any login or registration system. How I can setup rules correctly?

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

Ionic app on iOS requires turning off Safari setting "prevent cross-site tracking"

We have an Ionic 4 (Cordova/Angular) app that makes requests to a REST API backend with HttpClient, using cookies for authentication.
The app runs fine on Android (which apparently proves that we've configured CORS correctly). We are now in the process of adapting it for iOS. We have found that when the Safari setting "prevent cross-site tracking" is turned on (which it is by default), WkWebView ignores the Set-Cookie header that is sent by the backend in response to a successful login request, causing all subsequent requests to fail.
Is there a way to avoid the problem without requiring all users to turn off this setting (which is definitely not an option)? We have considered switching to JWT authentication, but I'm afraid that it won't solve the problem, as our backend expects JSON, and according to the docs, "Content-Type: application/json" headers also cause the request to be considered as a CORS request.
Additionaly, we have come across another problem which seems to be related. The app won't run on the iOS simulator on macOS - the Set-Cookie headers are ignored, even if we switch the above setting off! Meaning we can debug the app only on a physical device, which is quite a hindrance.
After several hours of searching on the web, and not finding any similar complaints, I have the feeling that I'm missing something obvious.
This library has come to my rescue: ionic-native-http-connection-backend
Quoting from the docs:
This library adds #ionic-native/http (when available) as a connection backend to Angular's Http and HttpClient
Motivation
Now that Apple promotes/requires the use of WKWebView instead of the deprecated UIWebView, Ionic has switched newly created apps over via their cordova-plugin-ionic-webview (and Cordova offers it via their cordova-plugin-wkwebview-engine). That causes requests that used to work just fine to fail with CORS errors.
The real solution of course is to fix the CORS issues server side - but this may not be possible with e.g. 3rd party APIs.
Even though there is a way to solve CORS issues without changing server's response header by using #ionic-native/http, this only works on device and doesn't provide all the power of Angular's Http and HttpClient.
How it works
The library provides a HttpBackend interface for Angular's HttpClient
This HttpBackend interface tries to use #ionic-native/http whenever it is possible (= on device with installed plugin)
If HttpBackend finds it impossible to use #ionic-native/http, it falls back to standard Angular code (HttpXhrBackend, which uses XmlHttpRequest)
This strategy allows developers to use Angular's HttpClient transparently in both environments: Browser and Device.
Although I still find it strange, that the developer only mentions the library's intended use for situations where CORS can't be configured server-side, but not the 2 problems that it solves for me, namely 1) having to require all users to allow cross-site tracking, and 2) not being able to use the simulator.

Xamarin google play services login setup

I am trying to hook a Xamarin project up to Google Play Services but keep receiving a SIGN_IN_REQUIRED error when calling Connect. I have read a few posts online but cannot determine what actually causes this error message.
I have setup the a game project and also setup an API with oAuth credentials. I have made sure that the same SHA key is being used in the API credentials and in the application while debugging but I am still not making any progress.
I am currently presuming that this is not a coding problem but rather something to do with the setup of the API services etc but have ran out of things to try at this point.
Firstly, to make sure your network connection is normal, you can run this demo in your network environment.developer.xamarin.com/samples/monodroid/google-services/… Donnot forget to change to clientID in string.xaml.Then , open the firebase console, find this app check the clientID if it is same with your code, and check the SHA-1 hash of your signing certificate.

Invalid redirect_uri when attempting to use social sign in with Gigya with iOS

I'm attempting to integrate Gigya's social login into an iOS application. Within a ViewController, I'm triggering the showLoginUI method on the GSAPI class. This appears to work fine and invokes the web view containing links to each of the social providers. The problem that I'm facing is clicking on any of the providers, the delegate method gsLoginUIDidFail is returning the responseText
{"errorCode":400011,"errorMessage":"Invalid redirect_uri"}
I've been following the guide found at http://developers.gigya.com/035_Mobile_SDKs/010_iPhone
Initially, I thought that perhaps this was a problem with the gigya test providers, but adding a real provider app to the gigya configuration didn't resolve the problem.
The gigya api internally references a gsapi://login_result/ and wondered if perhaps this is the issue as I can't seem to work out where that protocol is being defined.
Also, running the test application linked in the guide encounters the same issue.
Hoping someone has encountered this problem themselves and knows what trick i'm missing to get things working?
Ok, so it turns out if you have already been using the API and have an API key, it's super easy to miss the step within "Gigya Setup - Obtain Your Gigya API Key" which requires you to tick a Enable Mobile or Desktop Client Applications API Access checkbox.
Ensuring this is set resolves the issue.

Resources