I'm writing a chrome extension for quick search notes in fuzzy match model. So I need to cache all notes' metadata(title, url, createdTime,etc) in local storage.
According to evernote offical doc, there are two ways to authenticate to the Evernote API, developer tokens and OAuth.
But right now,
1. developer token has been deprecated.(if you go to the application URL you will get Update: the creation of developer tokens is temporarily disabled.
2. OAuth can only access one specific notebook(depend on user authentication)
So my question is : is there any way can work around to get all notes' metadata?
OAuth can only access one specific notebook(depend on user authentication)
This is not the case. By default, Evernote API keys are scoped to the account level; so you'll have access to all notebooks in the account of the user who authenticates using your OAuth process.
Evernote does also have an optional type of API key available, called an App Notebook key, that can be requested. But you have to specifically request that type of key when you request your API key; otherwise it'll be a full account access key.
Related
Recently i build a app using Firebase, But after i got Some users through advertisement, Someone just hacked Firebase database and Updated all user datas like .
Username
Profile pic path
They set it to a bad word and bad pic.
So then i Also Checked the Firebase rules and redefined them..
Like
Only Authenticated users can read/write.
But problem is.
The hacker is still updated the Value on firebase db.
and i want to know what i am missing.
Is it possible to update a Firebase db without the whole secure key and things..
using a browser may be?
User data of a single user ...
email : "https://m.me.developer.scg"
lastseen : "1617987743"
pic : "https://www.dropbox.com/s/03a50cx4adxqepk/(url cannot be posted publically it contains nude images)"
privacy : "PU"
state : "offline"
status : "Lets watch some movies"
type : "FREE USER"
username : "FU*KED BY DreamPLAY"
Here the hacker updated the 3 fields.
email :
pic:
username:
You have to know that as soon as (1) someone has the apiKey of your Firebase Project and (2) the email/password sign-in method is enabled, this person can use the Firebase Auth REST API and sign-up to your project (i.e. create a new account).
Getting the apiKey is not very difficult if you deploy an app linked to your Firebase project (Android, iOS, Web...).
Consequently, rules only based on auth != null allow anyone that has signed-up through the REST API accessing your Realtime Database. No need to use any GUI: after having been identified through the Auth REST API, the user can use the RTDB REST API.
One classical approach to avoid "non-desired" users to access data, is to add one or more Custom Claims to the desired accounts and use these claims in the Security Rules: See the doc for more details.
I will answer as parts :
Reason of Problem :
The Hacker found your API then created project and added your API to it then he
created authenticated user then he updated the fields , So this the reason of
problem
Solution :
First : is to create unique Fields (e.g Email to 1234567890Email as
Example but more secure)
Second : is to connect to Google Cloud Platform then setup Google Cloud Platform HTTP with your Domain (As Firebase will only accept data from your Domain ONLY)
Third : Is to create more secure rules as to denied access to Entire Database but just
give access to some collections or even documents So it will be more
secure
I just covered the most famous actions (You can see more but by google your problem)
& Wish I helped you :)
I just thought of a way to secure Firebase credentials so thought of a way to use a custom cloud functions authentication function (URL based function) to accept user credentials like username and password via URL encoded parameters. This method will only use database(firestore would be preferable). The function will only have to create custom tokens and send it to the user while keeping the user's temporary data like IP addresses etc. So request to write or read to the database will only be granted to this function.
You CAN prevent all those non authencated activities right from your firebase console.
GO to your firebase console, Open your project's android app.
Add SHA fingerprints of your app's SHA signing certificate fingerprints.
We are transitioning to using Terraform to create our architecture on Google Compute, and part of it utilises Firebase for the front-end. So far, I have managed to get this all working fine, but have hit a snag on Firebase Auth. Essentially, I want to allow 'Email/Password' authentication on a Firbase project programmatically.
The above shows where you find the setting in the UI console, but I want to be able to do that via an API/CLI, and also set the 'Authorised Domain'.
Yes, as of November 2022, this is now possible, either using Terraform, or the gcloud CLI and a bit of scripting. Both methods make use of the REST Identity Toolkit API.
If using Terraform: Your config file needs to specify a google_identity_platform_project_default_config resource: the documentation for it is available here. By way of example – assuming you've already declared a google_project resource called my_project, you could add the google_identity_platform_project_default_config resource as follows:
resource "google_identity_platform_project_default_config" "myconfig" {
project = google_project.myproject.project_id
sign_in {
allow_duplicate_emails = false
anonymous {
enabled = false
}
email {
enabled = true
password_required = false
}
}
}
This would enable email+password authentication, disallow anonymous access, and disallow duplicate email addresses.
If using the gcloud CLI: This would be a good deal fiddlier. I haven't tested it out completely, but it is presumably equivalent to what Terraform is doing behind the scenes. You need to obtain a service account access token, then use cURL (or a similar tool/API) to amend the Identity Toolkit configuration using the PATCH method (documentation here), supplying the token in the "Authorization" header.
gcloud lets you get an access token using the command gcloud auth print-access-token, but according to this 2021 blog post1 by #DazWilkin, the token obtained using your regular human credentials can't perform the necessary PATCH operation; you need to use a token backed by a service account that has the correct permissions.
The blog post gives further details, but roughly, the steps are:
Create a service account and give it the correct permissions. (Not necessary if you already have an appropriate service account; such an account can be created either using the Firebase console or Terraform's google_service_account resource.)
Create a JSON service account key file. (Not necessary if you already have a key created, plus a JSON file for it. These JSON files contain an object with the keys "project_id", "private_key_id", and "private_key", and are exactly the same sort of file as gets generated from the Firebase console if you go to "Project Overview" / "Project Settings" / "Service Accounts" / "Generate new private key". They can also be created programmatically using Terraform's google_service_account_key resource.)
Allow gcloud to perform operations using the service account's permissions, by running gcloud's "auth activate-service-account" subcommand: something like
$ gcloud auth activate-service-account --key-file=/path/to/key-file.json EMAIL_ADDRESS_OF_SERVICE_ACCOUNT
Obtain an access token for the service account by running gcloud auth print-access-token EMAIL_ADDRESS_OF_SERVICE_ACCOUNT.
Supply that token in the header of an HTTP PATCH request using cURL.
For more details, see the blog post; it's concerned with amending the "authorized domains" list for a Firebase project, but enabling email/password authentication would be very similar.
1 Also mentioned in this stackoverflow answer.
I'm trying to use the Firestore Go SDK from a client application. This looks like a client-side SDK, based on the functions, but that might be my first error?
I'm struggling to authenticate the user to Firestore. I've already logged them in using the REST API for Firebase Auth. This returns me an ID token, refresh token, etc. How do I use this with the Firestore SDK?
The docs suggest I need to call firestore.NewClient(<context>, <project-id>, <option>). For the latter argument, I've tried option.WithCredentialsJSON(...) passing a JWT-decoded ID token. I've also tried passing the raw refresh token. In both cases, the SDK complains about what I'm passing.
How can I authenticate the user based on the tokens I've obtained?
The Go SDK for Firestore is meant to be used in a trusted environment, such as your development machine, a server you control, or Cloud Functions. It doesn't have a way to sign the user of the application in, but instead authenticates itself with the server with administrative credentials, which you'll don't want to have on non-trusted devices.
option.WithCredentialsJSON accepts not JWT token, but Google Application Default Credentials.
Other option is to provide path to the file with Google Application Default Credentials using environment variable GOOGLE_APPLICATION_CREDENTIALS since firebase sdk is a part of the cloud.google.com/go sdk.
Check out the examples (also with other options).
https://cloud.google.com/docs/authentication/production#auth-cloud-implicit-go
https://godoc.org/cloud.google.com/go#example-package--ApplicationDefaultCredentials
There's an open feature request for Metabase to support IAP. I took a stab at it, and have a Clojure implementation of the steps detailed in Securing your app with signed headers (i.e. verify token header, verify token payload, retrieve user identity).
But this question isn't necessarily specific to Metabase. The general idea is to replace Google Sign-In and only use only IAP signed headers for authentication and user creation in an application on Google App Engine (specifically, GAE flex environment).
The "problem" is that the user identity information from the IAP token looks like: {"email":"alice#example.com","sub":"accounts.google.com:118133858486581853996"}. I also came across Using special URLs, but this returns something like: {"email":"accounts.google.com:USER_EMAIL","sub":"accounts.google.com:118133858486581853996"}.
With a Google Sign-In token, I can obtain values for given_name and family_name along with email, which means I can fetch-or-create a valid Metabase user. Is there a way to get the first and last name via the JWT sub, (i.e. accounts.google.com:118133858486581853996)?
Hm, if they have a public profile you can pass the number after "accounts.google.com:" to https://developers.google.com/+/web/api/rest/latest/people/get . Unfortunately, you won't be able to authenticate to that API as the user, since IAP doesn't currently provide a way to call let users delegate access to call Google APIs. (You'll have to use a service account to call that API.)
The other solution would be, if IAP provided a way to a) specify additional scopes in its OAuth request to Google, and if it then b) passed additional claims from the OIDC token into the IAP JWT, you'd be able to configure IAP to request the "profile" scope. However, IAP currently only requests the "email" and "openid" scopes, and doesn't have a mechanism for specifying additional scopes.
-- Matthew, Google Cloud IAP engineering
I'm building an installed application that will have features requiring the Google Drive REST API using Qt and C++. I understand Qt is now releasing new libraries to support OAuth flows but let's assume I'm a student and learning to use OAuth at this layer is a requirement for this project.
In my application, I have a working OAuth flow for installed applications that ends with an Access Token and Refresh Token being stored using QSettings (I'm open to input on whether this is a disastrously bad idea too). The application requires no authentication/login for its own sake/data, but it does need authentication to Google for calling API's using an Access Token. This application has no associated web backend being hosted; its simple and should be deployable completely locally (I've written and included a simple TCP server that will receive the authorization redirect_uri and will run and close when called from within the application).
As such, I'm curious about the best way to make sure that, when a user opens my application and wants to use the Google Drive features, they are appropriately authenticated on Google's end. Say, if I maintain an access token in the registry, and this access token is granted per-user/per-application basis (right?), then how can I make sure only the user the token belongs to is able to make calls to the API with it?
Here's my understanding and approach; feel free to correct me or educate me if I've got the wrong interpretation.
If an Access Token is found, perform the following:
Open a browser page to a Google login domain and have the user authenticate there (this could prohibit a user from being able to use a cached login session that would have access to a token they otherwise shouldn't have access to)
If user has correctly authenticated with a Google account, return control to the application and make a test call to an API using the stored token.
If the call fails (responds with an invalid_credentials) I should be able to be sure its because the access token has expired and the application will go through the flow to renew an Access Token from a Refresh Token.
If no Access Token is initially found:
Start a normal OAuth installed application flow
Get the tokens and store them so that when the user opens the application next time the former procedure is used
My issue then is the first two steps if the Access Token is found. Nominally this could be done by the typical OAuth flow but it appears that when using a localhost as the redirect uri, Google will always prompt for consent, regardless of settings for prompt and access_type authorization query parameters.
What can be done to accomplish these first two steps in a way that my application can control (i.e. not a solution that relies on a backend server being hosted somewhere)?
If this question is too open-ended for SO requirements I can make some more restrictions/assumptions to limit the problem domain but I'd rather not do that yet in case I unknowingly rope off a good viable solution.
Thanks for reading! Sorry if its a verbose; I wanted to ensure my problem domain was fully fleshed out!
If you are using an installed application, I wouldn't recommend using or storing refresh tokens. Storing refresh tokens on the client side means that if an intruder gains access to the client's application, they have infinite access to the user's application without ever having to enter the user's credentials. If you do insist on having a refresh token, ensure you follow the Google's installed app flow, with the code_verifier parameter included in your requests.
If the access token is found, you should try to verify it, and if verified then use it at the google api, otherwise force the user to login again (or refresh it if you chose to still use refresh tokens).
If no access token is found, your flow sounds fine.
A few notes on loggin in with Google:
Google will only return a refresh token if you specify access_type=offline in your auth request.
Google will only return a refresh token on the user's first authorization request, unless you always specify prompt=consent in your query params.
In my experience, when leaving out the prompt query param, the user is not prompted for their consent again. If they are logged in to google, you will get a new access token, but no refresh token, unless you have prompt=consent.
I think the idea is you use prompt=consent if you have no record of the user ever using your application. Otherwise if they have used it before, you may prefer to use prompt=select_account to allow the user to select which account he wants to use in case he has more then one, or you can just use prompt=none.
This is just my understanding of it all.
My approach I ended up using was just to deploy with an SQLite db that will be stored in the AppData roaming directory. The db schema includes a field for the user's Name (from the OpenID IDToken field if it exists), the user's picture URL (again from IDToken if it exists), the refresh and access token strings (will be stored as encrypted strings when I get around to it), the user's UID/sub string, and a field for a user name and password.
These latter two fields are authentication fields for within my own application, which, again, I wanted to avoid but it seems impossible to do so. So the user will be prompted to enter a username and password into a form, and these credentials will be checked against the existing SQLite db file mentioned previously.
If they exist and are correct, the user gets logged in and will have access to their respective access and refresh token.
If the user has forgotten their password, they'll be asked for reconsent (going through the installed app flow again), and whatever password they provided during initial login will be used as the reset password. It is considered, for my purposes, that logging into Google for the installed app flow is proof enough that the user account belongs to them and they should have authorization to reset the password.
If the user is a new user and doesn't have a record in the local SQLite db file, then they can also click a button to "Create New Account" - which effectively goes through the authorization flow as well but this time a whole new record is posted to the SQLite db with the appropriate fields filled.
There's still more optimization that could be done but at least I am getting closer to the level of security and control of access to Google user accounts that I want.
I'm not marking this as an answer because I feel like this solution is still not desired and that there should be an easier way. So if someone has evidence or experience of providing an equivalent level of authentication control without needing to maintain a local user account database then I would be more than happy to mark such a method as the solution!
Thanks again!