I have a web application where my users can log in through either user/ pass or Google, using Firestore to manage users/ auth.
I also have a Chrome extension that needs to leverage the same authentication session if possible - i.e stays logged in, token can easily be revoked if needed, and no need to type username/ password into the Chrome extension.
It is easy to do this by grabbing the user logged into Chrome (Not my app explicitly, but in most cases this is the same thing). This works fine using OAuth2.
Reading the docs, username/ password authentication seems to suggest you use Firebase Admin in a server environment to generate and return a token. This then creates more complexity around managing tokens, logouts, and revocation from what I can see.
I am wondering if it is possible to simply share the logged in state between Chrome and the Chrome extension via pushing the Firebase session/auth data in IndexedDb from the browser to the Chrome Extension in a content script? Would this effectively give the plugin the same 'session' as the main browser? Is there any risk in doing this?
Thanks
Related
I am trying out Firebase / Firestore. When I run the command-line firebase login in a Linux terminal, I am redirected to the typical Google login web-site but with an additional Firebase-logo. After login on that web-site, I have to enable various features and permissions for Firebase to access my Google account.
Then the firebase program on my local Linux PC knows that I have logged in to my Google account. Even after I restart the computer, the firebase program is apparently still logged in to my Google account.
How does this work behind the scenes? Is my Google account password stored on my local PC somewhere, since firebase remains logged in to the account? Doesn't that cause a security risk?
Thanks!
No, passwords are never stored like that. That would be incredibly unsafe. The CLI is storing a special token that gives access to parts of the account that you authorized in the web browser. That token is valid until something invalidates it, or you sign out by running firebase logout. It's similar to the way most auth systems work that allow an individual to stay signed in for long periods of time without reauthenticating.
If you want to see exactly what the CLI is doing, it's all open source.
So I have email link signin (password less) working for iOS and Android, but if a user requests the email and then opens it on a web browser, they see this message:
Error encountered
{"error":{"code":400,"message":"API key expired. Please renew the API key.","errors":[{"message":"API key expired. Please renew the API key.","domain":"global","reason":"badRequest"}],"status":"INVALID_ARGUMENT"}}
I need them to click the link using their mobile device in order for the authentication to work, but ideally I could provide a more graceful message here that tells them to open the link on the mobile device. Any ideas?
I've now got this redirecting to my own website. Long story short - for some reason my Firebase hosting site was not configured properly and thus this authentication url was not being handled as it should. Fixable by recreating hosting site or just creating an additional site under hosting and using that for the email action url.
What I did was:
Create an Additional Site on Firebase Hosting. I made it additional so I wouldn't have to worry about messing with the Dynamic Link setup that is currently working on the default site.
Then under Authentication > Templates in the Firebase console, I changed the action url to use the new site but still have the (__/auth/action?...) path after the domain.
Now, when this url is accessed via a desktop browser, the user is redirected to the continue url (specified in the action code settings of the mobile app) and I display what I want on this continue url.
I noticed that in my Google API console, Firebase created a new Browser key and that it is being used whenever this auth link is clicked. Perhaps this was the issue all along. I wonder if I somehow restricted the wrong key. Anyways, if you run into a similar issue, check your API keys and their restrictions and/or just create a new additional site in Firebase hosting and use that.
I have an Intranet authenticating by Azure AD - located at https://intranet.example.com/ (In details, its Sharepoint Online);
In some pages, we need dynamic content generated by an rest api - located at https://api.example.com/ (In details, .NET WebAPI, Owin middleware using OpenId);
api.example auth by AAD too;
Both api.example and intranet.example have Windows Azure AD permission granted through admin consent;
api.example has X-Frame-Options, Access-Control-Allow-Credentials and Access-Control-Allow-Origin enabled to https://intranet.example.com/;
What I need:
Some pages have dynamic content generated by JavaScript logic requesting data from api.example;
Users will authenticate in intranet.example and api.example must have Single Sign On behaviour.
Avoiding any type of prompt or authorize request is a MUST, since all of that must be transparent to the final user;
What I tried:
I tried to simply put an IFrame inside intranet.example pointing to app.example and it works both on Chrome/Firefox. But, IE11 doesnt allow it, since my app redirects to https://login.microsoftonline.com/ that responds with X-FRAME-OPTIONS set to DENY.
Example:
User log in Google Account, access https://mail.google.com/ and have hangouts messages up and running with no prompt or authorize request or something else, totally transparent.
User log in Microsoft Personal Account, access https://onedrive.live.com/ and have Skype messages up and running with no prompt or authorize request or something else, totally transparent.
Note1: It must works outside our domain. So, setting Intranet/Trusted Site Zone is not a option.
Note2: The more decoupled from Sharepoint, the better.
Note3: I tried this aproach PnP Webcast - Calling external APIs securely from SharePoint Framework.
I would recommend re-posting your question in SharePoint Stack
Exchange.
AadHttpClient might be a better option, but it's in preview right now and 'not supported in production tenants'. It also requires the new SharePoint Admin Center which is only available for first release tenants.
Also, I found these to be better AadHttpClient tutorials than the existing MS documentation:
https://www.spdavid.com/consume-a-secured-azurefunction-using/
https://github.com/SharePoint/sp-dev-docs/issues/1378
When I run ionic serve --lab everything works fine in the browser. I can do auth operations with email and password. When I try and test on a device through ionic upload, or build on android, the app isnt authenticating correctly. I can still connect to firebase if I hard code the Url of a list or object but can't get the data through my auth login. Its worth noting that when I emulate in the browser I get "The current domain is not authorized for OAuth operations. This will prevent signInWithPopup, signInWithRedirect, linkWithPopup and linkWithRedirect from working." Not sure if its related to my issue because it still allows me to login from the browser and I am not using any of those, just auth.login(email, password). Also when I debug the app from my device through chrome I get "Uncaught Error: "location.protocol" must be http or https ". Does anyone know how I may be able to fix this?
Popup and redirect operations are only currently supported in http and https environments. Check this thread on how to sign in or link with popup in Ionic/Cordova: https://groups.google.com/forum/#!searchin/firebase-talk/cordova$20facebook/firebase-talk/mC_MlLNCWnI/DqN_8AuCBQAJ
I have an issue with one of our clients.
We developed an app, that apparently works fine.
We tested with various accounts.
The issue is that our client can't use the app.
Accessing the client's account, I tried this FB access token tool:
https://developers.facebook.com/tools/access_token/
I tried to use various apps with the client's account, from various vendors.
This is the result (screenshot):
screenshot
What can be the cause? It seems that this account cannot store any access token from any app.
Thank you!
The Access Token tool will only show tokens for apps that the user is an admin or developer of - if they are just a regular user, this will not show up here.