Google Smart Lock on a website
I just visited Pinterest and it has a cool feature. Somehow when I visit the site Chrome can "see" that I have an account. And instead of passively waiting it informs me pro-actively: you do have an account here: would you like to login with 1 click? yes/No
https://support.google.com/accounts/answer/6160273?hl=en
Question: I see a lot of json code examples for apps. But how can we proactively add this to a website that a user has a stored uname/passwd for?
thanks, Sean
Here's an article describing how to add Smart Lock sign-in to your website: https://developers.google.com/web/updates/2016/04/credential-management-api
Basically, add a bit of code to the (https) website like this (you can try it in the JavaScript console:
navigator.credentials.get({
password: true, // `true` to obtain password credentials
}).then(function(cred) {
// continuation which submits the credential and signs the user in
...
Here is a complete sample website: https://credential-management-sample.appspot.com/
Once the user has used this credential or you have saved it with navigator.credentials.store(), then in the future, it can retrieved automatically (without a user click).
For more information about this, check out this talk from Google I/O (details on the credential management API start at about 8 minutes).
Related
I need to implement a standard user registration/activation workflow with Firebase. There doesn't seem to be an obvious way to implement this. When I say "standard", I mean how most email/password accounts work - not necessarily specific to Firebase. I'm sure you're familiar with this. This is the workflow:
User enters their username/password on a form with some validation and submits details
The back-end creates the user record in the database, but the account remains deactivated (i.e. user cannot authenticate - the activated flag is set to false)
The back-end sends an email to the user with a link to activate the account
The user clicks the link in their email which triggers activation. This is probably a Web API of some description.
At this point, the user record's activated flag ticks over to true, and the user can now authenticate
The link probably also has a deep link that opens the app or navigates to a web page
The user can now log into the app
How do I configure Firebase to do all this?
Currently, the app allows the user to register. I am using the Flutterfire SDK. I call createUserWithEmailAndPassword, which successfully creates the user in Firebase. But, the user is already activated. The user should have a state of "disabled" in firebase until the account becomes activated. I can't find any settings to default the user to disabled when the account is first created.
I also managed to get Firebase to send out an activation email by calling sendSignInLinkToEmail, but this call is really designed for email authentication - not email activation. Opening the link should activate the account, but I have not figured out how to do this. This documentation makes it sound like it is possible. Perhaps, the Flutterfire SDK is missing this? I don't want to allow people to log in without a password. I only want to use this call to send out an email.
What am I missing here? Is this non-standard behavior for Firebase? If so, why? If the user is allowed to use an app with an email address that is not activated, they can impersonate someone else. We need to confirm at least that they are custodians of the email address that they are claiming to have.
Do other Firebase people just not worry about this?
Lastly, I know I can achieve this by creating a collection for users in Firebase and putting an "activated" flag there. But, if I do that, I've got to write a cloud function that accepts the link and then updates the user in the collection based on the received link. But I thought this would be automatic in Firebase. If Firebase doesn't have this built-in, I have to put all the security over the top to stop users from authenticating when they have not yet activated their account.
This is a pretty valid concern. I suppose the way around this is to check whether the signed-in user is verified whenever the app is launched. The User object that is returned from Firebase Auth has an emailVerified flag. Check this page for more details.
Using this flag you can choose to show a different screen or pop-up that has a button to send a verification link to the registered email address. Until the user verifies this address, you can limit access to some of the app's screens if you want.
Please note that I have not checked if this emailVerified flag is true for sign ups using Federated login providers like Google Sign-in and Apple Sign In. You might want to check that out.
I have created an Azure Logic App in the Azure portal and successfully added several steps. I add the Azure DevOps List Iterations step and click the sign-in button. A popup prompts me to sign-in and then closes and I am left with the follow error in the Logic Apps designer:
Failed with error: 'The browser is closed.'. Please sign in again.
I have am recreating a workflow that I originally created using Microsoft Power Automate (Flow) so I know that my credentials should work.
Now when I hit the sign-in again I do not get the option to re-enter any credentials nor change accounts.
What fixed it for me was allowing 3rd party cookies:
In your browser settings, make sure that you allow all cookies (including 3rd party cookies: a lot of Microsoft webapps depend on that),
Refresh the Logic App page (might not be required, but it doesn't hurt),
Add a new connection and sign in.
You can then block 3rd party cookies again after this if you wish.
for me change browser from Chrome to MS Edge beta helped
For this problem, please check the resource group which your logic app belongs to. When you click the "Sign in" first time, it will generate a "API Connection" in the same resource group of you logic app. Its name should be like "visualstudioteamservices" (shown as below screenshot).
Please delete this api connection and then wait a few minutes(because there may be a delay in deleting operation). Then go back to your logic app and delete the DevOps List Iterations action, then create the DevOps List Iterations action again it will ask you for the sign in credential.
By the way, if your browser remember the last credential, it may still have some problem. Please delete the api connection and change to another browser to have a try.
Open an incognito/private window in your browser, then attempt to create the connection.
Just had the exact same issue, thought it had to do with my subscription being free trial.
But it logged in perfectly once I switched from Safari to Chrome (on a MacOS 11.2).
I had the same problem using Firefox to create a Logic App, solved by turning off Enhanced Tracking Protection for portal.azure.com
In the docs, the sign in functionality looks like this:
app.intent('Default Welcome Intent', conv => {
conv.ask(new SignIn('To get your account details'))
})
However, I can't find how to force logout a user who just signed in. Anyone help me please? Thanks.
"Logging out" of an account linked with Google Sign In is tricky, particularly if you're using voice matching as well, since the account sent to the Action is the same account as the one you setup the Assistant device with.
You can go to https://myaccount.google.com/permissions and remove permission from the app/Action/project. Once you do this, the Action will no longer get your user information. (This isn't Action specific - it is a core component of Google Sign In across all platforms.)
The other alternative you have is to reset your Assistant device and set it up with a new account. Then when you go to the Action with this reset device, the account won't be linked.
A explicit sign-out function does not seem to be available. However, this can be a good design decision as the user should be logged in to a particular service "as long as possibly allowed". Therefore, when releasing your apps to production, consider looking at the validity of the access_token and refresh_token on your authorisation server to control the "login period".
So there are definitely many tutorials out there regarding how to integrate various individual social network authentication/registration into existing user accounts. But the scenario I can't seem to find out much information about is if a user signs into your account with different social network credentials. For example:
Scenario #1
User registers on site using site's authentication.
User then signs in/registers on site using Facebook Connect.
User then signs in/registers on site using Twitter.
How do I integrate all of these into one account?
Obviously once a user is registered, they can add other social network associations in the account settings pages. But I am more concerned if they register via the other social network not remembering they are already setup.
My general thoughts are trying to figure out a way to use the "username" or email to try and guess and present the user a way to combine accounts right there.
Anyone have any thoughts?
following up -
if your users can't remember that they've signed up previously, well, best of luck to them in general ;)
much as you described, i'm planning on giving users the option to link additional accounts once they have signed in by one means or another.
but as far as cross-checking, there's only so much you can do. many social network APIs do indeed provide email addresses (once you've busted in through OAuth) but these may be accessible only if a user has elected to make his/her address public, which is not guaranteed.
also not guaranteed is that the user used the SAME email address for each social network account, so even if you manage to retrieve an address it may or not be of any use to you.
finally, if you find matching email addresses via such means, it might be advisable to prompt the user to link accounts rather than assume he/she wants this done automatically. some people like to maintain multiple personalities. i.e. "it looks like you are also signed up with twitter - do you want to link your accounts? it will make your life seem worth living."
you might consider offering incentives to link user accounts or to provide an email address (up to you of course to figure out what these might be, based on the functionality of your website).
solution i am working on, database-side, is to maintain multiple accounts and then if link information is discovered by various means, said link is indicated in a lookup table.
an alternative is once you find a link, attempt to combine all relevant entries for the multiple accounts into one account entity - all i can say about this latter approach is that i would do so with caution as there could be a formidable level of complexity depending on the user's activity level and the complexity of your database schema.
in my (mental/actual) namespace a user who registers the old-fashioned way has a 'standard' account and one who uses a social network has an 'alias' account. then the goal becomes to define where the alias is supposed to point, i.e. create the lookup such that a subsequent login via either means retrieves the relevant information for both accounts (with a preference for displaying personal data for the 'standard' account).
btw i figured out how to make twitter OAuth behave since my last post - you can look at my other answers for details if you're interested.
JB
hi matt,
i'm working on the same problem right
now.
assuming the user starts with regular
site account (which is not
necessarily safe to assume if he sees
all the pretty "connect with XXX
network" buttons!!!), you can use
either OAuth or the javascript APIs
(facebookConnect or #anywhere -
haven't fully figured out the latter
yet and i'm not sure I recommend it as
I don't think it provides as rich an
API as do the backend libraries) to
login to the other sites.
the APIs should return certain
information after a successful
login/redirect from the social network
- such as the user ID and an ACCESS TOKEN which you can then store in your
database in some capacity associating
your 'actual' application user with
the ID of the social network.
when the user returns to the site, you
can then
1 verify cookies set by the social
network services (various schemes
typically verifying a signature, based
on sha1 or md5 hash of your
application data - by which i mean the
data you get when you register your
app with twitter/facebook, typically a
consumer key, application ID, etc. -
with the received cookies) so you know
the user has logged in with the social
network
2 find your database entry association
as described above
3 login your user manually based on
the assumption that facebook/twitter
connection is secure.
caveat: this is only as secure as your
implementation (or as secure as
facebook/twitter's implementations, if
you prefer...)
although twitter's OAuth does not
currently seem to work quite right,
their general description of the
process is pretty informative:
http://dev.twitter.com/pages/auth
good luck.
J
I have been contemplating adding FB auth to our app, but we know that our returning users might click it and complete checkout for a new item, and then be surprised to not see any of their existing orders. To solve this, when a user clicks the 'Login with Facebook' item, we are using that click to fire a dropdown menu with two options:
[ Login with Facebook ]
[ Create new account ]
[ I have an account ]
If the user clicks 'I have an account' we send them to FB auth and return email from FB to our app. We compare that email to our existing users. If we match, we add the FB creds to the user. If no match, we throw an alert:
The email you have with FB does not match any of our accounts. To log in to your existing account, login with your email below, or update the email in your Facebook account
This allows the user to create a whole new account, if they want to keep them separate, without needing a new email service. While this is an edge case, it is a feature.
Simple scenario:
I have a signup form, with user name, password, email address, may be credit card number.
At the bottom of the page, I implement the Google Analytics code.
when user clicks submit, it goes to a page wihtout google analytics.
question is..
can GA get the data (user naem, password..email..etc) in the first form after user input the data?
Do they say anything about it in their TOS or Privacy policy?
Yes. Any <script> you include in the page has complete access to alter the user's interaction with the site due to the Same Origin Policy. Google, if they were feeling Evil today, could certainly rewrite the action of your <form> to point to themselves, or log every keypress, or create an <iframe> containing another page on your site and simulate the user clicking on any action in that page.
Do not include <script> on any page from a party you don't completely trust with the security of everything on your site. Even a single tracking or advertiser script on any page compromises everything on the same hostname (and maybe other subdomains if you are setting window.domain to allow cross-hostname-scripting, or sharing cookies between hostnames).
However, the Analytics script doesn't currently do any of these things and the form submission will not flow to Google as a matter of course; they would have to deliberately act to steal the data. Clearly it would be disastrous for them to be discovered doing it, so they presumably won't. But technically, they could. It always pains me to see third-party ad and tracking scripts on bank sites.
UPDATE: The landscape has changed quite a bit over the years since my original answer below was written: the scripts are now generally served (or at least have the option to be fetched) over HTTPS, so those scripts should be secure against the trivial man-in-the-middle attacks. However, you are still trusting the script source not to do malicious stuff in your page, since they still get to fully control what happens on your web page.
Original answer:
Yes. I recommend against putting any third party script on sensitive pages secured by SSL. It's not likely that Google is going to hijack sensitive data on your page but you should take into account the possibility that a malicious ISP can hijack the request (say, using DNS) to Google Analytics script and do whatever it wants on your page.