I am learning fauna db but is not working from terminal shell.
It shows data on webshell.
> Paginate(Indexes())
{
"data": [
Index("school"),
Index("Community")
]
}
But does not show data on terminal shell.
> Paginate(Indexes())
{ data: [] }
Each secret that you use is associated with a specific database.
The web shell can access any of your databases via your username+password login. The fauna-shell terminal app can only use secrets, which are typically stored in $HOME/.fauna-shell.
If you need to, create a new key in the Dashboard for the database you wish to access via fauna-shell (or application code); using the key's secret gives you access to that database. Make sure that you record the new secret someplace safe, such as in $HOME/.fauna-shell, because it is only provided once.
Related
I am fairly new to Cloudant/PouchDB. I have managed to get the PouchDB/cloudant instances to sync properly, so I am able to create databases, PUT data, and read data from both the local and Remote databases.
My issue is with authentication.
I'm not sure how to handle the authentication in my scenario. It seems like i have to create the API key/Password for basic authentication and pass that with each request. But how does my 'User' have access to that information?
In my tests the value is simply hardcoded in my javascript page - which is obviously not ideal. What id like to do is simply have a database of users with hashed credentials, and have the user submit their login username/pass against that database to allow login.
I've done some reading regarding enabling the '_users' database...but i cant seem to find anything that really lays out how that would work fully...
[EDIT]
I've manage to setup the _users database with cloudant, and add a user, and give them a membership to one of my databases.
However, this user still doesnt seem to be able to access the db.
Here is the user:
{
"_id": "org.couchdb.user:jan",
"_rev": "1-ec0b2b9c25815ab71a04df745151a85b",
"name": "jan",
"roles": [],
"type": "user",
"password_scheme": "simple",
"salt": "a4f47458b436e705378224896a3260f2",
"password_sha": "6ba718935b8ee170879973baae1b7ce953fd4258"
}
and here is the response from cloudant regardign the _securty of the db i want 'jan' to access:
My understanding is that i should be able to get a response via
jan:apple#cloudanturl/dbname
Instead i get:
{"error":"forbidden","reason":"_reader access is required for this request"}
I'm setting up an online survey. This survey will be anonymous - to fill it all you need to have is the survey's URL. I want to store the survey answers in Firestore, and later run scripts that retrieve the data and generate reports.
I want to set it up so that everybody can write to it, but only specific accounts that have access to the project can read the data. I've set up the following rules:
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read: if request.auth.uid != null;
allow write;
}
}
}
Now I want to create the script that reads the data, and I'm not sure - which API key should I use? Firestore automatically created a firebase-sdk-admin service account - should I use this account? There are also the Browser Key and Web client Key that were created automatically. Are those the ones to use?
What I would really want is to set up the script in a way that asks me for my Google Credentials (much like the gcloud sdk does it). That way there's no sensitive information in the script at all - if the script user logs in to Google with an account that has access to the database - it works. If it doesn't - it doesn't.
Can I do that?
You can either user Firebase Custom Claims which are basically like roles in Discord so or store UIDs of authorized users in Firestore or RTDB. Then you can write you security rules like this:
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read: if request.auth.uid != null;
allow write: if request.auth.token.admin == true;
}
}
}
Now only the users with "admin" claim set to true will be able to write to those documents. If you go with storing the user UIDs in a Firestore document then you can check if user's UID is present their as shown below:
allow write: get(/databases/$(database)/documents/users/$(request.auth.uid)).data.admin == true;
Regarding the Service Account, you should not use them from frontend. They grant privileged access to your Firebase resources i.e. security rules are redundant. So you usually use them with the Firebase Admin SDK in a secure server env like Cloud functions. You can create a Firebase Cloud Function and then allow only whitelisted users to invoke it. That means if unauthenticated users or someone you haven't whitelisted won't be able to invoke it.
If you want to give access to your database to a teammate, then you can add members to your project from the Firebase Console. Let me know if you have any further queries.
I think I got it. Since I want to let everybody write, and only read data from scripts run by admins and not users, I can set up the following access rules:
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read: if false;
allow write;
}
}
}
For reading, my scripts will authenticate as a service account (keeping the service account json file a secret), and will be able to read the data properly.
I'm writing a Google Script that will call an external API and pull the resulting data into a Google Sheet. The API requires a Client ID and Secret value for authorization, and I need to keep those values secure. I would also like to trigger the script to run periodically (basically, I'm trying to automate the updating of this sheet as much as possible).
I'm no data security expert, but keeping the Client ID and Secret hardcoded seems like a terrible idea. Most of the search results I've found recommend using the Properties Service to store those values, but in order to set those properties I'd have to hardcode them in the same script, correct? If so, that doesn't solve the security problem.
Other recommendations involve prompting the user to enter the credentials to authorize each run of the script. This solves the security requirement, but I want this process to be as automatic as possible. If I'm opening the script and providing my credentials each time it runs, then I may as well skip the triggered executions.
Are there any other solutions? For context, I am the only person who needs to access this script and no one else should be able to access the Client ID and Secret.
Since you are the only one who has access to the script (having View access to the spreadsheet doesn't allow users to look at the bound script), hardcoding the Client ID and Secret shouldn't be a problem. Just don't give them Edit access to the spreadsheet.
If you don't want to hard-code the data directly anyway, you have some alternatives:
Using Properties Service:
Use Properties Service, as you mentioned. You could, for example, set the Client ID by running this once (in the legacy IDE, you can set these properties manually too):
function setClientId() {
var props = PropertiesService.getScriptProperties();
props.setProperty('Client ID', '{YOUR_CLIENT_ID}');
}
Once the property was set, you can remove '{YOUR_CLIENT_ID}', or even the whole function, if you don't want to keep it hard-coded. The script could then retrieve the stored property the following way:
function getClientId() {
var props = PropertiesService.getScriptProperties();
return props.getProperty('Client ID');
}
Using library:
Another option could be to store this information in a different script, to be used as a library (see Gain access to a library):
var CLIENT_ID = "YOUR_CLIENT_ID";
var SECRET = "YOUR_SECRET";
And then import this library in your main script (see Add a library to your script project). In the sample below LIBRARY is the library Identifier name:
Code.gs (from main script):
function getData() {
const clientId = LIBRARY.CLIENT_ID;
const secret = LIBRARY.SECRET;
// ...
}
Note:
Please note that, even if you don't hard-code your data directly, anyone who can execute your script can potentially retrieve this data. For example, they could log what's returned by getClientId().
If the script has access to some data, users who can execute the script can access this data too.
I am shared folder in which does contain nearly 7 other folders. i have got client id and secret key and API key. i want to show all that folder in my application. if i m logged in to google drive.it works as soon i logged out it doesn't work, how can i by pass login screen
function handleClientLoad() {
//console.log(gapi.client);
gapi.client.setApiKey(apiKey);
//checkAuth();
//makeApiCall();
//getFoldersList();
window.setTimeout(checkAuth, 1);
}
function checkAuth() {
gapi.auth.authorize({ client_id: clientId, scope: scopes, immediate: true }, handleAuthResult);
}
Google Drive data is private data it is owned by you and your account. In order for your script to access that data you need to give it permissions to see that data. This is the consent screen you are giving it permission to view the data. Short of possibly setting the Google Drive folder to public and then using a public API key to access drive instead of Oauth2.
There are work abounds but none of them work with JavaScript. If this is the only account you will be accessing I recommend you look into a server sided language like PHP or python and use a Service account. You will have to give the service account access to your google drive by sharing the folders in question with it. This is how service accounts are preauthorized.
Answer: There is no way to do away with the consent screen in JavaScript. Or save your authentication for lager use (Refresh token). Switch to a server sided language.
Is it possible to use two or more JSON stores in a Worklight app at the same time (without switching back and forth)? When I initialize a second JSON store with a username/password, collections in the "default" JSON store that were initialized properly become inaccessible.
Given that many functions in the JSON store api does not let you specify a target store, I am guessing that using multiple stores concurrently is not possible. If this is true, then how does one address the use case where it is necessary to:
Encrypt sensitive user data, and
Need access to non-sensitive data before user is authenticated.
The username field you pass to init is basically the file name for the store, for example:
WL.JSONStore.init(..., {username: 'store1'})
You will have store1.sqlite on disk, no encryption. If you want to switch to another store simply call:
WL.JSONStore.closeAll()
The closeAll function will kill all database accessors. Then you can start a second store with a password, for example:
WL.JSONStore.init(..., {username: 'store2', password: '123'})
That will create a store2.sqlite file encrypted with 256-bit AES encryption.
If you want to switch back to store1, simply call WL.JSONStore.closeAll() and then WL.JSONStore.init(..., {username: 'store1'}).
Currently you can not access store1 and store2 at the same time. You can open a feature request here.
The .sqlite files are mentioned here if you want to see them on the file system, and a bit of their internal structure is mentioned here. The code snippets above don't show it, but make sure you take into account that most JSONStore API functions are async, read more here.