I am deciding which technologies to choose for my next project and I've decided that I'd like to use some of the Google Cloud products. I've been reading about Firestore in Native Mode and the idea of developing a web without a server need for CRUD operations seems really interesting.
My problem comes with me wanting to also use Google Recaptcha v3, is there any way to read how trusted an user is using according to Recaptcha v3 in the secutiry rules of Firestore to deny the request if it's, for example, under 2.
Thanks
No, Firestore security rules don't have any access to data from recaptcha. If you want to know something about the end user, you will have to use Firebase Authentication.
There is no information about Google Recaptcha v2 that is automatically included in the Firebase Authentication token for the user, as far as I know. And since the auth token is the only information about the user that is available in security rules (as request.auth), the repatcha information won't be available.
The only way to get that information into the user's token is if you'd add it yourself as a custom claim from one of the Admin SDKs.
Related
Using django-allauth I've enabled google authentication on backend. I can sign in to my Django project and everything.
Now, I want to connect that authentication with my React frontend, so I can login/register using google on http://127.0.0.1:3000.
What do I need to do?
You can use Google libraries for javascript or some npm library that does that for you.
After logging in through Google account and getting associated authentication keys / data on front-end side, you send them to Django and django-allauth should handle that data for you - you have to have specific view for that linked in urls.py.
After such request either new social account will be created or already existing logged in.
It might be required to adapt some of original social account management views to handle data that you send from React.
Keep in mind that at the moment Google is switching to Google Identity Services, which works a little bit differently than old method implemented in django-allauth - there is already an issue raised in the repository.
https://github.com/pennersr/django-allauth/issues/3074
To use Google Identity you can try to use:
https://www.npmjs.com/package/#react-oauth/google
or any other library that supports this
After that if you want to do this yourself new way on Django side, you can send JWT token that comes from Google to Django, validate it based on Google documentation and then create social account / sign in. That currently requires overriding some of original django-allauth views / forms for social accounts.
https://developers.google.com/identity
Im watching this tutorial that uses the firebase client library in cloud functions to authenticate users. I am starting to doubt wether this is the right approach. Should I do all the authentication in the react app instead? The tutorial explains that the benefit of doing everything server side is that it decreases the amount of things the user has to download to run the application.
That being said, Im having difficulty getting the client library to work with typescript which makes me just want to scrap it. How should I proceed?
It is generally better practice to host authentication (and especially authentication logic) in the back-end, if not for performance, definitely for security reasons.
That said, you can avoid using cloud functions for this authentication with firebase! Here is an alternative super simple video tutorial you may like instead from Fireship: https://www.youtube.com/watch?v=zQyrwxMPm88. The Google Firebase YouTube channel also has many videos on the subject.
Cloud functions are useful for when you want parallel action to be taken in the back-end during or after login, while the useAuthState() react hook is great for when you want parallel action to be taken in the front-end during or after login.
so my view on the best approach to solve this on Firebase is to either:
A) Use the Auth Firebase SDK for your client to create users and sign in users,
B) Do it with the Auth REST API
The end result is the same, you get your users into Firebase and you can sign them in and get their auth tokens. The SDK runs on the client, the REST API runs on the server. Once that's done, you can use the user token and pass it to cloud functions to do whatever you need and check the token validity and permissions server side.
On the cloud functions you're supposed to use the Admin SDK, not the client SDK. And the admin SDK has all privileges. For a more specific reason why you SHOULD NOT use the client SDK on cloud functions, is because it keeps state. So 2 users calling your cloud functions, using the client sdk server side, would result in the same user token, which is an error.
I hope I've solved your problem?
(intro)
I am new to Google Cloud Endpoints and I have started to build some HTTP REST services.
The purpose of those services is to be consumed directly by the users of my application (Business to Consumer - not business to business).
(The question)
I need to secure my services in a way to have only registered users being able to retrieve sensible data (and after login). My main purpose is to have the list of registered users saved in my database on CloudSQL (Dont want to use FB of Google Accounts). I was not able to find particular information about this point in the official Google documentation regarding authentication.
Can anyone advise me of the way to proceed and suggest some tutorials?
Thank you in advance.
The Endpoints proxy can validate JWTs, and we provide a couple of alternatives for creating those. Both Auth0 and Firebase have good user management capabilities and client-side libraries for generating JWTs. Both allow you to choose an identity provider (like FB or Google) or simply use username/password.
Check out the documentation here.
If you don't want to use Auth0 or Firebase Authentication, you can sign JWTs yourself with a private key and just give the proxy the URL of the Public Key (see the "Custom" tab on that same documentation page).
As far as looking up individual users in the database, you would have to do that part on your own.
I have integrated my application with Google apps marketplace with old version of OpenID and getting the data from Google calendar by using Google calendar version 2 API. Now I need to integrate every thing to new version. I have confused a little bit as Google is providing various authentication and authorization process. I looked in to OpenID connect, JWT (JSON Web Token), Google calendar version 3 service account. May any one please help me out from this issue like that should I use to authenticate as well as for authorization. Thanks in advance.
https://developers.google.com/accounts/docs/OAuth2 gives a good overview on various ways to authenticate with Google APIs and when to use them. For instance JWT is useful when your application uses Google APIs to store/retrieve its own data i.e. not to access data of your application's user.
Also see https://developers.google.com/google-apps/calendar/auth
I'm pretty new to SalesForce and their Apex language. I've been reading some documentation and tried the integration between Google and SalesForce.
I'm wondering is it possible to emulate an auth token from google to SalesForce?
I'm trying to read a google spreadsheet and then fill up a SalesForce object automatically. The user login will always be the same/universal for this spreadsheet, so I have the credentials required to login.
I am working off of the sample that requires a visualforce, and I'm wondering how would I automatically do the session id token that the google spreadsheet API requires.
Any ideas?
The old-school, hard way would be to send a login() call to the API (available through SOAP messages). Salesforce API is well documented and plenty of examples are available (both in programming languages and for raw XML requests/responses).
But I have no idea what possibilities you have from Google side, if it's only JavaScript then you might not be able to send and retrieve AJAX-like calls to another domain...
Recently another option emerged and that is REST API (no SOAP needed). Looks more promising and easier in my opinion. Quick intro is available here and you'll find more documentation on the bottom of the page.
Last but not least - 2 interesting links:
http://code.google.com/apis/gdata/articles/salesforce.html for some integration tutorial
and built-in integration offered by Salesforce: http://www.salesforce.com/assets/pdf/datasheets/SalesforceGoogleApps.pdf
I've used custom settings to do this. Use OAuth to get a token for Google, then store that token in Salesforce custom settings (Setup-Develop-Custom Settings). You can then retrieve the token for callouts to Google from that custom setting for any user needing access to Google Apps. The downside is, every user will authenticate as your custom setting token user. The upside is that they won't need to individually authenticate. Custom settings are retrievable via Apex using a simple getter, and live as Apex-like objects.
Also keep in mind, Google requires each service to use it's own token. So, if your user wants to use Calendars and Spreadsheets, that's two separate tokens that will need to be stored and retrieved for the callout.
I generally allow users to create their own authenticated session tokens via OAuth if they want to do that, then failover to the custom settings to get the general admin token if necessary.
Are you trying to log into Google Apps from SFDC? There are options for Google Apps within Salesforce, go to Setup > Administration Setup > Google Apps > Settings. I've not used this and it requires some setup, but thought I'd point it out. Aside from that I can only blurt out OAuth (getting users to authenticate with Google from within Salesforce when trying to access Google Apps) and SSO (which I know can be used to authenticate from an external system, though not sure if it works the other way).
Look into the "Named Credentials" menu in salesforce setup.
There, you can store auth credentials for the services accessed via Apex:
"A named credential specifies a callout endpoint and its required authentication parameters. When setting up callouts, avoid setting authentication parameters for each callout by referencing named credentials."
a username/pass combo can be used, or a certificate, or an AWS signature, and there is a JWT option..
Help docs: https://help.salesforce.com/articleView?id=named_credentials_about.htm&type=5