I am using electron version 18.1.0.
I have converted angular app to desktop using electron js.
I use file:// protocol to load index.html.
win.loadURL(url.format({ pathname: path.join(__dirname, 'index.html'),protocol: 'file:',slashes: true}));
App is using XSRF-TOKEN for authentication.
But cookie is not available. If I see dev tools -> application -> cookie. This showing file:// protocol and no cookie is listed.
I have used custom protocol but in this case, angular app is not loading. It may be due to failure to resolve path for JavaScript, CSS etc.
Please suggest a way so that I can access cookies and also would be able to use
Related
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
I am using Cordova to build an iOS App. I use the Ionic engine meaning that the app is served from a webserver running on the device.
My window.location.origin is "ionic://my-app.com".
A third party API (that I need to use in order to fetch an address suggestion based on what the user types) rejects my HTTP requests because the referrer header is missing in the request.
It's not possible to programmatically add a referrer from the JS layer and these did not work:
<meta name="referrer" content="origin">
<meta name="referrer" content="always">
I suspect that the issue is that the API is using https and my iOS App is using a custom scheme (the default one is ionic:// and cannot be changed to https). For this reason the referrer header is not added by the WebView.
How can I solve this issue?
I'd try following the CORS workaround for native apps that uses the HTTP plugin from ionic. See here for more details:
https://ionicframework.com/docs/faq/cors#1-native-only-apps-ios-android-
if you are using the webview package cordova-plugin-inappbrowser you can integrate this Pull Request in your code and you will be able to set a custom header with a custom value: https://github.com/apache/cordova-plugin-inappbrowser/pull/363
I have done it and it works.
When I use a service used for online authentication, I get an url to navigate to that will automatically open an app that is used for the passcode input.
The url is in this format:
bankid:///?autostarttoken=2a1b5e2c-c9fb-4402-1239-2a1619d655e9&redirect=null
The navigation to this kind of urls do only make sense on a mobile unit where a certain app is installed.
Nevertheless, desktop browsers (not everyone) also try to navigate to such an url, like it would ever be possible. That of course results in an error page.
Why do they do that?
Do I need to use a hidden form?
Will every mobile unit honor that?
The custom URL scheme is used to be able to start an application locally, in this case the BankID client which handles the 2FA.
This works nicely on both mobile and desktop, as long as the custom url scheme is registered. AFAIK for mobile, if the URL scheme is not registered locally, it will query the appstore and let the user install from there. The BankID is available for both iPhone and Android in the appstore. On Windows it also query the appstore, but the BankID client is not available as Windows App, so it has to be installed manually from https://install.bankid.com. On Mac I have no idea if it queries the app store, but I know it has to be installed manually from https://install.bankid.com
Android, iPhone, Windows Phone, Windows mobile, Windows XP and later, MacOSX all honors the custom URL scheme but it also need to be honored by the browser, which all the major browsers do.
Historically, before mobile, we used to start programs using the NSS plugin support in the browsers. NSS plugin support was removed by the browsers since it was easy to mis-use from a security point of view.
That's why the custom URL schemes are used.
As you can read about in the BankID relying party guidelines, there is a transition to use https://app.bankid.com links to start the client instead. Basically, that's just a custom url scheme similar to bankid:// but registers both protocol (https://) and host (app.bankid.com), which then starts the app. This has the added benefit that if a user who hasn't got the client installed and is not able to find the client via a appstore or similar, will get the web site available, which then can help the user to install the client.
As the idea of an applink is to let the user navigate to the website if the URL is not registered locally, don't hide the navigation.
I am following along a brilliant Pluralsight tutorial, building my first ASP.Net MVC site. I want to login to my website, creating a cookie in my Chrome browser, and use Postman to send some requests which should be handled by my controller because the Authorize attribute should be satisfied by my browser.
I have installed the interceptor plug-in on my Chrome browser. I keep seeing that I need to switch on the Interceptor at the top of Postman, but I don't have that switch! I have a Proxy Settings button instead.
Can someone please explain how I should proceed?
You have a few options here. The tutorial you are watching is probably referring to the Chrome Extension which is what Postman started out as. It now also has a standalone application version, which, at the time of this post, is up to 4.9.3 and for which the interceptor no longer works with.
So you either need to install the Chrome extension version or work with the standalone app without the interceptor.
Options 1: Uninstall the standalone app version and install the Chrome extension version and then also make sure to install and enable the Postman Interceptor Chrome Extension
Option 2: Just add a Cookie header to your standalone Postman app's request. Something like:
Key: Cookie
Value: CookieName=28789ijnbskjhiuhyd8y
Option 3: Use the standalone app's built in proxy which will allow any requests made through your browser to be streamed into the Postman history. This option works ok but you would have to get the request in your Postman history and then re-execute the request from within Postman which is kind of awkward. Instructions here
I am in the process of creating an iOS app with Phonegap and jQuery, however, I am running into issues trying to allow both iFrames (to load normally) and external URLs (to open in Safari). I decided to choose the path of using iframes as I was not able to send POST and open the resulting page in Safari (i was trying to create a mobile friendly login window that opens to the full site in safari).
I recently updated to v1.5 hoping to resolve the issue, but it still occurs.
I have tried the trick "[url scheme] isEqualToString:#"http"...." however this forces any page in the iframe to load in safari.
So, I would like either to have external URLs and iframes to behave just like it does in a Webapp (add to homescreen button on iOS) or be able to send POST to Safari?
Has anyone got ideas? :)
Thanks!
You could change tactic slightly and login fully using your app, but then create an authentication token which would be passed via a standard link to be opened in safari.
You could generate the token new each time. Tokens are a valid system for access.