We Keep Coding

How to support HTTP protocol in Electron/Firebase App

I'm trying to user firebase authentication (saml) within my Electron app. I have read that Electron isn't "officially supported", however I've also encountered some threads that indicate people have gotten it to work. My issue is when using firebase.auth().signInWithRedirect (or signInWithPopup), I get the error:
code: "auth/operation-not-supported-in-this-environment"
message: "This operation is not supported in the environment this application
is running on. "location.protocol" must be http, https or chrome-extension and
web storage must be enabled."
Google turns up this tips and tricks article which suggests just using a hosted URL:
Third, OAuth requests need to have a verifiable origin, which can be whitelisted in the Firebase Console. This requires the current Electron browser window to use the http or https protocol, and not file. That means the current window contents should be loaded with browserWindow.loadURL and not browserWindow.loadFile, and the url must be an http or https url, not a file:// url. This generally requires a hosted page somewhere that gets wrapped into the Electron window.
This will probably work, as just running the app locally on the angular dev server works by simply using:
mainWindow.loadURL('http://localhost:4200');
I don't want to do this because having a hosted page lessens much of the appeal of having a native app.
I could make this work in by just having a local Node/Express instance serve the app locally using get-port to find a free port to run the app there. I haven't really seen any examples showing this. There are a few Stackoverflow questions on getting it to work, but nothing that makes me think it is an acceptable production-level solution.
Is a local Express server an acceptable way to circumvent this error, or is there currently a better solution?
Note: The package recommended in this answer is not published by Firebase and anyway doesn't look like it supports SAML auth.

I had to do something very similar but with Auth0 instead of Firebase.
What I had to do was make two Browser Windows, where the first one is strictly an authentication Browser Window while the second one is the actual main App Browser Window.
Auth0 has the same restrictions of whitelisting only http/s protocols, so in the authentication Browser window, I load the Auth0 sign in URL via localhost (it’s a hosted URL in Auth0 itself). I then take the credentials (access token and refresh token) from that redirect/Oauth process and store them locally for the time being (use Keytar, SafeStorage, FS modules, whatever; I chose Keytar).
Then my authentication Browser Window closes itself and launches the main, app Browser Window.
From here onward, I have to reference my stored access token and refresh tokens from my storage location and use those in all other calls.
So, for instance, I have some API library modules I made for myself that use Axios. So I bring the saved access token into all of my Axios calls. Works like a charm.
So, in summary: I had to use two different Browser Windows and persist credentials locally for later use in the main Browser Window.
Check out Auth0’s guide on using Electron for authentication; I think you’ll find that many concepts carry over for Firebase and other providers.

i've successfuly implemented firebase email ver in my app, it is more feasible to load .html file rather than load a page from url as users can exploit the the url by sending fake data. but with oauth it is not possible,firebase create webapp you can create a html file it should contain api keys, host url etc and host it locally in android file://android_assets/filename.html this works fine even offline i dont know properly about
electron

Why script tags referencing "localhost:3000" fail

I am in the middle of a massive refactoring of my companies' web services and in doing so we are splitting out our static web files (HTML, CSS, JS) from our auth server and our API service. Our migration plan requires us to keep the old web server for backwards compatibility, therefore in order to do local dev I need to setup all my script tags to reference "localhost:3000", however, when I do that the requests fail in the browser
I can go directly to "localhost:3000/scripts/core.js" just fine in the browser, but if I put the exact same URL into a tag, all of a sudden the request fails in Chrome. Doesn't give me an error or anything, just says "failed"
Anyone know what I need to do to get this to work?

Because "localhost:3000/scripts/core.js" is a filepath name but "http://localhost:3000/scripts/core.js" is not. The first gives no transport mechanism but tries to attempt to open file:/// while the second specifies HTTP.
So test Or https:// as the case may be.
As far as SSL goes, this may be a separate issue. Is your SSL certificate signed for your local server or at least self-signed and accepted by your browser? Enquiring minds need to know but this may need to be a separate question.

Is it possible to use Chrome DevTools to override login logic?

I used the following project as the basis for the login authentication logic for an app: https://github.com/cornflourblue/angular-authentication-example
When the backend was down, I manually altered the frontend to avoid the validation of user credentials to workaround the $http calls.
That made me wonder if it is possible to use Chrome DevTools or Firefox's Dev Tools to circumvent the $http call and make the app think the credentials were accepted.
So far on my own, it seems Chrome still runs the original files and any altered files on stored elsewhere and not used. But I couldn't reproduce the hack just within Chrome DevTools, but I'm not an expert and was curious if it was possible.

Yes it is possible to alter client side scripts and hack any javascript code...
That is why there is a log in process the purpose of which should be assigning valid session credentials for the client side to provide to the server with each request so that it can be validated and acted upon accordingly.
Basically, your application must make sure that no sensitive information is exchanged before the valid session is established making any client side code circumvention obsolete

socket.io referring to localhost despite being set as a specfic IP

I'm trying to use web sockets to connect from a Google Chrome browser on my phone to a server running node.js and socket.io.
Using the remote debugging tool in Google Chrome I get this error in the console
Failed to load resource http://localhost/socket.io/1/?t=1368744562638
This happens despite me specifying my internal LAN IP in code for the client like so:
var socket = io.connect('http://192.168.1.3');
Furthermore it seems like the first heartbeat request makes it but starts to fail after that.
The code runs as expected when running the client on the server.

I am of course a idiot. I had another javascript file that had not been updated to connect to the specific IP I had set and was still set to "localhost".
After updating the host that socket.io should connect to in that javascript file everything is now running smoothly :)

Is there a way to bypass Javascript / jQuery's same origin policy for local access?

Trying to use ajax, getJSON, and functions like that to fetch an external URL from a local (non-server) development computer. Is there a way to bypass the same origin policy, so that I can test locally, instead of having to upload to a server?

Here's the simple answer: chrome --disable-web-security
From the source code (chrome_switches.h):
// Don't enforce the same-origin policy. (Used by people testing their sites.)
const char kDisableWebSecurity[] = "disable-web-security";
I wanted to use jquery.js to send AJAX calls to a Google Apps python server running on port 8080. Just for testing, I wanted to run the browser and the server on the same machine.
I don't understand all the security nuances, but for temporary development it seems like a reasonable workaround. So long as I only use chrome for testing with this flag, it shouldn't be a problem.
Here's the whole command for Mac OS X:
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --disable-web-security

We had the same need when developing our web app. Here's how we did it:
The browser and the server communicate only through JSON.
All the HTML is rendered in the browser using PURE (our JS template engine).
The browser code is developed locally like this:
We add a host parameter in the url of the app:
http://localhost/app.html?host=test.beebole-apps.com
In production, the JSON are sent to the server with a POST.
But here the function in charge of the ajax call will react to the host parameter and make a JSONP injection(GET) instead.
<script src="http://test.beebole-apps.com/?callback=f2309892&json={...}" />
f2309892 is a temporary function, with a random name, that points to the method that will handle the response
json is the JSON we send to the server
It means you will need some cooperation from the backend to serve you the json wrapped in a callback function like:
f2309892( /*the json here*/ );
Except a size limitation(you can't send a big JSON to the server with a GET) it works like a breeze.
An other advantage is you can call all the different systems(development and test) from the same localhost.

There are different ways to get around this, depending on which browser you're using for development. For example:
In Firefox (Gecko), set security.fileuri.strict_origin_policy to false
In Chrome, start the browser with the option --allow-file-access-from-files
References: Firefox, Chrome

Without touching the server -
The quickest and easiest way to bypass the same origin security policy in Firefox is the install the Force CORS add-on. This works with any service by inserting the proper headers into every response.
https://addons.mozilla.org/en-US/firefox/addon/forcecors/

Since this is a development issue and not a end-user/functionality issue, rather than focusing on getting AJAX to cross domains get your development environment set up as a proxy to fetch the most recent data from the production servers. This is actually really easy to do.
You'd need to set up a web server in your dev environment (if it doesn't have one already), and then configure the server to respond to 404 requests by fetching and then echoing production data. You can set up your server so that only the AJAX data files are picked up (otherwise, it will be confusing to debug other files if production assets start showing up on your development pages). So if http://dev.myserver.com/data/json/mydata.json is missing, your 404 script will get http://prod.myserver.com/data/json/mydata.json and echo it to the client. The nice thing about this set-up is that you can use mock data very easily: if the file is there in your dev environment, your AJAX script will get that; but if you then erase or rename that file, you'll get the production data instead. This feature has been so useful I can't recommend it enough.
If you're working with XML, I'd recommend duplicating the HTTP headers in the 404. If your 404 process responds with a Content-Type of text/html, you won't get any responseXML to parse.

try this (php curl ayax cross domain - by google):
http://www.iacons.net/writing/2007/08/02/ajax-cross-domain-proxy/
http://www.phpfour.com/blog/2008/03/cross-domain-ajax-using-php/
http://jquery-howto.blogspot.com/2009/04/cross-domain-ajax-querying-with-jquery.html

I had that problem, too, using Chrome and the --allow-file-access-from-files option didn't really help. Back to the script my server needed to return, I added these headers to the response and it worked fine :
'Access-Control-Allow-Origin: http://localhost/'
and another one for allowing a sort of key exchange
'Access-Control-Allow-Headers: X-KEY'

localhost is not allowed to use in CORS http://code.google.com/p/chromium/issues/detail?id=67743 use lvh.me instead