I'm a bit confused about firebase rules. This is my realtime database. Each node inside "1" is created using the firebase unique id of the user. And in the user's node there is a list of objects.
The objective is for the user to be able to create this node if it doesn't exist, and allow the user to read/write only inside this node.
I tried this but it doesn't work. I get permission error.
{
"rules": {
"1": {
"$key": {
".read": "auth != null && auth.uid == $key",
".write": "auth != null && auth.uid == $key"
}
}
}
}
Note: In the future there will be other parent nodes ("2","3" etc) So it is important to keep the "1". Also in case it matters I am using firebase anonymous sign in.
I appreciate the help.
UPDATE:
I retrieve the installationId like this:
Task<String> getIdTask = FirebaseInstallations.getInstance().getId()
and access the database like this:
FirebaseDatabase.getInstance()
.getReference()
.child("1")
.child(installationId)
Trying to access the database using above code gives this:
Listen at /1/cKYZwWrlRmSof79rtfuX82 failed: DatabaseError: Permission denied
SOLUTION:
I just realized the magnitude of my mistake. To retrieve the userId I was using
FirebaseInstallations.getInstance().getId()
instead of this which is what firebase sees as userId:
FirebaseAuth.getInstance().getCurrentUser().getUid();
Using the later one solved the issue.
Unless you'd add another node, that actually links the UID with your user ID, how shall it know about it? I'd suggest to reconsider the structure and get rid of that superfluous node altogether; just use the UID. It's not that it wouldn't be possible, to lookup values by UID ... but it might be an unfortunate database design, which ignores the given environment.
We receive Firebase warning emails about our realtime database having insecure rules. Which is true, but I am struggling with how to change them. Our application is about 2 apps with a Chat functionality between a passenger and a driver.
This is what we store in the database:
Currently we have:
{
"rules": {
".read": true,
".write": true
}
}
Access should be granted if driverId / passengerId are supplied in the database read or write request.
Help is much appreciated.
I have only basic info about Firebase rules. I hope my below rules can help or atleast give you some idea about how to approach your situation.
So basically for read and write requests, we'll check if your data has the field driverId of passengerId or not:
{
"rules": {
"chats": {
".read": data.hasChildren([‘driverId’, ‘passengerId’]) === "true"
".write": newData.hasChildren([‘driverId’, ‘passengerId’]) === "true"
}
}
}
Here, newData corresponds to the incoming data and data corresponds to the data already and curently residing in the database.
More help can be found here and here in Firebase's official documentation for security rules.
Your rules allow anyone to read & write anything anywhere. You should use authentication (to be able to identify users by their UID in the rules), structure you db so that information with different access logic is stored in different paths, then write rules to enforce your access logic.
I want to build a desktop application and be able to publish product keys or serial numbers.Before the user can use the application he will be requested to enter the product key/serial number.
Similar to Microsoft Office when they provide keys like XXXX-XXXX-XXXX-XXXX
The idea I have is to sell the app based on licenses and providing product key for every device seems more professional than accounts (usernames and passwords).
so my questions are:
1) Is it possible to accomplish this with electron?
2) Can you advice me wether I should go for serial numbers (if it is doable) or accounts? or are there better options?
3) if you answered the second question. Please state why?
Edit for 2021: I'd like to revise this answer, as it has generated a lot of inquiries on the comparison I made between license keys and user accounts. I previously would almost always recommended utilizing user accounts for licensing Electron apps, but I've since changed my position to be a little more nuanced. For most Electron apps, license keys will do just fine.
Adding license key (synonymous with product key) validation to an Electron app can be pretty straight forward. First, you would want to somehow generate a license key for each user. This can be done using cryptography, or it can be done by generating a 'random' license key string and storing it in a database and then building a CRUD licensing server that can verify that a given license key is "valid."
For cryptographic license keys, you can take some information from the customer, e.g. their order number or an email address, and create a 'signature' of it using RSA cryptography. Using Node, that would look something like this:
const crypto = require('crypto')
// Generate a new keypair
const { privateKey, publicKey } = crypto.generateKeyPairSync('rsa', {
// Using a larger key size, such as 2048, would be more secure
// but will result in longer signatures.
modulusLength: 512,
privateKeyEncoding: { type: 'pkcs1', format: 'pem' },
publicKeyEncoding: { type: 'pkcs1', format: 'pem' },
})
// Some data we're going to use to generate a license key from
const data = 'user#store.example'
// Create a RSA signer
const signer = crypto.createSign('rsa-sha256')
signer.update(data)
// Encode the original data
const encoded = Buffer.from(data).toString('base64')
// Generate a signature for the data
const signature = signer.sign(privateKey, 'hex')
// Combine the encoded data and signature to create a license key
const licenseKey = `${encoded}.${signature}`
console.log({ privateKey, publicKey, licenseKey })
Then, to validate the license key within your Electron app, you would want to cryptographically 'verify' the key's authenticity by embedding the public (not the private!) key generated above into your application code base:
// Split the license key's data and the signature
const [encoded, signature] = licenseKey.split('.')
const data = Buffer.from(encoded, 'base64').toString()
// Create an RSA verifier
const verifier = crypto.createVerify('rsa-sha256')
verifier.update(data)
// Verify the signature for the data using the public key
const valid = verifier.verify(publicKey, signature, 'hex')
console.log({ valid, data })
Generating and verifying the authenticity of cryptographically signed license keys like this will work great for a lot of simple licensing needs. They're relatively simple, and they work great offline, but sometimes verifying that a license key is 'valid' isn't enough. Sometimes requirements dictate that license keys are not perpetual (i.e. 'valid' forever), or they call for more complicated licensing systems, such as one where only a limited number of devices (or seats) can use the app at one time. Or perhaps the license key needs a renewable expiration date. That's where a license server can come in.
A license server can help manage a license's activation, expirations, among other things, such as user accounts used to associate multiple licenses or feature-licenses with a single user or team. I don't recommend user accounts unless you have a specific need for them, e.g. you need additional user profile information, or you need to associate multiple licenses with a single user.
But in case you aren't particularly keen on writing and maintaining your own in-house licensing system, or you just don't want to deal with writing your own license key generator like the one above, I’m the founder of a software licensing API called Keygen which can help you get up and running quickly without having to write and host your own license server. :)
Keygen is a typical HTTP JSON API service (i.e. there’s no software that you need to package with your app). It can be used in any programming language and with frameworks like Electron.
In its simplest form, validating a license key with Keygen is as easy as hitting a single JSON API endpoint (feel free to run this in a terminal):
curl -X POST https://api.keygen.sh/v1/accounts/demo/licenses/actions/validate-key \
-d '{
"meta": {
"key": "C1B6DE-39A6E3-DE1529-8559A0-4AF593-V3"
}
}'
I recently put together an example of adding license key validation, as well as device activation and management, to an Electron app. You can check out that repo on GitHub: https://github.com/keygen-sh/example-electron-license-activation.
I hope that answers your question and gives you a few insights. Happy to answer any other questions you have, as I've implemented licensing a few times now for Electron apps. :)
YES but concerning the software registration mechanism, IT IS HARD and it needs a lot of testing too.
If 90% of your users have internet access you should definitely go with the user accounts or some OAUTH 2.0 Plug and play thing (login with facebook/gmail/whatever)
I built a software licensing architecture from scratch using crypto and the fs module , and it was quite a journey (year) !
Making a good registration mechanism for your software from scratch is not recommended , electron makes it harder because the source code is relatively exposed.
That being said , if you really wanna go that way , bcrypt is good at this (hashs), you need a unique user identifier to hash , you also need some kind of persistence (preferably a file ) where you can store the user license , and you need to hide the salt that you are using for hashing either by hashing the hash... or storing small bits of it in separate files.
this will make a good starting point for licensing but it's far from being fully secured.
Hope it helps !
There are many services out there which help you add license key based software licensing to your app. And to ensure your customers don't reuse the key, you would need a strong device fingerprinting algorithm.
You can try out Cryptlex. It offers a very robust licensing solution with advanced device fingerprinting algo. You can check out the Node.js example on Github to add licensing to your electron app.
Yes, it is possible.
I myself desired this feature, and I found related solutions such as paid video tutorials, online solutions [with Keygen], and other random hacks, but I wanted something that is offline and free, so I created my own repository for myself/others to use. Here's how it works.
Overview
Install secure-electron-license-keys-cli. (ie. npm i -g secure-electron-license-keys-cli).
Create a license key by running secure-electron-license-keys-cli. This generates a public.key, private.key and license.data.
Keep private.key safe, but stick public.key and license.data in the root of your Electron app.
Install secure-electron-license-keys. (ie. npm i secure-electron-license-keys).
In your main.js file, review this sample code and add the necessary binding.
const {
app,
BrowserWindow,
ipcMain,
} = require("electron");
const SecureElectronLicenseKeys = require("secure-electron-license-keys");
const path = require("path");
const fs = require("fs");
const crypto = require("crypto");
// Keep a global reference of the window object, if you don't, the window will
// be closed automatically when the JavaScript object is garbage collected.
let win;
async function createWindow() {
// Create the browser window.
win = new BrowserWindow({
width: 800,
height: 600,
title: "App title",
webPreferences: {
preload: path.join(
__dirname,
"preload.js"
)
},
});
// Setup bindings for offline license verification
SecureElectronLicenseKeys.mainBindings(ipcMain, win, fs, crypto, {
root: process.cwd(),
version: app.getVersion(),
});
// Load app
win.loadURL("index.html");
// Emitted when the window is closed.
win.on("closed", () => {
// Dereference the window object, usually you would store windows
// in an array if your app supports multi windows, this is the time
// when you should delete the corresponding element.
win = null;
});
}
// This method will be called when Electron has finished
// initialization and is ready to create browser windows.
// Some APIs can only be used after this event occurs.
app.on("ready", createWindow);
// Quit when all windows are closed.
app.on("window-all-closed", () => {
// On macOS it is common for applications and their menu bar
// to stay active until the user quits explicitly with Cmd + Q
if (process.platform !== "darwin") {
app.quit();
} else {
SecureElectronLicenseKeys.clearMainBindings(ipcMain);
}
});
In your preload.js file, review the sample code and add the supporting code.
const {
contextBridge,
ipcRenderer
} = require("electron");
const SecureElectronLicenseKeys = require("secure-electron-license-keys");
// Expose protected methods that allow the renderer process to use
// the ipcRenderer without exposing the entire object
contextBridge.exposeInMainWorld("api", {
licenseKeys: SecureElectronLicenseKeys.preloadBindings(ipcRenderer)
});
Review the sample React component how you can verify the validity of your license, and act accordingly within your app.
import React from "react";
import {
validateLicenseRequest,
validateLicenseResponse,
} from "secure-electron-license-keys";
class Component extends React.Component {
constructor(props) {
super(props);
this.checkLicense = this.checkLicense.bind(this);
}
componentWillUnmount() {
window.api.licenseKeys.clearRendererBindings();
}
componentDidMount() {
// Set up binding to listen when the license key is
// validated by the main process
const _ = this;
window.api.licenseKeys.onReceive(validateLicenseResponse, function (data) {
console.log("License response:");
console.log(data);
});
}
// Fire event to check the validity of our license
checkLicense(event) {
window.api.licenseKeys.send(validateLicenseRequest);
}
render() {
return (
<div>
<button onClick={this.checkLicense}>Check license</button>
</div>
);
}
}
export default Component;
You are done!
Further detail
To explain further, the license is validated by a request from the client (ie. front-end) page. The client sends an IPC request to the main (ie. backend) process via this call (window.api.licenseKeys.send(validateLicenseRequest)).
Once this call is received by the backend process (which was hooked up because we set it up with this call (SecureElectronLicenseKeys.mainBindings)), the library code tries to decrypt license.data with public.key. Regardless if this succeeds or not, the success status is sent back to the client page (via IPC).
How to limit license keys by version
What I've explained is quite limited because it doesn't limit the versions of an app you might give to a particular user. secure-electron-license-keys-cli includes flags you may pass when generating the license key to set particular major/minor/patch/expire values for a license.
If you wanted to allow major versions up to 7, you could run the command to generate a license file like so:
secure-electron-license-keys-cli --major "7"
If you wanted to allow major versions up to 7 and expire on 2022-12-31, you could run the command to generate a license file like so:
secure-electron-license-keys-cli --major "7" --expire "2022-12-31"
If you do run these commands, you will need to update your client page in order to compare against them, ie:
window.api.licenseKeys.onReceive(validateLicenseResponse, function (data) {
// If the license key/data is valid
if (data.success) {
if (data.appVersion.major <= data.major &&
new Date() <= Date.parse(data.expire)) {
// User is able to use app
} else {
// License has expired
}
} else {
// License isn't valid
}
});
The repository page has more details of options but this should give you the gist of what you'll have to do.
Limitations
This isn't perfect, but will likely handle 90% of your users. This doesn't protect against:
Someone decompiling your app and making their own license to use/removing license code entirely
Someone copying a license and giving it to another person
There's also the concern how to run this library if you are packaging multiple or automated .exes, since these license files need to be included in the source. I'll leave that up to the creativity of you to figure out.
Extra resources / disclaimers
I built all of the secure-electron-* repositories mentioned in this question, and I also maintain secure-electron-template which has the setup for license keys already pre-baked into the solution if you need something turn-key.
I see that the workflow is to start authrorizer, giving it file loader. So, we have a sequence of callbacks, onAuthrorized => start loading file => doc.getModel() on file load. Here they say how you get the model. But, I also see that gapi.drive.realtime.load(fileId, onFileLoaded, initializeModel, handleErrors) can elso end up with TOKEN_REFRESH_REQUIRED and it seems that TOKEN_REFRESH_REQUIRED can fire after the document is loaded, after some time of user inactivity, which seems to be related with token expiration. How should re-authorization to go? Should I tell the client that the current model that he is connected to is invalid? Please note that my app starts on file load. So, if I go the whole stack re-authorization, which calls another file load, which calls another document loaded will re-start my application. Is it supposed way to go? To put in other words, is there a way to refresh the token without loosing existing connection?
Where is the token stored actually? I do not see that I receive it on authorized. It is not passed to the realtime.load. How does realtime.load knows about the token? How can I speed up the token expiration for debug?
I am still not sure that this is a right answer but this is what I have got looking at code here, which says that we should provide empty callback to re-authorize
/**
* Reauthorize the client with no callback (used for authorization failure).
* #param onAuthComplete {Function} to call once authorization has completed.
*/
rtclient.Authorizer.prototype.authorize = function(onAuthComplete) {
function authorize() {
gapi.auth.authorize({client_id: rtclient.id, scope: ['install', 'file'],}, handleAuthResult)
}
function handleAuthResult(authResult) {
if (authResult && !authResult.error) {
hideAuthorizationButton() && onAuthComplete()
} else with (authorizationButton) {
display = 'block' ;
onclick = authorize;
}
}
You call it first use it in a function to load your document
(rtclient.authorizer ? rtclient.authorizer = identity : rtclient.authorize) (proceedToLoadingTheFile)
But later, on timeout we have code
function handleErrors(e) { with(gapi.drive.realtime.ErrorType) {switch(e.type) {
case TOKEN_REFRESH_REQUIRED: rtclient.authorizer.authorize() ; break
case CLIENT_ERROR: ...
Note no arguemnts in the latter. Authorizer won't reload the document. I think that this explains the logic asked. However, it does not answer about the internals, how is it possible that loader takes on existing authorizer or switches to a new one.
I've signed up for the free month trial of Azure, and I have created a Mobile Service. I'm using iOS, so I downloaded the model Todo app for iOS.
I am now trying to use Table Storage in the back end instead of a MSSQL store; I have found instructions on using Table Storage here: http://azure.microsoft.com/en-us/documentation/articles/storage-nodejs-how-to-use-table-storage/
However, my app is still storing todo items in the MSSQL storage. I've been told that I don't need to do anything in the client to make the switch, so I assume everything I need to do must be done in the node.js scripts. But I'm clearly missing something.
One thing that confuses me is that after I downloaded the generated node.js script for the Todo app, I didn't see anything in it that seemed to be explicitly talking to the MSSQL database.
Any pointers would be greatly appreciated.
EDIT:
here's my todoitem.insert.js:
var azure = require('azure-storage');
var tableSvc = azure.createTableService();
function insert(item, user, request) {
// request.execute();
console.log('Request received');
console.log(request);
var entGen = azure.TableUtilities.entityGenerator;
var task = {
PartitionKey: entGen.String('learningazure'),
RowKey: entGen.String('1'),
description: entGen.String('add something to TS'),
dueDate: entGen.DateTime(new Date(Date.UTC(2014, 11, 5))),
};
tableSvc.insertEntity('codedelphi',task, {echoContent: true}, function (error, result, response) {
if(!error){
// Entity inserted
console.log('No error on table insert: task created.');
request.respond(statusCodes.SUCCESS, 'OK.');
} else {
console.log('Houston, we have a problem. Entity not added to table.');
console.log(error);
}
});
console.log(JSON.stringify(item, null, 4));
}
tableSvc.createTableIfNotExists('codedelphi', function(error, result, response){
if(!error){
// Table exists or created
console.log('No error, table should exist');
} else {
console.log('We have a problem.');
console.log(error);
}
});
Mobile Services has the built in capability to handle talking to your SQL Database for you. When your script calls "request.execute()" that triggers whatever the request is (insert, update, delete, select) to be ran against the SQL database. Talking to Table Storage instead of SQL requires you to edit those scripts to explicitly talk to Table Storage (i.e. perform your insert, update, deletes, and reads). Today there is no magic switch which will change your "request.execute" from talking to SQL to talk to Table Storage. If you've already edited your scripts to talk to Table Storage and it's not working / you still see data stored in your SQL database, I would suspect that you are either still calling "request.execute" in your scripts, or you haven't pushed them to your Mobile Service (if you've pulled them down locally and then need to push them back to your service). If you've done all of the above, update your question with the Node.js script in question so we can see it.
As Chris pointed out, you are most likely still calling request.execute() from your table scripts. By design, this will explicitly talk to the MSSQL database you configured your application with. You will have to edit your table scripts to not perform "request.execute()" and instead interact with the TableService object.
If you follow the tutorial, and do the following:
1. Import the package.
2. Create the table service object.
3. Create an entity (and modify the variables to store the data you need)
4. Write the entity to your table service.
You should see data being written to table storage rather than SQL database.
Give it a shot and ping back, we'll help you out.