In one of my use cases for my react web application, my user will open the application after following a link generated by a chat bot.
In this case, the specific chat application is LINE, and all links parsed by the chat window are opened by default, in LINE's own web browser.
When the user attempts to login, the login process is halted, in what I believe is the intended behavior, as google has said it has depreciated web-app logins from app webviews in 2016.
Is there any way I can detect one of these in-app browsers and prompt the user to re open the web app in their preferred browser?
If not, does anyone know of a workaround I can use? Would having a secondary, server side authentication route be the best bet?
Related
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'm creating a firebase application that uses user authentication, in addition to an express server for video calling with Twilio. Right now, I'm not quite sure how to test signing in multiple users to my application, as when I open different tabs to localhost:3000 both windows redirect to the same location whenever I change the route (using react-router-dom). Therefore, when I try to sign in on a different tab, all other tabs will redirect to the sign in page instead of remaining on the home dashboard.
Could this be a problem with how I'm handling users in Firebase, or how I'm testing with express?
Any help is appreciated.
Firebase Authentication doesn't really support signing in multiple users into a single app instance. That sign-in is shared globally among all tabs loaded with the same site. If you try to sign in a new user, the old one will be immediately and forcefully signed out. This is true on all client app platforms, including iOS and Android.
If you want to test two users signed into your site at the same time, try two different browsers, or use two different Chrome profiles, so that the per-user storage is different for each browser window.
Never thought I'd run into an issue of having too much documentation! I need help with picking the right information so I can read it, understand it, and follow it.
My scenario:
I have an ASP .NET Web Application that is hosted on mywebapp.azurewebsites.net
The web app has a full REST API at mywebapp.azurewebsites.net/api/v1/dostuff/1
You can go to the site and perform all the CRUD stuff. You can also use desktop application to do the same.
I went ahead and enabled Azure AD authentication in Azure Portal. Now in order to do anything on the website, users need to sign in. It brings up the usual Microsoft Login popup and then upon successful authentication redirects back to the site.
But when it comes to the desktop app, I want the users to be able to use it without signing in. Somehow my desktop application needs to be able to make calls to the API/website and be authenticated!
At this point I am lost if there is something I need to do in manifest file, or in the web app, or elsewhere?
Most I was able to do is get an access token using client credentials/client secret.
I just need to know if what I am trying to achieve possible and which document explains the approach of doing so.
Well the fundamental problem you have is that a desktop app (like any public client) has no way of authenticating itself to AAD in a secure way.
You cannot use a client secret.
It is very easy to grab the secret from the executable, and that is basically your app's password.
You would have to make the API accept calls without authentication pretty much.
If authentication is required for access to the API,
then a user must authenticate in the app.
Google's OAuth has blocked request from web view.
However, most of my user enter my website via QR code scanner app (QR code scanner app in general). Qr code scanner app then open webview to my page. User won't be to login or signup through social network (OAuth authentication). I would like to find a way to work this out. Many users have this problem and call to our support.
I am finding the solution or work around to this. I use Google's Firebase, therefore, I could't use other authentication service.
Here is the list of options I can think of..
launch normal browser if webview is detected.. (I'm not sure if this
is possible, the webview is own by the QR code scanner app, I tried
many ways and it didn't work)
set http request header on client to show that the client is NOT requesting from a webview (not possible due to Google's policy "Do not mislead Google about an application's operating environment.")
I am using facebook/twitter logged in user to authenticate my web api. i followed this
Okay that was most likely what I what. But my view page will be differently hosted. That is user will be logging in with a different page and they will send an ajax request get values from api controller.
I would authorize the web api only to user who is logged in.
If by "differently hosted" you mean on separate domains, then you won't be able to share a cookie between the two. If you mean that the client is a iOS app or Windows Phone app running on a device, the general pattern is to use a "Browser Control" and build a little UI as part of your API site. You can show your users this UI in the browser control and then scrape the token out. If you use Azure ACS, this is much easier with the "javascriptnotify" protocol that enables the token to be pushed out of the browser control.
The best article I've seen on this is http://www.cloudidentity.com/blog/2012/04/04/authenticating-users-from-passive-ips-in-rich-client-apps-via-acs-2